Package: bash
Version: 3.0-10
Severity: normal
I'd consider raising the severity, given the amount of pain this has
caused me, and because it's a common case, and because it mostly
defeats the purpose of trap - but there's an easy workaround *and* the
bug has been around for years. (As such, please forward it upstream;
I'm sending it via debian primarily for the tracking, and to give
people a chance to think about other packages using trap in config
scripts.)
trap, with a *single*, *non-builtin* command, and a signal_spec of 0,
trashes the exit status.
The case where I found this was a build script using it for a
"try/finally" cleanup, namely
/bin/sh -c '... create file ... trap "rm -f file" 0; configure && build &&
install'
the idea being that if any of configure/build/install fail, the shell
line fails, but the rm occurs. What was noticed originally was that
the build would continue.
It turns out that there's a workaround: make sure that the trap
command is more than one statement. Adding "; true" after the rm is
sufficient, as is wrapping the command in ().
The reduction of the broken case to something easy to try:
$ /bin/bash -c 'trap "/bin/echo" 0 && false'; echo STATUS: $?
STATUS: 0
Examples of other cases which are very similar, but which pass the
false status through correctly:
Two commands:
$ /bin/bash -c 'trap "/bin/echo;/bin/echo" 0 && false'; echo STATUS: $?
STATUS: 1
A builtin, instead of a command:
$ /bin/bash -c 'trap "echo" 0 && false'; echo STATUS: $?
STATUS: 1
Grouping the command with ():
$ /bin/bash -c 'trap "(/bin/echo)" 0 && false'; echo STATUS: $?
STATUS: 1
Appending a builtin:
$ /bin/bash -c 'trap "/bin/echo; true" 0 && false'; echo STATUS: $?
STATUS: 1
The above bug is consistent on
GNU bash, version 2.05.0(1)-release (sparc-sun-solaris2.9) [Solaris 9]
GNU bash, version 3.00.16(1)-release (i386-pc-linux-gnu) [debian sarge]
GNU bash, version 2.05a.0(1)-release (i386-pc-linux-gnu) [debian woody]
Note that /bin/sh on Solaris 9 reports "STATUS: 255" for all of these;
/usr/xpg4/bin/sh reports "STATUS: 1".
For another angle on the same bug, though perhaps not a clarifying one
(because exit is a builtin...):
$ /bin/bash -c 'trap "exit 42" 0 && exit 33'; echo STATUS: $?
STATUS: 42
$ /bin/bash -c 'trap "(exit 42)" 0 && exit 33'; echo STATUS: $?
STATUS: 33
This may, however, be a *different* bug given that some of the other
workarounds don't impact it.
Using /bin/sh instead of /bin/bash doesn't change anything (ie. posix
mode doesn't matter.)
dash/ash does not exhibit the bug either.
I note that the dpkg scripts already have a different workaround for it:
info/dpkg.preinst:18:trap 'es=$?; rm -f /var/lib/dpkg/bp.$$; exit $es' 0
A quick look at dpkg scripts installed on my system (not a
comprehensive archive scan by any means) turns up these cases where
this bug could mask a postinst failure; I haven't dug deeply enough to
tell if they actually lead to bugs or not, though.
info/w3m.postinst:18: trap "rm -f $tmp" 0 1 2 15
info/postgresql.preinst:121:trap "rm -f $TMPFILE" 0
info/tpconfig.postinst:77: trap "clean_temp_files" EXIT INT QUIT TERM
_Mark_ <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.13.2toughbook
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages bash depends on:
ii base-files 3.1.2 Debian base system miscellaneous f
ii libc6 2.3.5-6 GNU C Library: Shared libraries an
ii libncurses5 5.4-4 Shared libraries for terminal hand
ii passwd 1:4.0.3-31sarge5 change and administer password and
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
