I'm pondering about implementing pkill like functionality in kill,
instead of introducing a new command specific for the purpose. My
idea is basicly to make `kill' accept a name instead of just a pid, so
the command would look something like:
kill [-s SIG | -SIGNAL] PID | NAME
Personally, I
Alfred M\. Szmidt [EMAIL PROTECTED] writes:
kill [-s SIG | -SIGNAL] PID | NAME
Personally, I think this makes more sense than introducing pkill (or
for that matter, killall). And is cleaner. What do people think
about this?
Most people use the builtin kill command of the shell, so you'll
Most people use the builtin kill command of the shell, so you'll
have to change Bash as well as coreutils.
I wish that bash would remove all those builtins, or only use them if
a such a builtin doesn't exist on the system.
bash has the enable builtin which lets you disable builtins:
Remember, POSIX requires kill(1) to be a shell builtin, because it
must support job syntax (kill %1, for example), which cannot be
done with normal POSIX child process semantics.
In that case, one can make the builtin kill a wrapper, that parses the
command line, and if it see %1 it
[EMAIL PROTECTED] (Eric Blake) writes:
Remember, POSIX requires kill(1) to be a shell builtin, because it
must support job syntax (kill %1, for example), which cannot be
done with normal POSIX child process semantics.
In that case, one can make the builtin kill a wrapper, that
Write your own shell function that does just that.
Nice, but I'd rather have it default in bash. Might just patch that
horrid beast...
True. But in this case, it doesn't make it wrong, either. Another
argument for making kill a builtin is if you hit your ulimit on max
processes,
