* EOF exiting shell @ 2001-08-14 15:24 Adam Spiers 2001-08-14 16:04 ` Peter Stephenson 0 siblings, 1 reply; 5+ messages in thread From: Adam Spiers @ 2001-08-14 15:24 UTC (permalink / raw) To: zsh workers mailing list 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: EOF exiting shell 2001-08-14 15:24 EOF exiting shell Adam Spiers @ 2001-08-14 16:04 ` Peter Stephenson 2001-08-15 18:49 ` Peter Stephenson 0 siblings, 1 reply; 5+ messages in thread From: Peter Stephenson @ 2001-08-14 16:04 UTC (permalink / raw) To: Zsh hackers list 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. ********************************************************************** ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: EOF exiting shell 2001-08-14 16:04 ` Peter Stephenson @ 2001-08-15 18:49 ` Peter Stephenson 2001-08-16 2:16 ` Bart Schaefer 0 siblings, 1 reply; 5+ messages in thread From: Peter Stephenson @ 2001-08-15 18:49 UTC (permalink / raw) To: Zsh hackers list 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. ********************************************************************** ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: EOF exiting shell 2001-08-15 18:49 ` Peter Stephenson @ 2001-08-16 2:16 ` Bart Schaefer 2001-08-16 9:36 ` Peter Stephenson 0 siblings, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2001-08-16 2:16 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: EOF exiting shell 2001-08-16 2:16 ` Bart Schaefer @ 2001-08-16 9:36 ` Peter Stephenson 0 siblings, 0 replies; 5+ messages in thread From: Peter Stephenson @ 2001-08-16 9:36 UTC (permalink / raw) To: Zsh hackers list 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. ********************************************************************** ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-08-16 9:37 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-08-14 15:24 EOF exiting shell Adam Spiers 2001-08-14 16:04 ` Peter Stephenson 2001-08-15 18:49 ` Peter Stephenson 2001-08-16 2:16 ` Bart Schaefer 2001-08-16 9:36 ` Peter Stephenson
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).