On 5/19/2010 2:30 AM, Ralf Wildenhues wrote:
Hello Ian,
* Ian Beckwith wrote on Wed, May 19, 2010 at 03:54:52AM CEST:
* trap with signal numbers
According tohttp://www.opengroup.org/onlinepubs/009695399/utilities/trap.html
(btw, am I right in saying "The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition" is POSIX, or at least a part of
it?),
Not technically, no, but practically, yes. IIRC.
POSIX requires signals specified as names (HUP, INT, etc),
although XSI allows numbers for certain signals (the ones used by
gnulib all fall into this category).
We've had a similar discussion about this on an Autoconf list a while
ago (with a Debian maintainer). The Autoconf manual, Shell Portability
chapter, lists 1 2 13 15 as signals which are safe to trap. I'm not
aware of any shell which does not accept these signal numbers in
practice, except for maybe one that was written specifically to inflict
extra pain upon shell script authors by explicitly disallowing them.
I would have thought the portability concern would be the meanings of
the numbers more than the allowance of numbers in the syntax.
Even within a single OS linux, even within a single version, the
meanings of signals above 16 differ between platforms/architectures.
However, as for syntax, at least SCO Open Server /bin/sh _only allows
numbers_, and only in the range 0-16 , where 0 is a special case that
happens on exit from the shell and 11 (SEGV) is a special case that just
produces an error.
The signals above 16 vary widely. But the signals from 1-16 are not the
same across systems either.
Just comparing SCO Open Server 5.0.7 and current Linux 2.6 x86_64, I
find these differences in the 1-16 range:
7:
sco: #define SIGEMT 7 /* EMT instruction */
linux: #define>SIGBUS 7 /* BUS error (4.2 BSD). */
also, Old linux: SIGUNUSED
10:
sco: #define SIGBUS 10 /* bus error */
linux: #define SIGUSR1 10 /* User-defined signal 1 (POSIX). */
12:
sco: #define SIGSYS 12 /* bad argument to system call */
linux: #define SIGUSR2 12 /* User-defined signal 2 (POSIX). */
16:
sco: #define SIGUSR1 16 /* user defined signal 1 */ (I happen to
know at least this one was the same at least as far back as SCO Xenix
386 2.2)
linux: #define SIGSTKFLT 16 /* Stack fault. */
(Open Server only has one platform, i386, and the signal definitions at
least for 1-16 have not changed since at least as far back as Xenix286
(yes 286), if you allow for the fact that although ABRT has replaced
IOT, to this day both are still defined and both are still 6)
refs:
SCO:
http://osr507doc.sco.com/en/man/html.C/sh.C.html
http://osr507doc.sco.com/en/man/html.M/signal.M.html (unfortunately the
table is munged by the conversion from troff to html and a cell was lost
or a row injected injected after 04, so after 04 the cells are just
shifted off by one, but I have access to real osr5 boxes and signal.h
matches the ancient xenix doc below. The SCO Unixware version is NOT
munged and also
matches:http://uw714doc.sco.com/en/man/html.5/signal.5.html but unixware
is an entirely different OS and so that doc proves nothing about Open
Server by itself.)
http://www.tenox.tc/docs/sco_xenix_sysv286_programmers_reference.pdf p.501
Linux, FreeBSD, Solaris:
http://fxr.watson.org/fxr/source/sys/signal.h
So, it's right to not want to use numbers as their meanings are all over
the place, even for 1-16, but at least one standard shell only allows
numerical arguments. So we are down to what you are already are doing,
which is using numbers and only a certain few special numbers at that.
--
bkw
