EOF exiting shell

EOF exiting shell

[Adam Spiers]

Two queries regarding exiting the shell via ^D:

  - The info pages say that even if IGNOREEOF is set, the shell will
    exit after ten EOFs, but in zle_main.c it looks like it needs to
    happen 20 times (although for me it never exits with IGNOREEOF set).

  - More importantly, if you exit via EOF, it exits with the last
    value of $? as the exit code.  This may be deliberate, but it's
    quite annoying for me; I have /bin/sh as my default shell, and
    then this gets called by my .bash_profile:

      switch_shell () {
        if [ -x $MYSHELL ] && [ -z "$NO_ZSH" ]; then
          # we do this rather than exec() just in case $MYSHELL fails to
        run.
          $MYSHELL -d "$@" && exit
        fi
      }

    where $MYSHELL points to a CVS install of zsh, which could
    conceivably be broken.  This way I guarantee myself a usable shell
    without some annoying `Run zsh [Y/n]?' sort of prompt every time I
    pop up a new terminal.  However, if in the successfully invoked
    zsh I hit ^D after doing something that sets $? != 0, that means
    that I fall back into bash.  No great hardship, but would be nice
    if it didn't happen.  Is there any reason why EOF couldn't set $?
    to 0 before exiting?

Thanks,

Adam

Re: EOF exiting shell

[Peter Stephenson]

Adam Spiers wrote:
> Two queries regarding exiting the shell via ^D:
> 
>   - The info pages say that even if IGNOREEOF is set, the shell will
>     exit after ten EOFs, but in zle_main.c it looks like it needs to
>     happen 20 times

That's a slightly different issue --- it tries to read a single character
20 times, and if that fails it assumes the terminal has gone away.  Maybe
that's supposed to take over from the IGNOREEOF test in this case?

> (although for me it never exits with IGNOREEOF set).

Right, I suppose that's a real bug, although I don't know anything about
its history.  It's not documented, anyway, but possibly someone decided the
current way was good enough to avoid shells hanging around too long.  In
which case, the rest of this message is irrelevant, but I'd like to know
for sure, obviously.

It looks like it could be fixed by the following --- if the option isn't
set, handle EOF unconditionally, if it is, handle it only on a feep.
Doesn't seem to conflict with vared's use of ^D's, with or without the -e
option.

If it was intended that IGNOREEOF should display a message but stay on the
same prompt, then this will stomp on that --- for that to work requires a
more complicated patch where the number of EOF's is tested inside zle
and the test in the main code is bypassed.

I'm sure I must be missing something else, though...

Index: Src/Zle/zle_main.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_main.c,v
retrieving revision 1.19
diff -u -r1.19 zle_main.c
--- Src/Zle/zle_main.c	2001/07/08 00:32:12	1.19
+++ Src/Zle/zle_main.c	2001/08/14 15:53:03
@@ -560,19 +560,27 @@
     prefixflag = 0;
     zrefresh();
     while (!done && !errflag) {
+	int maybe_eof;
 
 	statusline = NULL;
 	vilinerange = 0;
 	reselectkeymap();
 	selectlocalmap(NULL);
 	bindk = getkeycmd();
-	if (!ll && isfirstln && unset(IGNOREEOF) && c == eofchar) {
+	maybe_eof = (!ll && isfirstln && c == eofchar);
+	if (maybe_eof && unset(IGNOREEOF)) {
 	    eofsent = 1;
 	    break;
 	}
 	if (bindk) {
 	    if (execzlefunc(bindk, zlenoargs))
+	    {
 		handlefeep(zlenoargs);
+		if (maybe_eof) {
+		    eofsent = 1;
+		    break;
+		}
+	    }
 	    handleprefixes();
 	    /* for vi mode, make sure the cursor isn't somewhere illegal */
 	    if (invicmdmode() && cs > findbol() &&

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: EOF exiting shell

[Peter Stephenson]

Peter Stephenson wrote:
> > (although for me it never exits with IGNOREEOF set).
> 
> Right, I suppose that's a real bug, although I don't know anything about
> its history.  It's not documented, anyway, but possibly someone decided the
> current way was good enough to avoid shells hanging around too long.

Any comments on this?  Should I install the patch, giving the documented
behaviour?  Or should I fix the documentation to say that IGNOREEOF ignores
an arbitrary number of EOFs in zle?  Or does anyone think zle is supposed
to handle this internally, requiring a bigger fix?

I'm inclined to think the first option is the safest, unless anyone
remembers what's going on.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: EOF exiting shell

[Bart Schaefer]

On Aug 15,  7:49pm, Peter Stephenson wrote:
} Subject: Re: EOF exiting shell
}
} Peter Stephenson wrote:
} > > (although for me it never exits with IGNOREEOF set).
} > 
} > Right, I suppose that's a real bug, although I don't know anything about
} > its history.
} 
} Any comments on this?  Should I install the patch, giving the documented
} behaviour?

The history is reflected in the thread leading up to zsh-workers/12485.
An EOF generated by ^D never used to get to ZLE at all, and this was
deemed annoying because it meant you couldn't override it with a user-
defined widget.

So 12485 changed it to be handled by zle, but then if you DON'T have a
user-defined widget, it never exits.

I haven't checked your patch to see how it interacts with user-defined
widgets bound to the EOF character.  As long as it doesn't revert us back
to the days when that wasn't possible, you can probably apply it.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: EOF exiting shell

[Peter Stephenson]

Bart Schaefer wrote:
> An EOF generated by ^D never used to get to ZLE at all, and this was
> deemed annoying because it meant you couldn't override it with a user-
> defined widget.
> 
> So 12485 changed it to be handled by zle, but then if you DON'T have a
> user-defined widget, it never exits.
> 
> I haven't checked your patch to see how it interacts with user-defined
> widgets bound to the EOF character.  As long as it doesn't revert us back
> to the days when that wasn't possible, you can probably apply it.

It works at present so that you get the EOF behaviour if the widget
failed, which means returned non zero status for a builtin widget.

But if the current behaviour is good enough to make sure the shell exits
when the tty goes away (because the read should fail) then it's an
unnecessary complication.  Maybe the documentation could be reworded, since
the `exit after ten EOFs' is not now the behaviour most users will see.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************