[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 18 Aug 2001 11:27:07 +0200
On Sat, Aug 18, 2001 at 09:01:06AM +0200, Jim Meyering wrote:
> Have you considered the one in the procps package?
Only about a second ;) Neal already convered that in his reply.
Some time ago, the one in the procps was changed to require the Linux
procfs. I don't know if this was changed back.
> What about this?
> $ sudo bash -c 'kill ...'
There is at least one package (db3) which checks for /bin/kill in configure.
One could probably argue that it is a bug, but it seems the moral of the
story is a different: That people expect there to be a kill binary.
Are you reluctant because it is a lot of work to write a portable kill, or
because there are other reasons as well? As there already is a portable
kill in bash, there is probably nothing we can't find out by just looking at
it, and maybe some parts in bash are directly usable (for example, how to
get a list of all signals). In general, I am not unwilling to do the work,
but I don't consider me to be an expert on portability, and I could only
test it on GNU/Linux, Linux, FreeBSD and SunOS, and others only on more
input by people (like you ;) who can tell me what broken assumptions I made.
Do you envision other potential portability problems than getting the signal
Depending on how you feel about it, it would also work for us if you build
the kill only on the GNU system, until other people start to get interested
in it as well. This is probably not necessary, but I mention it for
The alternative is to put kill in the Hurd package, but we don't have any
clever ideas how to extend it in a hurdish way, and we feel that shellutils
is a much better place.
`Rhubarb is no Egyptian god.' Debian http://www.debian.org address@hidden
Marcus Brinkmann GNU http://www.gnu.org address@hidden
- kill, Marcus Brinkmann, 2001/08/16
- Re: kill, Jim Meyering, 2001/08/18
- Re: kill, Neal H Walfield, 2001/08/18
- Re: kill,
Marcus Brinkmann <=