Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: exit after 10 EOF's
- X-seq: zsh-workers 20383
- From: Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: PATCH: exit after 10 EOF's
- Date: Sun, 19 Sep 2004 12:53:11 +0100
- In-reply-to: <Pine.LNX.4.61.0409181943300.6971@xxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <200409131118.i8DBIM5B005245@xxxxxxxxxxxxxx> <Pine.LNX.4.61.0409181943300.6971@xxxxxxxxxxxxxxxxxx>
Bart Schaefer wrote:
>... a lot ...
Thanks for the long explanation. The reason I started suggesting a
change now is that I didn't realise how confused the implementation was.
I think the key bits that need discussing are...
> Returning to your excerpt far above, you appear to object to the fact that
> the conditions of "not internal" and "not completion" are simultaneously
> required in order for a widget binding to override the default behavior of
> setopt ignoreeof. Is that an accurate summation?
Yes, particularly since even calling a builtin widget from a zle -N
widget doesn't override the behaviour. I have for a long time had a
widget which calls delete-char-or-list and is bound as a replacement to
^D and you still get the message. Consequently, for most zsh users,
the additional feature is nothing more than a confusion. I would have
thought an explicit option to make it so ('so' means that either you
have 'standard' ignore_eof behaviour in zle, or you have no special response
to the EOF character at all) would be an advantage.
My guess is that because of this problem very few people are relying on
(nor possibly even aware of, despite the documentation) the
suppress-message behaviour of widget binding, so the inconvenience is
minimal.
> You also feel that there shouldn't be a distinction on the behavior of 10
> EOF characters, but my assertion is that 10 EOF characters was never
> intended to have any semantics of its own and shouldn't be given any now.
> It's nothing but an unfortunate side-effect, and one that ZLE correctly
> avoided before, which is why I think 20363 should be backed out.
I have absolutely no disagreement with your detailed technical
description.
My feeling, however, is that to most users who've heard of it "shell
exits after 10 EOFs" is part of the feature. I don't want shell users to
have to know about the distinction between canonical input and what the
line editor does. I want it just to work. It seems to me consistency
in the user interface is considerably preferable to a low-level
technical consistency that users won't notice.
Indeed, although this isn't an important point, we're not strictly being
technically consistent, since as you say the character isn't a real EOF
in zle anyway, so printing a message as if it was is already a confusion.
(I have been known in the past to hit ^Ds until the shell exits, but
probably I'm weird. Obviously I haven't done it in zsh for a long time.)
I would be delighted if there was a strong body of opinion one way or
the other to resolve the issue. Maybe some prodding on zsh-users is
appropriate.
I find it unfortunate that the message in zle (when it isn't going to
exit) is the same as from the base shell (when it eventually will). If
there's no enthusiasm for a new option, maybe simply fixing the message
to indicate the shell isn't going to exit is useful.
--
Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxx>
Work: pws@xxxxxxx
Web: http://www.pwstephenson.fsnet.co.uk
Messages sorted by:
Reverse Date,
Date,
Thread,
Author