* [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).