Thanks for the quick replies everyone. It sounds like "kill -l" is the best portable way to deal with signals' exit statuses. I never saw the Rationale section of the standard. I wonder if the standard was influenced by ksh here? ________________________________________ From: David Korn [[email protected]] Sent: Friday, March 15, 2013 8:25 AM To: Alan Somers; [email protected] Subject: Re: [ast-users] ksh93 returns exit statuses > 256 for commands killed by a signal
cc: [email protected] Subject: Re: [ast-users] ksh93 returns exit statuses > 256 for commands killed by a signal -------- > I noticed that when a command run by ksh93 is killed by SIGABRT, it returns > an e > xit status of 262. This is contrary to the behavior of dash, bash, zsh, csh, > tc > sh, and mksh, which all return 134. It also seems contrary to the sus, which > sp > ecifies that "the special parameter '?', the shell shall report the full > eight b > its of exit status available". Is this a bug or is the behavior intentional? > I > tested it on FreeBSD 9.1 and Ubuntu 11.10, both on amd64. > > # /bin/sleep 20 # From another terminal, type "kill -6 the_pid_of_sleep" > Abort(coredump) > # echo $? > 262 > # ksh93 --version > version sh (AT&T Research) 93u+ 2012-08-01 > > > http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_ > 08_02 > In section 2.8.2 it states that the exit status for a command that terminates with a signal is greater an 128. However, in the rationale for this section, it states, "Implementations are encourated to choose an exit status greater than 256 to indicate programs that terminate by a signal so that the exit status cannot be confused with an exit status generated by a normal termination." ksh93 uses 256+signo, and if you do kill -l $? for an exit status > 256, it will give you the name of the signal. $ kill -l 262 ABRT David Korn [email protected] _______________________________________________ ast-users mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-users
