bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bashisms


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.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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]