From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29944 invoked from network); 19 Sep 2004 11:49:10 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 19 Sep 2004 11:49:10 -0000 Received: (qmail 27815 invoked from network); 19 Sep 2004 11:49:04 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 19 Sep 2004 11:49:04 -0000 Received: (qmail 6004 invoked by alias); 19 Sep 2004 11:49:01 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20383 Received: (qmail 5988 invoked from network); 19 Sep 2004 11:48:59 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 19 Sep 2004 11:48:59 -0000 Received: (qmail 27537 invoked from network); 19 Sep 2004 11:48:59 -0000 Received: from cmailg2.svr.pol.co.uk (195.92.195.172) by a.mx.sunsite.dk with SMTP; 19 Sep 2004 11:48:58 -0000 Received: from modem-114.coral-beauty.dialup.pol.co.uk ([62.136.252.114] helo=pwstephenson.fsnet.co.uk) by cmailg2.svr.pol.co.uk with esmtp (Exim 4.14) id 1C90Bc-0002nA-SG for zsh-workers@sunsite.dk; Sun, 19 Sep 2004 12:48:57 +0100 Received: by pwstephenson.fsnet.co.uk (Postfix, from userid 501) id C9A40863A; Sun, 19 Sep 2004 07:53:12 -0400 (EDT) Received: from pwstephenson.fsnet.co.uk (localhost [127.0.0.1]) by pwstephenson.fsnet.co.uk (Postfix) with ESMTP id B6E908639 for ; Sun, 19 Sep 2004 12:53:12 +0100 (BST) To: zsh-workers@sunsite.dk Subject: Re: PATCH: exit after 10 EOF's In-reply-to: References: <200409131118.i8DBIM5B005245@news01.csr.com> Date: Sun, 19 Sep 2004 12:53:11 +0100 From: Peter Stephenson Message-Id: <20040919115312.C9A40863A@pwstephenson.fsnet.co.uk> X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: * X-Spam-Status: No, hits=1.5 required=6.0 tests=RCVD_IN_SORBS autolearn=no version=2.63 X-Spam-Hits: 1.5 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 Work: pws@csr.com Web: http://www.pwstephenson.fsnet.co.uk