From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2173 invoked from network); 21 Jan 2009 16:53:26 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 21 Jan 2009 16:53:26 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 1337 invoked from network); 21 Jan 2009 16:53:22 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 21 Jan 2009 16:53:22 -0000 Received: (qmail 23517 invoked by alias); 21 Jan 2009 16:53:17 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26392 Received: (qmail 23504 invoked from network); 21 Jan 2009 16:53:17 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 21 Jan 2009 16:53:17 -0000 Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by bifrost.dotsrc.org (Postfix) with ESMTP id DB81E80271F0 for ; Wed, 21 Jan 2009 17:53:01 +0100 (CET) Received: by fg-out-1718.google.com with SMTP id e21so1710922fga.37 for ; Wed, 21 Jan 2009 08:53:01 -0800 (PST) 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= MIME-Version: 1.0 Received: by 10.86.27.9 with SMTP id a9mr95135fga.46.1232556781295; Wed, 21 Jan 2009 08:53:01 -0800 (PST) In-Reply-To: <2d460de70812291246o62169a0bxa7b68ce4aa5be504@mail.gmail.com> References: <2d460de70812291246o62169a0bxa7b68ce4aa5be504@mail.gmail.com> Date: Wed, 21 Jan 2009 17:53:01 +0100 Message-ID: <2d460de70901210853rf9ccca8ybe7cc24ede204552@mail.gmail.com> Subject: Re: Debian zsh bug triage From: Richard Hartmann To: zsh-workers@sunsite.dk Cc: 288323@bugs.debian.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92.1/8884/Wed Jan 21 14:15:32 2009 on bifrost X-Virus-Status: Clean 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 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 >