Subject: bash: doesn't handle suspension of commands in conditional lists correctly
Date: Sun, 02 Jan 2005 20:54:31 -0500
Package: bash
Version: 3.0-12
Severity: important
Things like:
foo && bar && baz
are a basic POSIX shell feature, and Bash doesn't handle them right.
Try:
echo one && sleep 10 && echo two
While, in the sleep, background the command with CTRL-Z.
The 'echo two' will run immediately. This is wrong. The sleep has no exit
status yet because it has not exited, and the && and || connectives must
only be evaluated once the preceding command has exited. Until then, the
command in question *has* no exit status. The box with Schroedinger's Cat
in it has not yet been opened.
ash, dash, pdksh, and zsh are also buggy, but instead they never run "echo
two" at all. It appears that of Debian's allegedly POSIX-compliant shells
have this problem, except for posh.
Here are some speculations/argument from #debian-devel as to what may be
going on:
08:42PM|<asuffield> Overfiend: what you have in bash is bloody broken
conditionals. I can't see how to fix it, and I can't stand looking
at bash any longer to figure it out
08:42PM|<asuffield> it passes WUNTRACED to wait() when job control is
enabled, so that it can spot jobs which have been sent SIGSTOP
08:43PM|<asuffield> somewhere in the pipeline logic is a missing check
for WIFSTOPPED on the status code, to see if the process is really
dead yet or not
08:49PM|<asuffield> look, WSTOPCODE() and WEXITCODE() are the same
macro. zsh is calling WEXITCODE() and treating it as the exit code,
and this is *INCORRECT*, because WIFEXITED() is false and WIFSTOPPED()
is true
08:51PM|<Keybuk> and zsh documents that it won't continue a pipeline if
the process is terminated by an unhandled signal
08:52PM|<Keybuk> so zsh is being correct, just different to bash
08:52PM|<asuffield> zsh has incorrectly interpreted the result from wait()
as if the process had been terminated
08:52PM|<asuffield> the process has been stopped. this is a different
event
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: powerpc (ppc)
Kernel: Linux 2.4.25-powerpc-smp
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages bash depends on:
ii base-files 3.1.2 Debian base system miscellaneous f
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libncurses5 5.4-4 Shared libraries for terminal hand
ii passwd 1:4.0.3-30.7 Change and administer password and
-- no debconf information
Subject: Re: Bug#288319: bash: doesn't handle suspension of commands in conditional lists correctly
Date: Wed, 5 Jan 2005 20:28:34 +0000
forwarded 288321 upstream
thanks.
Hi Herbert, please see below. This, I think, indeed can be taken as
unexpected behavior; I don't see how it can easily be changed though.
Some others already commented on this issue:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288319http://www.zsh.org/mla/workers/2004/msg01294.html
Thanks for the report, Branden. Regards, Gerrit.
On Sun, Jan 02, 2005 at 08:54:31PM -0500, Branden Robinson wrote:
> Things like:
>
> foo && bar && baz
>
> are a basic POSIX shell feature, and Bash doesn't handle them right.
>
> Try:
>
> echo one && sleep 10 && echo two
>
> While, in the sleep, background the command with CTRL-Z.
>
> The 'echo two' will run immediately. This is wrong. The sleep has no exit
> status yet because it has not exited, and the && and || connectives must
> only be evaluated once the preceding command has exited. Until then, the
> command in question *has* no exit status. The box with Schroedinger's Cat
> in it has not yet been opened.
>
> ash, dash, pdksh, and zsh are also buggy, but instead they never run "echo
> two" at all. It appears that of Debian's allegedly POSIX-compliant shells
> have this problem, except for posh.
>
> Here are some speculations/argument from #debian-devel as to what may be
> going on:
>
> 08:42PM|<asuffield> Overfiend: what you have in bash is bloody broken
> conditionals. I can't see how to fix it, and I can't stand looking
> at bash any longer to figure it out
> 08:42PM|<asuffield> it passes WUNTRACED to wait() when job control is
> enabled, so that it can spot jobs which have been sent SIGSTOP
> 08:43PM|<asuffield> somewhere in the pipeline logic is a missing check
> for WIFSTOPPED on the status code, to see if the process is really
> dead yet or not
> 08:49PM|<asuffield> look, WSTOPCODE() and WEXITCODE() are the same
> macro. zsh is calling WEXITCODE() and treating it as the exit code,
> and this is *INCORRECT*, because WIFEXITED() is false and WIFSTOPPED()
> is true
> 08:51PM|<Keybuk> and zsh documents that it won't continue a pipeline if
> the process is terminated by an unhandled signal
> 08:52PM|<Keybuk> so zsh is being correct, just different to bash
> 08:52PM|<asuffield> zsh has incorrectly interpreted the result from wait()
> as if the process had been terminated
> 08:52PM|<asuffield> the process has been stopped. this is a different
> event
>
> -- System Information:
> Debian Release: 3.1
> APT prefers unstable
> APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: powerpc (ppc)
> Kernel: Linux 2.4.25-powerpc-smp
> Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>
> Versions of packages bash depends on:
> ii base-files 3.1.2 Debian base system miscellaneous f
> ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
> ii libncurses5 5.4-4 Shared libraries for terminal hand
> ii passwd 1:4.0.3-30.7 Change and administer password and
>
> -- no debconf information
>
>
> --
> To UNSUBSCRIBE, email to [email protected]
> with a subject of "unsubscribe". Trouble? Contact [email protected]
>
--
Open projects at http://smarden.org/pape/.
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.