[PATCH] ash.c: repairing kill for susv3

[Denis Vlasenko]

Hello Mats,

Sorry for late reply

On Wednesday 18 April 2007 20:18, Mats Erik Andersson wrote:
> My very first patch for ash.c could only fix the builtin
> call "kill -l", whereas the second patch digressed from
> the intended Susv3 compatibility. I would like to aim
> at the SuSv3 standard with this third patch.
> 
> The intention is to implement a functionality displayed
> in the help text as
> 
> 	kill -l exitstatus
> 
> where SuSv3 says "exitstatus" should be a numerical value
> and may denote a valid signal, which should then be returned
> as its ascii name.
>  
> There are two lines in shell/ash.c.svn that prevents any
> success of reaching that functionality:
> 
> 3582:   name = get_signame(signo);
> 3583:   if (!isdigit(*name))

I propose (a) nuking builtin kill from ALL shells we have.
(b) make them call kill applet (grep for 'bb_cat' for an example
how to reuse one applet's internals from other applets),
and (c) fix any SuSv3 incompatibilities in kill applet.

This way we won't be forced to fix kill five times.

kill from coreutils-6.8 is probably SuSv3 compliant or very
close to it. On my system it gives:

# /usr/bin/kill -l
HUP
INT
...
RTMAX-1
RTMAX
# /usr/bin/kill -l 1
HUP
# /usr/bin/kill -l 0
EXIT
# /usr/bin/kill -l INT
2

And -t is

# /usr/bin/kill -t
 1 HUP      Hangup
 2 INT      Interrupt
 3 QUIT     Quit
...
63 RTMAX-1  Real-time signal 29
64 RTMAX    Real-time signal 30
# /usr/bin/kill -t 1
 1 HUP      Hangup
# /usr/bin/kill -t 0
 0 EXIT     Unknown signal 0
# /usr/bin/kill -t INT
 2 INT      Interrupt

Thus -t is just a "verbose" variety of -l

Now, busyboxed kill:

bash-3.2# /bin/kill -t
kill: bad signal name 't'

No luck with -t (is it in SuSv3 at all, btw?)

# /bin/kill -l
 1) HUP    2) INT    3) QUIT   4) ILL    5) TRAP   6) ABRT   8) FPE
 9) KILL  10) USR1  11) SEGV  12) USR2  13) PIPE  14) ALRM  15) TERM
17) CHLD  18) CONT  19) STOP  20) TSTP  21) TTIN  22) TTOU
# /bin/kill -l 0
 0) EXIT
# /bin/kill -l HUP
 1) HUP
# /bin/kill -l EXIT
 0) EXIT

Our -l looks similar to coreutils' -t option.

Overall fixing kill to match -l (and maybe -t) behaviour of coreutils
doesn't look like unsurmountable task.

> However, I have not been able to understand beyond any doubt
> whether SuSv3 intends a use like "kill -l $?" and a corresponding
> printing of named exit statuses. The printout EXIT does at
> present appear, on the other hand, and is related to a TODO-remark
> of Rob Landley inside libbb/u_signal_names.c.

I think it simply means "treat signal# 0 as 'EXIT', and vice versa".
--
vda