Subject: Re: Killing processes by name
To: None <current-users@NetBSD.ORG>
From: Greg Earle <earle@isolar.Tujunga.CA.US>
Date: 04/10/1996 14:42:40
> earle@isolar.Tujunga.CA.US (Greg Earle)wrote:
>> Speaking of killing processes by name, if we can replace more(1) with a
>> slightly hacked less(1), surely we can replace kill(1) with Jeff Forys'
>> skill(1) as well? It kills by user name, tty name, etc. and so on, and is
>> a complete superset of kill(1).
> IMHO, "less" is used for the job of "more" not because it has more
> features, but because it is the best implementation of the
> functionality of *basic* "more". There is no lighter implementation for
> the basic job.
Huh? It's *bigger* than the normal "more". It's used because it's WAY better
than "more" and it fixes more's more egregious faults, e.g. the inability to
go backwards (and continued inability to go backwards if reading from a pipe
on later versions of "more"), and the complete messing up of auto-wrapped text
that spills over 80 columns.
> 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".
> 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".
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.)
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.