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

Bug#288322: marked as done (pdksh: doesn't handle suspension of commands in conditional lists correctly)



Your message dated Wed, 27 Jun 2012 11:03:54 +0000 (UTC)
with message-id <Pine.BSM.4.64L.1206271103120.3110@herc.mirbsd.org>
and subject line pdksh: doesn't handle suspension of commands in conditional lists correctly
has caused the Debian Bug report #288322,
regarding pdksh: doesn't handle suspension of commands in conditional lists correctly
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 owner@bugs.debian.org
immediately.)


-- 
288322: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288322
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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


--- End Message ---
--- Begin Message ---
Hi,

thanks Dieter for the explanation. I also think this is not
user-friendly, but it’s kept at upstream as feature request
for now.

bye,
//mirabilos
-- 
13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good
guy. But he's always right! In every fsckin' situation, he's right. Even
with his deeply perverted taste in software and borked ambition towards
broken OSes - in the end, he's damn right about it :(! […] works in mksh


--- End Message ---

Reply to: