|
From: | Brian K. White |
Subject: | Re: bashisms |
Date: | Wed, 19 May 2010 05:51:40 -0400 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 |
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.htmlhttp://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.hSo, 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
[Prev in Thread] | Current Thread | [Next in Thread] |