* [andrew@pimlott.net: Bug#303623: zsh: CHECK_JOBS doesn't work when only one command was run since last Control-D] @ 2005-04-07 19:10 Clint Adams 2005-04-08 0:05 ` Bart Schaefer 0 siblings, 1 reply; 5+ messages in thread From: Clint Adams @ 2005-04-07 19:10 UTC (permalink / raw) To: zsh-workers; +Cc: 303623-submitter ----- Forwarded message from Andrew Pimlott <andrew@pimlott.net> ----- When a job is still running and the CHECK_JOBS is set, zsh should only exit when it receives two exit requests in a row. However, sometimes it honors an exit request in other conditions. One repeatable case is when the request is a Control-D and there was only one command run since the last exit request. The following illustrates (<C-D> stands for pressing Control-D): % vi zsh: suspended vi % exit zsh: you have suspended jobs. % true % exit zsh: you have suspended jobs. % true % true % <C-D> zsh: you have suspended jobs. % true % <C-D> <shell exits> I have accidentally logged out with my mail open several times because of this. Andrew ----- End forwarded message ----- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [andrew@pimlott.net: Bug#303623: zsh: CHECK_JOBS doesn't work when only one command was run since last Control-D] 2005-04-07 19:10 [andrew@pimlott.net: Bug#303623: zsh: CHECK_JOBS doesn't work when only one command was run since last Control-D] Clint Adams @ 2005-04-08 0:05 ` Bart Schaefer 2005-04-09 23:47 ` Bug#303623: " Andrew Pimlott 0 siblings, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2005-04-08 0:05 UTC (permalink / raw) To: zsh-workers, 303623-submitter On Apr 7, 3:10pm, Clint Adams wrote: } } When a job is still running and the CHECK_JOBS is set, zsh should only } exit when it receives two exit requests in a row. However, sometimes it } honors an exit request in other conditions. One repeatable case is when } the request is a Control-D and there was only one command run since the } last exit request. The issue here seems to be that zsh doesn't actually receive a ctrl-D keystroke, but rather that there is a true end-of-file on the tty. If you try, for example, running zsh and then starting another zsh from within the first, then when you force the "inner" zsh to exit, the "outer" one sometimes exits as well. There may actually be some kind of race condition here, because sometimes only the "inner" shell exits. It might even be an xterm bug. Here's a much simpler example to reproduce the base problem: zsh -f % sleep 300 & % <C-d> zsh: you have running jobs. % true % <C-d> zsh: warning: 1 jobs SIGHUPed It only happens with <C-d>, not with the 'exit' builtin, so it may have to do with an interaction with no_ignore_eof. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug#303623: [andrew@pimlott.net: Bug#303623: zsh: CHECK_JOBS doesn't work when only one command was run since last Control-D] 2005-04-08 0:05 ` Bart Schaefer @ 2005-04-09 23:47 ` Andrew Pimlott 2005-04-10 1:49 ` Bart Schaefer 0 siblings, 1 reply; 5+ messages in thread From: Andrew Pimlott @ 2005-04-09 23:47 UTC (permalink / raw) To: Bart Schaefer, 303623-quiet; +Cc: zsh-workers On Fri, Apr 08, 2005 at 12:05:42AM +0000, Bart Schaefer wrote: > On Apr 7, 3:10pm, Clint Adams wrote: > } > } When a job is still running and the CHECK_JOBS is set, zsh should only > } exit when it receives two exit requests in a row. However, sometimes it > } honors an exit request in other conditions. One repeatable case is when > } the request is a Control-D and there was only one command run since the > } last exit request. > > The issue here seems to be that zsh doesn't actually receive a ctrl-D > keystroke, but rather that there is a true end-of-file on the tty. Ok, but I don't think this should preclude correct behavior. My understanding is that when <C-D> is pressed, the application gets a zero-length read on the terminal, but that a subsequent read will get more keyboard input (or another zero-length read if <C-D> is pressed again). So zsh should still be able to detect each press of <C-D> reliably. > If you try, for example, running zsh and then starting another zsh from > within the first, then when you force the "inner" zsh to exit, the "outer" > one sometimes exits as well. Hmm, mysterious. I should have also said in my message that I think I've seen unexpected exits in other cases, but the one I posted is the only one I could reproduce. It sounds like there is a subtle bug in zsh. > There may actually be some kind of race condition here, because sometimes > only the "inner" shell exits. It might even be an xterm bug. > > Here's a much simpler example to reproduce the base problem: Right, I should have explained that I gave a longer example to show that 1) exit and <C-D> act differently and 2) running two commands between <C-D>s behaves as expected. Andrew ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug#303623: [andrew@pimlott.net: Bug#303623: zsh: CHECK_JOBS doesn't work when only one command was run since last Control-D] 2005-04-09 23:47 ` Bug#303623: " Andrew Pimlott @ 2005-04-10 1:49 ` Bart Schaefer 2005-04-10 4:23 ` Andrew Pimlott 0 siblings, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2005-04-10 1:49 UTC (permalink / raw) To: Andrew Pimlott, 303623-quiet; +Cc: zsh-workers On Apr 9, 4:47pm, Andrew Pimlott wrote: } Subject: Re: Bug#303623: [andrew@pimlott.net: Bug#303623: zsh: CHECK_JOBS } } > The issue here seems to be that zsh doesn't actually receive a ctrl-D } > keystroke, but rather that there is a true end-of-file on the tty. } } Ok, but I don't think this should preclude correct behavior. My } understanding is that when <C-D> is pressed, the application gets a } zero-length read on the terminal If the TTY driver is interpreting the EOF character, then yes, that is what happens. However, zsh supposedly doesn't allow the TTY driver to interpret <C-d>; it puts the terminal in CBREAK mode, so it receives a literal ASCII '\04' character, so that it's able to invoke the bindkey for that, which normally runs delete-char-or-list. The do-not-exit-when-jobs-are-pending behavior relies on having read a '\04' when the input buffer is empty. It's a simulated end-of-file rather than a real one. What *appears* to be happening -- I could still be wrong -- is that on the second C-d the CBREAK setting fails to work as expected and zsh in fact gets a zero-length read. When ignoreeof is not set, this causes the shell to exit. The point being that although I agree this is not the correct behavior, the reason for the failure is not what you may think, and therefore the fix is likely to be in a more obscure part of the C code. Further, the workaround in the meantime is to setopt ignoreeof. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug#303623: [andrew@pimlott.net: Bug#303623: zsh: CHECK_JOBS doesn't work when only one command was run since last Control-D] 2005-04-10 1:49 ` Bart Schaefer @ 2005-04-10 4:23 ` Andrew Pimlott 0 siblings, 0 replies; 5+ messages in thread From: Andrew Pimlott @ 2005-04-10 4:23 UTC (permalink / raw) To: Bart Schaefer; +Cc: 303623-quiet, zsh-workers On Sun, Apr 10, 2005 at 01:49:30AM +0000, Bart Schaefer wrote: > On Apr 9, 4:47pm, Andrew Pimlott wrote: > } Subject: Re: Bug#303623: [andrew@pimlott.net: Bug#303623: zsh: CHECK_JOBS > } > } > The issue here seems to be that zsh doesn't actually receive a ctrl-D > } > keystroke, but rather that there is a true end-of-file on the tty. > } > } Ok, but I don't think this should preclude correct behavior. My > } understanding is that when <C-D> is pressed, the application gets a > } zero-length read on the terminal > > If the TTY driver is interpreting the EOF character, then yes, that is > what happens. However, zsh supposedly doesn't allow the TTY driver to > interpret <C-d>; it puts the terminal in CBREAK mode, so it receives a > literal ASCII '\04' character, so that it's able to invoke the bindkey > for that, which normally runs delete-char-or-list. > > The do-not-exit-when-jobs-are-pending behavior relies on having read a > '\04' when the input buffer is empty. It's a simulated end-of-file > rather than a real one. > > What *appears* to be happening -- I could still be wrong -- is that on > the second C-d the CBREAK setting fails to work as expected and zsh in > fact gets a zero-length read. Ah, I see, thanks. However, a strace doesn't seem to show that happening in this case. Here are the reads on FD 10 while reproducing the problem: read(10, "\4", 1) = 1 read(10, "t", 1) = 1 read(10, "r", 1) = 1 read(10, "u", 1) = 1 read(10, "e", 1) = 1 read(10, "\n", 1) = 1 read(10, "\4", 1) = 1 Andrew ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-04-10 4:23 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-04-07 19:10 [andrew@pimlott.net: Bug#303623: zsh: CHECK_JOBS doesn't work when only one command was run since last Control-D] Clint Adams 2005-04-08 0:05 ` Bart Schaefer 2005-04-09 23:47 ` Bug#303623: " Andrew Pimlott 2005-04-10 1:49 ` Bart Schaefer 2005-04-10 4:23 ` Andrew Pimlott
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).