Porting rc to Linux

[jeremy@sw.oz.au (Jeremy Fitzhardinge)]

I didn't anticipate any problems, but there were a few:

Linux has real ansi headers in /usr/include, so it wasn't necessary to use
the face prototypes in proto.h, and it was undesireable to do so since
the compiler whined about inconsistencies.  I added a new configuration
flag GOODHEADERS that makes proto.h include system headers rather than
define prototypes.

Rc has the "mksignal" script to extract signal names and descriptions from
/usr/include/sys/signal.h.  This didn't work on linux for two reasons:
	/usr/include/sys/signal.h just includes <linux/signal.h> (in
	the kernel source tree).

	linux/signal.h doesn't have comments after each #define describing
	the signal.
I just made mksignal look at a fake signal.h when running under Linux.
A better solution might be to use the sys_siglist array which has
the name to number mapping of the signal names, if not a text description.

They were the easy problems, that prevented compilation.  The subtle
one was in which.c.  Under linux gid_t is defined as an
unsigned short, and getgroups() takes a pointer to gid_t as its second
argument. rc uses an array of ints for the group list, so it got a list
of bad groups.  This meant that rc wouldn't exec a file that was group
executable only and the group was in the user's supplimentary list.

When searching the path, why does rc try to double guess the kernel
by testing the permissions itself rather than just trying to exec it?
And if it has to (whatis), why doesn't it just use the access system
call rather than doing it for itself in rc_access?  The comment
says "does the right thing for group-executable files" - does access()
not work correctly on other Unicies in this case?

	J