Zsh Mailing List Archive Messages sorted by: Reverse Date, Date, Thread, Author

Re: Debian zsh bug triage

X-seq: zsh-workers 26392
From: Richard Hartmann <richih.mailinglist@xxxxxxxxx>
To: zsh-workers@xxxxxxxxxx
Subject: Re: Debian zsh bug triage
Date: Wed, 21 Jan 2009 17:53:01 +0100
Cc: 288323@xxxxxxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=b4GJDBHfzylHUZV17+ut3OsheT10A8Abs5dnBAItVIg=; b=XRIDGN56dtcz1Ts6GMGYRH3z/vc6uEK8eHYh+7GOgO6KiisH2ocomfkYSDbAZHz7WC s/Lit4jKeRq2V+CrazR0lOoRU/pZkvZTEx+UJ2SMYBj/YH+RmhTvq5xW6nrWV7KsVSf1 Vg/eoQ6bhp9D94tCVWTDY/B7rt3qwRxo8TzSE=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=elOkzQZSQRsSurGEXbkn4qbnjtQnl3/IKg6cXwXxchAp2rDVLJq6WAj9dfWQKVS6X2 wa5l93Y94l9sOxiaG8cLg31AsFmJl5IKGcQNl8M4u5EABjcoCIWTkwXOnP00NZ6tmJ4P hwJ6HjwmoSFz+5o7gCZgBcO0OcI3L+L61FF/0=
In-reply-to: <2d460de70812291246o62169a0bxa7b68ce4aa5be504@xxxxxxxxxxxxxx>
Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
References: <2d460de70812291246o62169a0bxa7b68ce4aa5be504@xxxxxxxxxxxxxx>

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@xxxxxxxxx> 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
>

Messages sorted by: Reverse Date, Date, Thread, Author