Re: Bug#303623: [andrew@xxxxxxxxxxx: Bug#303623: zsh: CHECK_JOBS doesn't work when only one command was run since last Control-D]

[Andrew Pimlott <andrew@xxxxxxxxxxx>]

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@xxxxxxxxxxx: 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