From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4807 invoked from network); 30 Dec 2008 09:40:19 -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; 30 Dec 2008 09:40:19 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 97688 invoked from network); 30 Dec 2008 09:40:15 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 30 Dec 2008 09:40:15 -0000 Received: (qmail 14039 invoked by alias); 30 Dec 2008 09:40:10 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26204 Received: (qmail 14026 invoked from network); 30 Dec 2008 09:40:09 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 30 Dec 2008 09:40:09 -0000 Received: from mail.o2.co.uk (yoda.london.02.net [82.132.130.151]) by bifrost.dotsrc.org (Postfix) with ESMTP id 1A34980308BE for ; Tue, 30 Dec 2008 10:40:06 +0100 (CET) Received: from sc.homeunix.net (78.105.235.196) by mail.o2.co.uk (8.0.013.3) (authenticated as stephane.chazelas) id 494F67FB02050186; Tue, 30 Dec 2008 09:40:05 +0000 Received: from chazelas by sc.homeunix.net with local (Exim 4.69) (envelope-from ) id 1LHb4z-0001h0-5v; Tue, 30 Dec 2008 09:40:01 +0000 Date: Tue, 30 Dec 2008 09:40:01 +0000 From: Stephane Chazelas To: Richard Hartmann Cc: zsh-workers@sunsite.dk, 288323@bugs.debian.org Subject: Re: Debian zsh bug triage Message-ID: <20081230094000.GB4921@sc.homeunix.net> Mail-Followup-To: Richard Hartmann , zsh-workers@sunsite.dk, 288323@bugs.debian.org References: <2d460de70812291246o62169a0bxa7b68ce4aa5be504@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2d460de70812291246o62169a0bxa7b68ce4aa5be504@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-09-19) X-Virus-Scanned: ClamAV 0.92.1/8813/Tue Dec 30 07:53:19 2008 on bifrost X-Virus-Status: Clean On Mon, Dec 29, 2008 at 09:46:07PM +0100, Richard Hartmann wrote: [...] > 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]: I don't observe that with 4.3.9-dev-1-cvs1210 And I can see all the shells behaving the same. Am I missing something again? > > > 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 Well, it does return a status, but it also leaves a job stopped in background. > > (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 ;) [...] When one runs: cmd1; cmd2 he may intend that to be a little script of two commands. If one expects to terminate that little script (which zsh, ksh, pdksh, ash do), one may expect (1) above as well, that is to stop that little script. On the other end, 2 makes even more sense because you'd expect cmd1; cmd2 to be the same as cmd1 cmd2 And according to SUSv4, those are two jobs. According to SUSv4, a job is a shell pipeline. And: SUSv4> pipeline : pipe_sequence SUSv4> | Bang pipe_sequence SUSv4> ; SUSv4> pipe_sequence : command SUSv4> | pipe_sequence '|' linebreak command SUSv4> ; SUSv4> command : simple_command SUSv4> | compound_command SUSv4> | compound_command redirect_list SUSv4> | function_definition So, in the case of { cmd1; cmd2; }, we've got one job, so one would expect to stop the whole job. But then, in "cmd1; cmd2", according to SUSv4 again, should only terminate cmd1 as bash does and run cmd2... so there's a consistency problem here. -- Stéphane