zsh-workers
 help / color / mirror / code / Atom feed
From: "Richard Hartmann" <richih.mailinglist@gmail.com>
To: zsh-workers@sunsite.dk
Cc: 276187@bugs.debian.org, 288323@bugs.debian.org
Subject: Debian zsh bug triage
Date: Mon, 29 Dec 2008 21:46:07 +0100	[thread overview]
Message-ID: <2d460de70812291246o62169a0bxa7b68ce4aa5be504@mail.gmail.com> (raw)

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


             reply	other threads:[~2008-12-29 20:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-29 20:46 Richard Hartmann [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2d460de70812291246o62169a0bxa7b68ce4aa5be504@mail.gmail.com \
    --to=richih.mailinglist@gmail.com \
    --cc=276187@bugs.debian.org \
    --cc=288323@bugs.debian.org \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).