* Debian zsh bug triage @ 2008-12-29 20:46 Richard Hartmann 2008-12-29 21:19 ` Stephane Chazelas ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Richard Hartmann @ 2008-12-29 20:46 UTC (permalink / raw) To: zsh-workers; +Cc: 276187, 288323 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Debian zsh bug triage 2008-12-29 20:46 Debian zsh bug triage Richard Hartmann @ 2008-12-29 21:19 ` Stephane Chazelas 2008-12-29 23:16 ` Richard Hartmann 2008-12-30 9:40 ` Stephane Chazelas 2009-01-21 16:53 ` Richard Hartmann 2 siblings, 1 reply; 8+ messages in thread From: Stephane Chazelas @ 2008-12-29 21:19 UTC (permalink / raw) To: Richard Hartmann; +Cc: zsh-workers, 276187, 288323 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]: [...] That'd be a feature. All the other shells except bash behave like that. You'll find plenty of places where people complain about bash behavior. -- Stéphane ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Debian zsh bug triage 2008-12-29 21:19 ` Stephane Chazelas @ 2008-12-29 23:16 ` Richard Hartmann 2008-12-30 8:54 ` Stephane Chazelas 2008-12-30 9:42 ` Stephane Chazelas 0 siblings, 2 replies; 8+ messages in thread From: Richard Hartmann @ 2008-12-29 23:16 UTC (permalink / raw) To: Richard Hartmann, zsh-workers, 288323 Please don't CC 276187@bugs.debian.org any more -- my fault for mixing two bugs into one email. Won't happen again. On Mon, Dec 29, 2008 at 22:19, Stephane Chazelas <Stephane_Chazelas@yahoo.fr> wrote: > That'd be a feature. All the other shells except bash behave > like that. You'll find plenty of places where people complain > about bash behavior. doing the 'right' thing and suspending {1;2;3} : ksh93 swallowing 3 : bash, csh, fish, running 3 the second 2 is suspended: ash, dash freezing the whole shell: Solaris 9 /bin/sh not allowing you to suspend within a command chain at all: ksh88 not catching ^Z and suspending themselves; when stopped from another shell, they do: posh : runs 3 the second 2 is suspended sash : does the 'right' thing and suspends {1;2;3} being so weird i had to kill the shell from outside: scsh Richard ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Debian zsh bug triage 2008-12-29 23:16 ` Richard Hartmann @ 2008-12-30 8:54 ` Stephane Chazelas 2008-12-30 9:42 ` Stephane Chazelas 1 sibling, 0 replies; 8+ messages in thread From: Stephane Chazelas @ 2008-12-30 8:54 UTC (permalink / raw) To: Richard Hartmann; +Cc: zsh-workers, 288323 On Tue, Dec 30, 2008 at 12:16:49AM +0100, Richard Hartmann wrote: > Please don't CC 276187@bugs.debian.org any more -- my fault for mixing > two bugs into one email. Won't happen again. > > On Mon, Dec 29, 2008 at 22:19, Stephane Chazelas > <Stephane_Chazelas@yahoo.fr> wrote: > > > That'd be a feature. All the other shells except bash behave > > like that. You'll find plenty of places where people complain > > about bash behavior. > > doing the 'right' thing and suspending {1;2;3} : [...] Sorry, I read too quickly, I thought you meant <Ctrl-C> instead of <Ctrl-Z>. -- Stéphane ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Debian zsh bug triage 2008-12-29 23:16 ` Richard Hartmann 2008-12-30 8:54 ` Stephane Chazelas @ 2008-12-30 9:42 ` Stephane Chazelas 2008-12-30 15:29 ` Richard Hartmann 1 sibling, 1 reply; 8+ messages in thread From: Stephane Chazelas @ 2008-12-30 9:42 UTC (permalink / raw) To: Richard Hartmann; +Cc: zsh-workers, 288323 On Tue, Dec 30, 2008 at 12:16:49AM +0100, Richard Hartmann wrote: > Please don't CC 276187@bugs.debian.org any more -- my fault for mixing > two bugs into one email. Won't happen again. > > On Mon, Dec 29, 2008 at 22:19, Stephane Chazelas > <Stephane_Chazelas@yahoo.fr> wrote: > > > That'd be a feature. All the other shells except bash behave > > like that. You'll find plenty of places where people complain > > about bash behavior. > > doing the 'right' thing and suspending {1;2;3} : > ksh93 > > swallowing 3 : > bash, csh, fish, > > running 3 the second 2 is suspended: > ash, dash > > freezing the whole shell: > Solaris 9 /bin/sh > > not allowing you to suspend within a command chain at all: > ksh88 > > not catching ^Z and suspending themselves; when stopped from > another shell, they do: > posh : > runs 3 the second 2 is suspended > sash : > does the 'right' thing and suspends {1;2;3} > > being so weird i had to kill the shell from outside: > scsh [...] Could you please clarify what you tried? I get different behaviors from you whether I try { echo 1; sleep 10; echo 2; } or echo 1; sleep 10; echo 2 -- Stéphane ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Debian zsh bug triage 2008-12-30 9:42 ` Stephane Chazelas @ 2008-12-30 15:29 ` Richard Hartmann 0 siblings, 0 replies; 8+ messages in thread From: Richard Hartmann @ 2008-12-30 15:29 UTC (permalink / raw) To: Richard Hartmann, zsh-workers, 288323 On Tue, Dec 30, 2008 at 10:42, Stephane Chazelas <Stephane_Chazelas@yahoo.fr> wrote: > Could you please clarify what you tried? I get different > behaviors from you whether I try > > { echo 1; sleep 10; echo 2; } > or > echo 1; sleep 10; echo 2 I tried with the latter. The former is well-defined and should always stop and restart as a whole. The interesting bit is to see how the latter is handled. Quite differently, it turns out. Richard PS: Are all questions in your previous mails answered? If not, please tell me. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Debian zsh bug triage 2008-12-29 20:46 Debian zsh bug triage Richard Hartmann 2008-12-29 21:19 ` Stephane Chazelas @ 2008-12-30 9:40 ` Stephane Chazelas 2009-01-21 16:53 ` Richard Hartmann 2 siblings, 0 replies; 8+ messages in thread From: Stephane Chazelas @ 2008-12-30 9:40 UTC (permalink / raw) To: Richard Hartmann; +Cc: zsh-workers, 288323 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 <Ctrl-C> to terminate that little script (which zsh, ksh, pdksh, ash do), one may expect (1) above as well, that is <Ctrl-Z> 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 <Ctrl-Z> to stop the whole job. But then, in "cmd1; cmd2", according to SUSv4 again, <Ctrl-C> should only terminate cmd1 as bash does and run cmd2... so there's a consistency problem here. -- Stéphane ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Debian zsh bug triage 2008-12-29 20:46 Debian zsh bug triage Richard Hartmann 2008-12-29 21:19 ` Stephane Chazelas 2008-12-30 9:40 ` Stephane Chazelas @ 2009-01-21 16:53 ` Richard Hartmann 2 siblings, 0 replies; 8+ messages in thread From: Richard Hartmann @ 2009-01-21 16:53 UTC (permalink / raw) To: zsh-workers; +Cc: 288323 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-01-21 16:53 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-12-29 20:46 Debian zsh bug triage Richard Hartmann 2008-12-29 21:19 ` Stephane Chazelas 2008-12-29 23:16 ` Richard Hartmann 2008-12-30 8:54 ` Stephane Chazelas 2008-12-30 9:42 ` Stephane Chazelas 2008-12-30 15:29 ` Richard Hartmann 2008-12-30 9:40 ` Stephane Chazelas 2009-01-21 16:53 ` Richard Hartmann
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).