[comp.unix.aux] Here are some useful patches to rn for A/UX

herbw@wiskit.pdx.com (Herb Weiner) (11/30/90)

This is an UNOFFICIAL patch for rn 4.3.
Patches through patch 47 should be applied before applying this patch.
This patch is being emailed to Larry Wall (lwall@jpl-devvax.jpl.nasa.gov)
and is being posted to comp.unix.aux.
This patch was created by Herb Weiner (herbw@wiskit.pdx.com)
and is hereby placed into the public domain.
This patch is provided on an AS IS basis.  Use it at your own risk.

This patch contains two completely independent changes (apply either or
both):

1.  On A/UX 2.0, if the console window is resized while rn has a read
    pending, rn terminates with an error.  This is fixed by the change
    to final.c.  This change is A/UX specific, and is conditionally
    compiled only if _AUX_SOURCE is defined.  The added line specifies
    that rn is to use 4.2 BSD-compatible (safe) signals, and that read,
    write, ioctl, and wait calls which are interrupted by a signal will
    resume at the point they were interrupted rather than generating an
    error.

2.  A new switch, -p<number> is added to rn.  This change should work
    correctly with any implementation of rn, although it has been tested
    only with A/UX 2.0.  The affected files are rn.1 (the man page),
    term.h, term.c, and sw.c.  The description from the man page follows:

    -p<number> tells rn how many lines to display before pausing for input.
    This switch is useful if you are using a terminal or workstation
    with a scroll buffer larger than the window size, and you do not want
    rn to pause at the end of each screen full of text.  For example,
    -p100 specifies that 100 lines are to be displayed before pausing
    for input.  The -p switch works well with the -l switch.  If the
    -p switch is not specified, the number of lines is a function of
    the terminal or window size.

Herb Weiner (herbw@wiskit.pdx.com)

*** final.c	Sat Nov 10 02:08:44 1990
--- ../rn/final.c	Sat Nov 10 02:06:13 1990
***************
*** 49,54
  void
  final_init()
  {
  #ifdef SIGTSTP
      sigset(SIGTSTP, stop_catcher);	/* job control signals */
      sigset(SIGTTOU, stop_catcher);	/* job control signals */

--- 49,59 -----
  void
  final_init()
  {
+ #ifdef _AUX_SOURCE
+ #include <compat.h>
+     setcompat (COMPAT_BSDSIGNALS | COMPAT_SYSCALLS); /* for Apple A/UX 2.0 */
+ #endif _AUX_SOURCE
+ 
  #ifdef SIGTSTP
      sigset(SIGTSTP, stop_catcher);	/* job control signals */
      sigset(SIGTTOU, stop_catcher);	/* job control signals */
*** rn.1	Sat Nov 10 02:05:04 1990
--- ../rn/rn.1	Thu Nov 29 14:27:15 1990
***************
*** 947,952
  forces normal (non-mailbox) format in creating new save files.
  Ordinarily you are asked which format you want.
  .TP 5
  .B \-q
  bypasses the automatic check for new newsgroups when starting 
  .I rn.

--- 947,973 -----
  forces normal (non-mailbox) format in creating new save files.
  Ordinarily you are asked which format you want.
  .TP 5
+ .B \-p<number>
+ tells
+ .I rn
+ how many lines to display before pausing for input.
+ This switch is useful if you are using a terminal or workstation
+ with a scroll buffer larger than the window size, and you do not want
+ .I rn
+ to pause at the end of each screen full of text.
+ For example,
+ .B \-p100
+ specifies that 100 lines are to be displayed before pausing for input.
+ The
+ .B \-p
+ switch works well with the
+ .B \-l
+ switch.
+ If the
+ .B \-p
+ switch is not specified, the number of lines is
+ a function of the terminal or window size.
+ .TP 5
  .B \-q
  bypasses the automatic check for new newsgroups when starting 
  .I rn.
*** term.h	Sat Nov 10 02:08:21 1990
--- ../rn/term.h	Sat Nov 10 02:06:04 1990
***************
*** 174,179
  EXT char PC INIT(0);		/* pad character for use by tputs() */
  EXT short ospeed INIT(0);	/* terminal output speed, for use by tputs() */
  EXT int LINES INIT(0), COLS INIT(0);	/* size of screen */
  EXT int just_a_sec INIT(960);			/* 1 sec at current baud rate */
  					/* (number of nulls) */
  

--- 174,180 -----
  EXT char PC INIT(0);		/* pad character for use by tputs() */
  EXT short ospeed INIT(0);	/* terminal output speed, for use by tputs() */
  EXT int LINES INIT(0), COLS INIT(0);	/* size of screen */
+ EXT int FORCELINES INIT(0);	/* -p=forcelines option */
  EXT int just_a_sec INIT(960);			/* 1 sec at current baud rate */
  					/* (number of nulls) */
  
*** sw.c	Sat Nov 10 02:08:13 1990
--- ../rn/sw.c	Sat Nov 10 02:05:47 1990
***************
*** 311,316
  	    fputs("This isn't readnews.  Don't use -n.\n\n",stdout) FLUSH;
  	    break;
  #endif
  	case 'r':
  	    findlast = upordown;
  	    break;

--- 311,322 -----
  	    fputs("This isn't readnews.  Don't use -n.\n\n",stdout) FLUSH;
  	    break;
  #endif
+ 	case 'p':
+ 	    s++;
+ 	    if (*s == '=') s++;
+ 		FORCELINES = atoi(s);
+ 	    LINES = FORCELINES;
+ 	    break;
  	case 'r':
  	    findlast = upordown;
  	    break;
*** term.c	Sat Nov 10 02:08:44 1990
--- ../rn/term.c	Sat Nov 10 02:05:30 1990
***************
*** 223,229
  	UE = SE;
  	UG = SG;
      }
!     LINES = tgetnum("li");		/* lines per page */
      COLS = tgetnum("co");		/* columns on page */
  
  #ifdef TIOCGWINSZ

--- 223,232 -----
  	UE = SE;
  	UG = SG;
      }
!     if (FORCELINES > 0)
!         LINES = FORCELINES;
!     else
!         LINES = tgetnum("li");	/* lines per page */
      COLS = tgetnum("co");		/* columns on page */
  
  #ifdef TIOCGWINSZ
***************
*** 229,235
  #ifdef TIOCGWINSZ
      { struct winsize ws;
  	if (ioctl(0, TIOCGWINSZ, &ws) >= 0 && ws.ws_row > 0 && ws.ws_col > 0) {
! 	    LINES = ws.ws_row;
  	    COLS = ws.ws_col;
  	}
      }

--- 232,239 -----
  #ifdef TIOCGWINSZ
      { struct winsize ws;
  	if (ioctl(0, TIOCGWINSZ, &ws) >= 0 && ws.ws_row > 0 && ws.ws_col > 0) {
! 	    if (FORCELINES == 0)
! 	        LINES = ws.ws_row;
  	    COLS = ws.ws_col;
  	}
      }
***************
*** 251,257
      }
  #ifdef TIOCGWINSZ
  	if (ioctl(1, TIOCGWINSZ, &winsize)>=0) {
! 		if (winsize.ws_row>0) LINES=winsize.ws_row;
  		if (winsize.ws_col>0) COLS=winsize.ws_col;
  	}
  #endif

--- 255,261 -----
      }
  #ifdef TIOCGWINSZ
  	if (ioctl(1, TIOCGWINSZ, &winsize)>=0) {
! 		if ((winsize.ws_row>0) && (FORCELINES == 0)) LINES=winsize.ws_row;
  		if (winsize.ws_col>0) COLS=winsize.ws_col;
  	}
  #endif
***************
*** 1097,1103
       struct winsize ws;
  
       if (ioctl(0, TIOCGWINSZ, &ws) >= 0 && ws.ws_row > 0 && ws.ws_col > 0) {
!           LINES = ws.ws_row;
            COLS = ws.ws_col;
            line_col_calcs();
       }

--- 1101,1108 -----
       struct winsize ws;
  
       if (ioctl(0, TIOCGWINSZ, &ws) >= 0 && ws.ws_row > 0 && ws.ws_col > 0) {
!           if (FORCELINES == 0)
!               LINES = ws.ws_row;
            COLS = ws.ws_col;
            line_col_calcs();
       }

urlichs@smurf.sub.org (Matthias Urlichs) (12/01/90)

In comp.unix.aux, article <1990Nov30.015100.6211@wiskit.pdx.com>,
  herbw@wiskit.pdx.com (Herb Weiner) writes:
<   final_init()
<   {
< + #ifdef _AUX_SOURCE
< + #include <compat.h>
< +     setcompat (COMPAT_BSDSIGNALS | COMPAT_SYSCALLS); /* for Apple A/UX 2.0 */
< + #endif _AUX_SOURCE
< + 
<   #ifdef SIGTSTP

Another way to accomplish this would be to link with the BSD compatibility
library, -lbsd. That would have the advantage of leaving the source intact --
important when the next patch comes along...

NB: The problem also occurs when suspending rn via ^Z.

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330)   \o)/

alexis@panix.uucp (Alexis Rosen) (12/02/90)

Is the first patch mentioned any different from adding the line 
"setsig42();" to init.c? I did this and have had no problems. ^Z now works
fine.

Also, I did not know anything about the compatibility libraries (my knowledge
of A/UX coding is basically non-existent yet...), although I know about the
compiler define switches like _SYSV_SOURCE. Is there a brief and concise
description of stuff like this in one place, or do I need to fish through
the man pages for a year in order to discover everything?

Has anyone fixed the bug introduced in patch 48 with the -L option? It's
not bothersome enough to go hunting for but it would be nice to deal with it.
(SOB knows about it, and says it will be dealt with in the next patch, so
it's not terribly important...)

---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix, NY
{cmcl2,apple}!panix!alexis

urlichs@smurf.sub.org (Matthias Urlichs) (12/04/90)

In comp.unix.aux, article <1990Dec2.014221.12113@panix.uucp>,
  alexis@panix.uucp (Alexis Rosen) writes:
< 
< Also, I did not know anything about the compatibility libraries (my knowledge
< of A/UX coding is basically non-existent yet...), although I know about the
< compiler define switches like _SYSV_SOURCE. Is there a brief and concise
< description of stuff like this in one place, or do I need to fish through
< the man pages for a year in order to discover everything?
< 
Man pages?

There are basically four "compatibility modes" or whatever Apple chooses to
call them:
- A/UX standard stuff (no additional library)
- SysV (use -lsysv)
- BSD (use -lbsd)
- POSIX (use  -lposix)

This is the environment which programs expect when you run them. Obviously,
it doesn't make sense to use more than one of the above. If you need anything
weird, include the appropriate setcompat() call in your program.
(There are some other minor differences, e.g. when enumerating directories.)

Distinguished from this are the various defining flags for cc which make
your C code compile in the first place:

-D_SYSV_SOURCE
-D_BSD_SOURCE
-D_POSIX_SOURCE
-D_AUX_SOURCE

if your program uses any special features from System V, BSD, Posix, or A/UX,
respectively. These can be combined freely.
There are some bugs in the include files; you can't include some of the
Streams stuff without using -D_SYSV_SOURCE or some of the networking code
without -D_POSIX_SOURCE because Apple forgot to replace some of the standard
typedef'd names in the Streams/networking-specific .h files.

Incidentally, Apple seems to have licensing problems with AT&T because Apple
modified all these include files. (AT&T doesn't seem to like that at all.)
These -D_XXX_SOURCE flags are somewhat awkward at first, but very easy to
work with if / as soon as you know what you want to do and what kind of
compile- and runtime environment the programs you're trying to compile expect
-- lots easier than mucking around with "universe" stuff like some other
vendors' Unix.

NB: None of the above applies to the TTY interface, which is System Five
throughout. The odd code which still doesn't have SysV terminal support will
have to be rewritten.
The biggest hassle are programs which don't use "feature flags" but expect
that there's either a -DBSD or a -DSYSV (or -DUSG) in the Makefile which
switches everything around. This is a problem because the A/UX terminal
handling is SysV while the signal handling is BSD. (Mostly.) Fortunately,
programmers learn, and the percentage of new code which does this sort of
thing is decreasing fast.

Disclaimer: All of the above is gross conjecture and should not be taken
seriously.

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330)   \o)/

domo@tsa.co.uk (Dominic Dunlop) (12/04/90)

In article <1990Dec2.014221.12113@panix.uucp> alexis@panix.uucp (Alexis Rosen)
writes:
> Also, I did not know anything about the compatibility libraries (my knowledge
> of A/UX coding is basically non-existent yet...), although I know about the
> compiler define switches like _SYSV_SOURCE. Is there a brief and concise
> description of stuff like this in one place, or do I need to fish through
> the man pages for a year in order to discover everything?

Hey, that must be why I read manuals in the bath: I'm fishing.  

Anyway, the documentation on these ``feature test'' macros is in a
really obvious place: page B-7 in A/UX Programming Languages and Tools,
Volume 1.  Anybody with an ounce of sense should have realised that a
section called A/UX POSIX Environment would be the place to look.
Right?						( :-), needless to say.)

And see also the man pages for cc(1) and setcompat(2), and Section 2,  cc
Command Syntax, in A/UX Programming Languages and Tools, Volume 1.
Setcompat in particular allows you utterly to confuse yourself and your
program.
-- 
Dominic Dunlop

mp@unido.UUCP (Michael Pickers) (12/06/90)

In article <#-1qg2.0-5@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
>Man pages?

Following various discussions about porting software to A/UX I have
the impression that nobody ever took the time to read the man-page of cc(1)
to the end. You should all do that (there is other interesting stuff in
there).

>Distinguished from this are the various defining flags for cc which make
>your C code compile in the first place:
>
>-D_SYSV_SOURCE
>-D_BSD_SOURCE
>-D_POSIX_SOURCE
>-D_AUX_SOURCE

NO! Your not supposed to define that youself! Why do you think that
Apple was so nasty to put those annoying underscores in front of the
defines ?

What you should do instead is using the '-Z' flag of cc. (Ok, you'll have
to read until page 4 of manual to find that...:-) :-)

Here ist the relevant part (not all options shown):
----
	  -Zflags Special flags to override the default behavior (see
		  NOTES in this section).  Currently recognized flags
		  are:
                  S    Compile to be SVID-compatible.  Link the pro-
		       gram with a library module that calls
		       setcompat(2) with the COMPAT_SVID flag set.
		       Define only the SYSV_SOURCE feature test macro.

                  P    Compile for the POSIX environment.  Link the
		       program with a library module that calls
		       setcompat(2) with the COMPAT_POSIX flag set.
		       Define only the POSIX_SOURCE feature test mac-
		       ro.

		  B    Compile to be BSD-compatible.  Link the program
		       with a library module that calls setcompat(2)
		       with the COMPAT_BSD flag set.  Define only the
		       BSD_SOURCE feature test macro.
----

This will not only set the proper define for the preprocessor but also
link your program with the right compatibility library from /lib automaticly.
So you should also remove any -lbsd -lposix or -lsvid options. 

          Michael Pickers
          Computer Science Department, University of Dortmund
          IRB - Informatik Rechner Betriebsgruppe
          4600 Dortmund 50, P.O. Box 500500, W.-Germany
          E-mail address UUCP: mp@unido.uucp (...uunet!mcsun!unido!mp)
          Internet: mp@unido.informatik.uni-dortmund.de
          BITNET: mp@unido.bitnet

urlichs@smurf.sub.org (Matthias Urlichs) (12/06/90)

In comp.unix.aux, article <3112@unido.UUCP>,
  mp@unido.UUCP (Michael Pickers) writes:
< In article <#-1qg2.0-5@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
< >Distinguished from this are the various defining flags for cc which make
< >your C code compile in the first place:
< >
< >-D_SYSV_SOURCE    [...]
< 
< NO! Your not supposed to define that youself! Why do you think that
< Apple was so nasty to put those annoying underscores in front of the
< defines ?
< 
Probably to make sure that they don't collide with anything the program in
question might want to define for itself.

< What you should do instead is using the '-Z' flag of cc. (Ok, you'll have
< to read until page 4 of manual to find that...:-) :-)
< 
< 	  -Zflags Special flags to override the default behavior (see
< 		  NOTES in this section).  Currently recognized flags
< 		  are:
<                   S    Compile to be SVID-compatible.     [...]
<                   P    Compile for the POSIX environment. [...]
< 		    B    Compile to be BSD-compatible.      [...]
< 
< This will not only set the proper define for the preprocessor but also
< link your program with the right compatibility library from /lib automaticly.
< So you should also remove any -lbsd -lposix or -lsvid options. 
< 
Unfortunately, there are some problems with -Zx (for x in [SPB]):
- There doesn't seem to be a way to define more than one flag. For instance,
  as I mentioned in my last posting, the include files for networking can't
  be compiled unless _BSD_SOURCE is defined; same for Streams and _SYSV_SOURCE.
- There doesn't seem to be a way to define _AUX_SOURCE, which you need if you
  want to use some of A/UX's special features. (Grep the include files if you
  need examples.)
- For some hybrid SysV/BSD programs, one compatibility flag alone will still
  create numerous errors. The alternate approach, saying 
  "-D_SYSV_SOURCE -D_BSD_SOURCE" on the cc command line, works very well in
  these cases.
- Which compatibility library, if any, is to be linked in also is a somewhat
  open question which you'll habe to decide by trial and error in some cases.

Lastly, the fact that I decide to do things differently doesn't mean that I
didn't read the man pages.

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330)   \o)/

jim@jagubox.gsfc.nasa.gov (Jim Jagielski) (12/06/90)

In article <%4yrg2."da@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
 ->In comp.unix.aux, article <3112@unido.UUCP>,
 ->  mp@unido.UUCP (Michael Pickers) writes:
 ->< In article <#-1qg2.0-5@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
 ->< >Distinguished from this are the various defining flags for cc which make
 ->< >your C code compile in the first place:
 ->< >
 ->< >-D_SYSV_SOURCE    [...]
 ->< 
 ->< NO! Your not supposed to define that youself! Why do you think that
 ->< Apple was so nasty to put those annoying underscores in front of the
 ->< defines ?
 ->< 
 ->Probably to make sure that they don't collide with anything the program in
 ->question might want to define for itself.
 ->


Yeah, but aren't -D_BSD_SOURCE and -D_SYSV_SOURCE "set" by default by cpp?

I think they are.
--
=======================================================================
#include <std/disclaimer.h>
                                 =:^)
           Jim Jagielski                    NASA/GSFC, Code 711.1
     jim@jagubox.gsfc.nasa.gov               Greenbelt, MD 20771

"Kilimanjaro is a pretty tricky climb. Most of it's up, until you reach
 the very, very top, and then it tends to slope away rather sharply."

urlichs@smurf.sub.org (Matthias Urlichs) (12/07/90)

In comp.unix.aux, article <4104@dftsrv.gsfc.nasa.gov>,
  jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes:
< 
< Yeah, but aren't -D_BSD_SOURCE and -D_SYSV_SOURCE "set" by default by cpp?
< 
< I think they are.

Umm, yes they are -- by Apple's cpp.

However, the gcc front end on wuarchive only defines _AUX_SOURCE and I didn't
yet have the time to ftp the sources and change it.

The second problem is that just as there are some programs which need the
appropriate flags, some need them undefined... :-(

Playing around with compiler options instead of fixing the sources isn't a
good idea in the general case, of course -- but kludging a programs into
compiling and running correctly usually is somewhat faster than having to dig
around in the source code and fix the program's portability problems.

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330)   \o)/

coolidge@cs.uiuc.edu (John Coolidge) (12/07/90)

jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes:
> ->< >Distinguished from this are the various defining flags for cc which make
> ->< >your C code compile in the first place:
> ->< >
> ->< >-D_SYSV_SOURCE    [...]
> ->< 
> ->< NO! Your not supposed to define that youself! Why do you think that
> ->< Apple was so nasty to put those annoying underscores in front of the
> ->< defines ?
> ->< 
> ->Probably to make sure that they don't collide with anything the program in
> ->question might want to define for itself.

>Yeah, but aren't -D_BSD_SOURCE and -D_SYSV_SOURCE "set" by default by cpp?

>I think they are.

Yes, you're right. In fact, all four (BSD, SYSV, AUX, and POSIX) are
set by default by cpp. CC turns off the ones it doesn't like.

Gnu cpp in the current version defines none of them by default. My
opinion is that _AUX_SOURCE should turn on more things than it does,
and that _BSD_SOURCE, _SYSV_SOURCE, and _POSIX_SOURCE should be
reserved for things that are in fundamental confict with each other.
The current situation, where _BSD_SOURCE and _SYSV_SOURCE both need
to be defined in order to compile a number of programs, is wrong.

--John

--------------------------------------------------------------------------
John L. Coolidge     Internet:coolidge@cs.uiuc.edu   UUCP:uiucdcs!coolidge
Of course I don't speak for the U of I (or anyone else except myself)
Copyright 1990 John L. Coolidge. Copying allowed if (and only if) attributed.
You may redistribute this article if and only if your recipients may as well.