Re: Debian zsh bug triage

[Richard Hartmann <richih.mailinglist@gmail.com>]

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?


Richard

On Mon, Dec 29, 2008 at 21:46, Richard Hartmann
<richih.mailinglist@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.  Choice (3) is impossible in an interactive shell.  That leaves
>> (2), which is what zsh does, using the signal number as the status.
>
> Personally, I think 1) would meet most users' expectations, but any of
> the three are OK. Not executing the third command at all is not, imo. Of
> course, if the third command is a rm, mv or some other potentially
> destructive command, it's best to err on the save side, so I can see why
> that was done. If that is a design decission, I will accept that and
> close the bug accordingly. But keep in mind that 1) would be a save
> solution, as well ;)
>
>
> Richard
>
> [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=zsh
> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276187
> [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288323
> [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288323#18
>