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

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

[Clint Adams]

----- 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 -----

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

[Bart Schaefer]

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.

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

[Andrew Pimlott]

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

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

[Bart Schaefer]

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.

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

[Andrew Pimlott]

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