Printing ^C, ^D key presses at end of prompt when pressed

Printing ^C, ^D key presses at end of prompt when pressed

[Michael Treibton]

Hi all,

In bash, if I type something at the prompt, and press ^C, my prompt
would look like this:

$ some command ^C

That is the "^C" is explicitly printed.  Likewise if I press ^D to
logout from a prompt, that too is printed:

$ ^D

But in zsh, this doesn't happen, and as odd as it may seem I really
miss this visual indication of this.

Can this be done in Zsh?

TIA,

Michael

Re: Printing ^C, ^D key presses at end of prompt when pressed

[Bart Schaefer]

On Feb 3, 11:05pm, Michael Treibton wrote:
} 
} In bash, if I type something at the prompt, and press ^C, my prompt
} would look like this:
} 
} $ some command ^C
} 
} That is the "^C" is explicitly printed.

Really.  Doesn't work for me.  Do you somehow have readline disabled?

You seem to be describing native TTY input mode with ctlecho turned on
in the stty settings.

} But in zsh, this doesn't happen, and as odd as it may seem I really
} miss this visual indication of this.

Zsh normally leaves the stty intr setting alone and handles the INT
signal.  Which means that when you type ^C, you're sending a signal
to the tty process group, not a normal keystroke to the shell input.
This has some helpful side-effects for process management, but means
the the line editor exits.

In order to behave the way you want, you have to trap the INT signal
and print the ^C yourself:

    TRAPINT() { print -n -u2 '^C'; return $((128+$1)) }

Some old versions of zsh may not behave correctly when returning from
the trap, i.e., may not propagate the effects of being interrupted.

} Likewise if I press ^D to
} logout from a prompt, that too is printed:
} 
} $ ^D

Again, zsh leaves the tty settings alone, so it doesn't get a ^D here,
it gets an end-of-file on the shell input descriptor.  This causes it
to exit unless ignoreeof is set.

One might therefore think this could be handled like so:

    zshexit() { print -n -u2 '^D' }

However, the line editor prints a newline when finished, before the
zshexit hook is called; so the ^D ends up on the next line rather
than at the point where it was typed.

Instead you have to override the widget that's bound to the ^D key:

    delete-char-or-list() {
	[[ -z $BUFFER ]] && print -n -u2 '^D' && exit 0
	zle .$WIDGET
    }
    zle -N delete-char-or-list
    setopt ignoreeof

Ignoreeof is necessary for the line editor to ever get the ^D kestroke
in the first place, otherwise it exits without calling your widget.

Re: Printing ^C, ^D key presses at end of prompt when pressed

[Philippe Troin]

Bart Schaefer <schaefer@brasslantern.com> writes:

> On Feb 3, 11:05pm, Michael Treibton wrote:
> } 
> } In bash, if I type something at the prompt, and press ^C, my prompt
> } would look like this:
> } 
> } $ some command ^C
> } 
> } That is the "^C" is explicitly printed.
> 
> Really.  Doesn't work for me.  Do you somehow have readline disabled?

Actually:

bash-4.1$ stty echoctl
bash-4.1$ ^C
bash-4.1$ stty -echoctl
bash-4.1$                  <--- Ctrl-C pressed, no output.

No such luck in zsh (stty echoctl has no effect).
Coult it a spurious line redraw on ctrl-C (and others)?

Note how echoctl still works in zsh when using the read builtin or
just cat:

phil@air:~% stty echoctl
phil@air:~% read
^C%
zsh: exit 1
phil@air:~% cat
^C
phil@air:~%                <-- Ctrl-C pressed, no output

Phil.

Re: Printing ^C, ^D key presses at end of prompt when pressed

[Bart Schaefer]

On Feb 4,  2:03am, Philippe Troin wrote:
} Subject: Re: Printing ^C, ^D key presses at end of prompt when pressed
}
} bash-4.1$ stty echoctl
} bash-4.1$ ^C
} bash-4.1$ stty -echoctl
} bash-4.1$                  <--- Ctrl-C pressed, no output.
} 
} No such luck in zsh (stty echoctl has no effect).

I actually did try this in bash before writing my original response.
On the CentOS systems I have access to, echoctl makes no difference
whatsoever to bash.  OTOH, they don't have bash4, so maybe this is
something changed in readline at some point since bash3.  Or ...

} No such luck in zsh (stty echoctl has no effect).
} Coult it a spurious line redraw on ctrl-C (and others)?

Sorry, could you rephrase that?
 
} Note how echoctl still works in zsh when using the read builtin or
} just cat:
} 
} phil@air:~% stty echoctl
} phil@air:~% read
} ^C%
} zsh: exit 1
} phil@air:~% cat
} ^C

On what may be a third hand, I don't get *that* either.  I have echoctl
on all the time, but just to be doubly sure:

schaefer<511> STTY=echoctl cat 

schaefer<512> 

Maybe there's yet another stty option getting involved here?  Even with
bash3 I don't see the ^C when I interrupt cat.

And just for completeness:

schaefer<516> setopt printexitvalue
schaefer<517> read
zsh: exit 1
schaefer<518> STTY=echoctl cat       

zsh: interrupt  STTY=echoctl cat
schaefer<519> 

Re: Printing ^C, ^D key presses at end of prompt when pressed

[Philippe Troin]

Bart Schaefer <schaefer@brasslantern.com> writes:

> On Feb 4,  2:03am, Philippe Troin wrote:
> } Subject: Re: Printing ^C, ^D key presses at end of prompt when pressed
> }
> } bash-4.1$ stty echoctl
> } bash-4.1$ ^C
> } bash-4.1$ stty -echoctl
> } bash-4.1$                  <--- Ctrl-C pressed, no output.
> } 
> } No such luck in zsh (stty echoctl has no effect).
> 
> I actually did try this in bash before writing my original response.
> On the CentOS systems I have access to, echoctl makes no difference
> whatsoever to bash.  OTOH, they don't have bash4, so maybe this is
> something changed in readline at some point since bash3.  Or ...

The ^C are emitted by the kernel tty layer I believe.
The shell has nothing to do with it.
But you are right, I've just tested on a CentOS5 box, and echoctl has
no effect there.
 
> } No such luck in zsh (stty echoctl has no effect).
> } Coult it a spurious line redraw on ctrl-C (and others)?
> 
> Sorry, could you rephrase that?

I was suggesting that the sequence of events could be:

 1. Ctrl-C is pressed on the terminal

 2. Kernel tty layer sees it is the stty intr character, emits the ^C
    string to the tty, and send SIGINT to the foreground process group
    which would be zsh.

 3. Zsh catches SIGINT, then clears the line (that's where ^C would
    disappear), and redisplays the prompt.
  
> } Note how echoctl still works in zsh when using the read builtin or
> } just cat:
> } 
> } phil@air:~% stty echoctl
> } phil@air:~% read
> } ^C%
> } zsh: exit 1
> } phil@air:~% cat
> } ^C
> 
> On what may be a third hand, I don't get *that* either.  I have echoctl
> on all the time, but just to be doubly sure:
> 
> schaefer<511> STTY=echoctl cat 
> 
> schaefer<512> 

(I was not aware of the STTY special environment variable).
I think CentOS5's handling of tostop seems is broken or missing.

> Maybe there's yet another stty option getting involved here?  Even with
> bash3 I don't see the ^C when I interrupt cat.

It could be.  These are my full stty settings:

% stty -a
speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

I assume you do NOT have ttyctl is frozen mode:

% ttyctl
tty is not frozen

Phil.

Re: Printing ^C, ^D key presses at end of prompt when pressed

[Bart Schaefer]

On Feb 5,  3:54pm, Philippe Troin wrote:
} Subject: Re: Printing ^C, ^D key presses at end of prompt when pressed
}
} > Maybe there's yet another stty option getting involved here?  Even with
} > bash3 I don't see the ^C when I interrupt cat.
} 
} It could be.  These are my full stty settings:

Mine are identical except -
- my stty does not support "swtch" or "iutf8" (CentOS4)
- I have -hupcl -brkint -imaxbel, the reverse of yours.

However, changing any of those has no different effect.

} I assume you do NOT have ttyctl is frozen mode:
 
I do have it frozen, but that only affects what happens to the settings
after the shell gets control back from an external command.

}  1. Ctrl-C is pressed on the terminal
} 
}  2. Kernel tty layer sees it is the stty intr character, emits the ^C
}     string to the tty, and send SIGINT to the foreground process group
}     which would be zsh.
} 
}  3. Zsh catches SIGINT, then clears the line (that's where ^C would
}     disappear), and redisplays the prompt.

I don't think that can be it, because you can easily see that zsh does
not clear the line.  Type some characters, back up into the middle of
them, and then hit ^C; the stuff to the right of the cursor remains.

} (I was not aware of the STTY special environment variable).
} I think CentOS5's handling of tostop seems is broken or missing.

Do you mean tostop or ctlecho?

schaefer<511> stty tostop
schaefer<512> (echo foo) &
[1] 26738
[1]  + suspended (tty output)  ( echo foo; )