[Pkg-zsh-devel] Bug#288323: Debian zsh bug triage

[Vincent Lefevre]

On 2009-01-21 17:53:01 +0100, Richard Hartmann wrote:
> Bump email
> 
> There is an actual thread below this email. See
> http://www.zsh.org/mla/workers/2008/msg01850.html
> 
> I still think choice 1 meets users expectations best and is the safest
> thing to do. Maybe offer this as an option?

I disagree with choice 1, even though zsh behaves like that for
functions (unlike other shells), so that side effects no longer
affect the current shell when the function has been suspended.
There's at least a documentation problem.

I've reported the following bug about functions:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660630

> On Mon, Dec 29, 2008 at 21:46, Richard Hartmann
> <richih.mailinglist at gmail.com> wrote:
> > Hi all,
> >
> > I am triaging bugs in Debian's BTS [1] and the first two things that are
> > still valid are (both have been on zsh-workers, the first in 2004, the
> > second in 2005):
> >
> > 2) Unexpected behaviour when stopping a job in a command chain[3]
> >
> > Consider this:
> >
> > echo one && sleep 10 && echo two
> >
> > When stopping `sleep 10`, `echo two` will never be executed, no matter in
> > what way you revive `sleep 10`. That is OK as backgrounding `sleep 10`
> > will set $? to 20. Yet, with
> >
> > echo one ; sleep 10 ; echo two
> >
> > the same thing happens. As Bart pointed out[4]:
> >
> >> Given "one && two && three", if "two" stops, the shell has three choices:
> >> (1) pretend the command was "{ one && two && three }" and suspend the
> >>     entire sublist; or
> >> (2) pretend that "two" has returned a status and continue the junction; or
> >> (3) stop the entire shell until "two" is resumed.
> >
> >> Choice (1) is undesirable because it subverts the user's intent (if he
> >> meant there to be braces, he should have typed them) and it puts "three"
> >> into a separate process when it might better have been run in the current
> >> shell.

This is the kind of problem I've observed with a suspended function.

> >> Choice (3) is impossible in an interactive shell.  That leaves
> >> (2), which is what zsh does, using the signal number as the status.

I don't see why (3) is impossible (posh does that or ignore the ^Z,
depending on how it has been started: from another shell or directly
by the terminal). Note that the terminal can be able to send signals
to the process group of the process running under the terminal (for
instance, xterm can do that).

For ^Z, there's also:

(4) ignore the TSTP signal. Or handle it only when it is "safe".

> > Personally, I think 1) would meet most users' expectations,
[...]

Not if there's a side effect, such as setting a variable.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)