[Top][All Lists]

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

Re: Portability problems in autoconf manual

From: Ralf Wildenhues
Subject: Re: Portability problems in autoconf manual
Date: Fri, 12 Jun 2009 08:21:43 +0200
User-agent: Mutt/1.5.19 (2009-06-09)

* Eric Blake wrote on Wed, Jun 10, 2009 at 02:41:21PM CEST:
> According to Ralf Wildenhues on 6/8/2009 2:59 PM:
> > 
> > If I understand this correctly, then there are one, or even two ways to
> > portably reset traps to their default value: either use reset only one
> > signal at a time:
> > 
> >   trap 1; trap 2; trap 13; trap 15
> Remember, POSIX 2001 specified that you use either 0 arguments or 2 or
> more, but left the use of exactly one argument undefined.

Ah.  However, we care not about POSIX requirement, but about portability
in practice.  So, the question is how portable is the above in practice?

> $ posh -c 'trap : 0; trap; trap 0; trap; echo done'
> trap -- : EXIT
> posh: trap: no signals specified
> $ echo $?
> 1
> But posh is already the oddball, as (depending on the version) it requires
> names instead of numbers (although I know that has already been brought up
> with the debian folks).

Look, the only reason for the existence of posh is to act as a torture
device for developers that do not write portable software.  If we have
code that is portable in practice, but fails with posh, then almost by
definition, that is a bug in posh, not in our code.  (You could even
interpret that as QoI issue in POSIX in that case.  :-)

More generally, if somebody starts using the heirloom sh as their
/bin/sh on their brand new Linux system, and then starts filing bug
reports against shell scripts that work portably on all relevant hosts,
then I'm very much inclined to not add workarounds to Autoconf, unless
there is also at least one non-museum system that exhibits the same
issues.  Moreover since the source code of those shells is available,
they should just be fixed instead.  (We should recommend to those people
to use the Autoconf testsuite as part of their shell release testing.)

> > or factor the code based on whether the shell groks resetting of traps
> > with a numeric first argument (and assuming it will accept '-'
> > otherwise):
> You are on to something here.  Notice that we don't even have to worry
> about whether 0 is a command or alias, if we insist on doing things one
> trap at a time and rely on the syntax error of posh as the determining
> factor instead:
> if (trap 0) 2>/dev/null ; then
>   trap 0; trap 1; trap 2
> else
>   trap - 0 1 2
> fi
> In my testing, this worked for Solaris /bin/sh, dash, bash, zsh, pdksh,
> and posh, modulo posh's need for signal names.  Anyone have a
> counterexample, before I publish this as a portable way to reset traps?

Haven't found any.

> Unfortunately, we cannot wrap this logic in an ease-of-use function:

Yes, we can't.

> since using trap inside a function does not properly affect the outer
> environment, on at least zsh (even with emulate sh).
> But we COULD make an AS_TRAP_DEFAULT macro that uses m4 expansion time to
> break a list into multiple calls as needed.

Yep.  :-)


reply via email to

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