Fix a hang where ctrl-d can hang the next call to Readline

When running the examples/readline-demo, you can enter the `sleep`
command which causes the loop to sleep for 4 seconds before it
calls Readline() again. If you press ctrl-d during the sleep,
the program will hang.

Normally ctrl-d is mapped to CharDelete (rune:4), however termios
manpage states that when not in raw mode the following is true:

> VEOF   (004,  EOT,  Ctrl-D)  End-of-file  character (EOF).  More
> precisely: this character causes the pending tty buffer to be sent
> to the waiting user program without waiting for end-of-line.  If
> it is the first character of the line, the read(2) in the user
> program  returns  0,  which  signifies  end-of-file. Recognized
> when ICANON is set, and then not passed as input.

Between calls to Readline, the terminal is not in raw mode and thus
read returns 0. Note that err=io.EOF is correctly unset.

Previously the terminal ioloop returned the 0 on the t.outchan
which is being read by the operation ioloop. Unfortunately, 0 is
also used to indicate EOF and thus the operation ioloop terminates
which means that nobody will read from t.outchan any more and
thus input processing stops and causes the hang.

The fix is simply to ignore 0 in the terminal and go on expecting
characters.
This commit is contained in:
Thomas O'Dowd 2023-03-06 13:29:18 +09:00
parent 7f93d88cd5
commit e77a6b0c4c
1 changed files with 7 additions and 0 deletions

View File

@ -197,6 +197,13 @@ func (t *Terminal) ioloop() {
expectNextChar = true
switch r {
case 0:
// If ctrl-D is pressed at the beginning of a line before rl.Readline() is
// called, then the terminal won't be in raw mode and will translate the
// ctrl-D to 0. If we return the 0, the operation ioloop will exit and
// the next call to rl.Readline() will hang as nothing will read t.outchan.
// Instead, we can safely ignore this and continue.
continue
case CharEsc:
if t.cfg.VimMode {
t.outchan <- r