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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
