Your message dated Mon, 25 Mar 2024 15:13:12 +0100
with message-id <516a676e-03fe-42a7-85b2-6426ce0c7...@svario.it>
and subject line Re: Bug#336224: bash: trap with one command trashes exit status
has caused the Debian Bug report #336224,
regarding bash: trap with one command trashes exit status
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
336224: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336224
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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_ <eic...@metacarta.com>
<eic...@thok.org>
-- 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
--- End Message ---
--- Begin Message ---
Version: 5.0-6
On Fri, 28 Oct 2005 14:20:17 -0400 (EDT) eic...@metacarta.com wrote:
Package: bash
Version: 3.0-10
Severity: normal
trap, with a *single*, *non-builtin* command, and a signal_spec of 0,
trashes the exit status.
[...]
The reduction of the broken case to something easy to try:
$ /bin/bash -c 'trap "/bin/echo" 0 && false'; echo STATUS: $?
STATUS: 0
Hi,
this issue does not seem to affect version 5.0-6 and later of bash.
$ /bin/bash -c 'trap "/bin/echo" 0 && false'; echo STATUS: $?
STATUS: 1
Please reopen this bug if you can still reproduce this issue.
Regards,
--
Gioele Barabucci
--- End Message ---
