Greg Earle sez:

#  > The basic job of "kill" is to kill by PID and I don't see why "skill"

#  Since when?  The man page says

#	   kill - terminate or signal a process

#  It doesn't say "terminate or signal a process BY PID".

Killing by pid is the simplest way to go.  If you want skill, fine, but
don't necessarily make it a replacement for /bin/kill.

#  > is better here.  Here we have a lighter altenative.  I often have to use
#  > "kill" in critical situations where every u-sec of startup time counts and
#  > have a statically-linked binary on emergency setups where every Kb of
#  > disk/floppy space counts.

#  Are you using "kill" in "critical situations" where you're running a C
#  Shell?  If so, it's already *built in* to that shell.  And statically-linked
#  binaries are *larger*, so that's at odds with "where every Kb disk/floppy
#  space counts".

That paragraph contained a dichotomy.  What's the statically-linked thing
got to do with c-shell builtins?  Oh, I see -- it's two separate things,
sorry, got confused...

#  The only good reason I can think for rejecting "skill" as a "kill"
#  replacement is due to the restriction that "/bin/kill" be a
#  statically-linked executable.  (Interestingly, /usr/bin/kill on SunOS is a
#  pure dynamically-linked binary.)

So is /usr/etc/mknod, but that doesn't make it the right thing to do.
[ask me why this is bad if you can't figure it out.]

#  Most of the "code bloat" of "skill" comes from sucking in static libraries.
#  A stripped dynamically-linked (against -lc and -lkvm) "skill" binary is 32
#  Kb on my NetBSD/SPARC 1.0 system.  If it's pure (a la SunOS's), it's only 18
#  Kb.  And you get the super renice'er along for the ride.
#  It's only when it's *required* to be statically-linked does it become a
#  lose.

#	   - Greg

Most of the "code bloat" of "csh" comes from sucking in static libaries.
In fact, "sh" is more bloated than "csh" is!  And "sh" is required
to be statically linked no matter WHAT system you're on (otherwise you
have no single-user mode).

s/csh/fsck/g
s/fsck/init/g

etc...

I think what kills "kill" here is the presence of all the option checking.
If it weren't for that it would probably not be quite so big.  A kill
which simply accepted "kill [-signum] pid ..." would be quite compact,
but all the POSIX overhead bloats it.

#define TANGENTIALLY_RELATED
IMNSHO, SunOS goofed, and BSD had it right from the start.  The root 
filesystem should be small, yes, but it should be self-sufficient.
Under SunOS, the root filesystem is barely usable -- the system REQUIRES
/usr, even in single-user mode!  If /usr is hosed, you're SOL.  No
edit capability, no NOTHING under SunOS.
#undef TANGENTIALLY_RELATED

				--*greywolf;
-- 
Friends don't let friends use Windows NT.