Re: rfc patch, abort rm instead of only removing the * from the cmdline

["Richard Hartmann" <richih.mailinglist@xxxxxxxxx>]

On Sun, Aug 17, 2008 at 22:42, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

> It having been this way for far more than a decade without anyone ever
> complaining before, I'm not sure "asap!" really applies.

Something to be in a certain state for a long time does mean it should
not be fixed. To qualify, I did mean 'with the next release', not 'release
emergency patches', though.
Also, I know several people who have had massive data loss due to
misunderstanding what a program wants to do, or even due to a bug,
and never bothered to file a bug. That is unfortunate, but a fact. So
the mere lack of feedback does not mean it did not happen. Neither
does it mean it did happen, of course. Yet, especially with such
counter-intuitve behaviour, are slow to file issues. Especially if they
are not sure what happened or notice a long time after the fact.


> The existing behavior really is what Paul Falstad wanted the shell to
> do, all those years ago.  Like several of the very oldest features,
> it's rather woefully under-documented in the man pages.  If you want
> to abort the whole command, you're supposed to interrupt it with ^C,
> not answer "n" -- the prompt is really just to give you an extra moment
> to think about what a stupid thing you might be about to do, not to
> second-guess your entire command line; compare the RM_STAR_WAIT option
> (which is a lot more recent).

I can't think of a situation where ZSH queries me if I want to do
something and answering no does anything other than stopping to
execute whatever it wanted to do. The CORRECT option is somewhat
special, but follows the same pattern.
Thus, not aborting the command completely is against most user's
expectations and as this can lead to data loss, it is better to default
to the save option.


> Ideally I suppose this prompt should work like the prompt for "correct",
> giving you "nyae" as choices so you can choose to abort or to edit your
> typo.  Then it would be more obvious that "n" was not going to entirely
> whack the command.

I have been thinking about this, as well. A problem I see is that the
meanings of yes and no are exchanged in the two examples. This
will probably confuse users and a bit of muscle memory can destroy
data.


To summarize, I think it is best to default to the save option which
is to simply stop executing and returning to the command line.


Richard