From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12643 invoked from network); 29 Dec 2008 20:46:40 -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=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; 29 Dec 2008 20:46:40 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 75833 invoked from network); 29 Dec 2008 20:46:30 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 29 Dec 2008 20:46:30 -0000 Received: (qmail 20684 invoked by alias); 29 Dec 2008 20:46:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26192 Received: (qmail 20665 invoked from network); 29 Dec 2008 20:46:22 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 29 Dec 2008 20:46:22 -0000 Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by bifrost.dotsrc.org (Postfix) with ESMTP id 6E36280308BE for ; Mon, 29 Dec 2008 21:46:08 +0100 (CET) Received: by fg-out-1718.google.com with SMTP id e21so1688764fga.37 for ; Mon, 29 Dec 2008 12:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=kxFHDiaiwHEtPvkuxV9BHBSFSOv03Kuw45tEySLGc2g=; b=PSy5Ik5KWEQsHz8YMkCMf7UPCHD4DdioicCwRD8snsv1u2SNnnSWy7So6RyGQd47my v0gAl/pG+bJL9tccgkvNH0HQ6k59+oqTh0buWs7qC16vEv8hyMLsGKx2YUVsiZKSNO5E sHF41yyHBjmWl4CspCW04BmDbJr2b/j0kEKaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=NdhjrQqp8s8H2a6INDGoqLuWU/VYPwftWFkUtlR1hgzH8glOz6ZBuU+CK9nLGCLWmP Ky2HWKEtOpJYNGb1nX5lwlf77eIvUwThZMoyfWA1OeL7YWCvhQFyBfl1a/Lw3xRjCn7e w5xiIHl8T2UkzY2z5TnsuYEy+n4X1mLdDgHic= Received: by 10.86.92.7 with SMTP id p7mr8314477fgb.54.1230583567994; Mon, 29 Dec 2008 12:46:07 -0800 (PST) Received: by 10.86.62.8 with HTTP; Mon, 29 Dec 2008 12:46:07 -0800 (PST) Message-ID: <2d460de70812291246o62169a0bxa7b68ce4aa5be504@mail.gmail.com> Date: Mon, 29 Dec 2008 21:46:07 +0100 From: "Richard Hartmann" To: zsh-workers@sunsite.dk Subject: Debian zsh bug triage Cc: 276187@bugs.debian.org, 288323@bugs.debian.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.92.1/8811/Mon Dec 29 21:02:38 2008 on bifrost X-Virus-Status: Clean 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): 1) Possible regression/setting change[2]: It seems that with zsh 4.07 and autoload -U compinit compinit -C compinit -u zstyle ':completion:*' menu select interactive You were able to hit tab twice, get the menu and then use tab to cycle through all menu options. With 4.3.6 and 4.3.9, you need to use the cursor keys. Was that on purpose? Does the user need to set something? At least the garbage chars seem to have disappeared. 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