On Wed, Mar 19, 2008 at 1:50 PM, Jos Vos <[EMAIL PROTECTED]> wrote:
> Hi,
>
> It seems that bash's built-in kill behaves different from /bin/kill,
> ksh's kill, and from what I would expect (this happens in all the
> versions of bash that I tested).
>
[EMAIL PROTECTED] ~]$ which kill
/usr/bin/kill
[EMAIL PROTECTED] ~]$ ls -l /bin/kill /usr/bin/kill
-rwxr-xr-x 1 root root 11168 Nov 30 15:35 /bin/kill*
lrwxrwxrwx 1 root root 14 Dec 3 14:17 /usr/bin/kill -> ../../bin/kill*
[EMAIL PROTECTED] ~]$
I do not see it as a builtin. Is there a
Or are you talking about this from man bash:
SIGNALS
When bash is interactive, in the absence of any traps, it ignores
SIGTERM (so that kill 0 does not kill an interactive shell), and SIGINT
is caught and handled (so that the wait builtin is interruptible). In
all cases, bash ignores SIGQUIT. If job control is in effect, bash
ignores SIGTTIN, SIGTTOU, and SIGTSTP.
> What I would expect (and what /bin/kill a.o. seem to do):
> kill -0 <PIDS> fails if one or more of the pid parameters is invalid
>
> What bash does:
> kill -0 <PIDS> succeeds if one or more of the pid parameters is valid
>
> I couldn't find a complete spec of what is correct/wrong in any formal
> UNIX spec till now.
>
> Comments?
>
> --
> -- Jos Vos <[EMAIL PROTECTED]>
> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
> -- Amsterdam, The Netherlands | Fax: +31 20 6948204
>
> _______________________________________________
> rhelv5-list mailing list
> rhelv5-list@redhat.com
> https://www.redhat.com/mailman/listinfo/rhelv5-list
>
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
_______________________________________________
rhelv5-list mailing list
rhelv5-list@redhat.com
https://www.redhat.com/mailman/listinfo/rhelv5-list
