* Printing ^C, ^D key presses at end of prompt when pressed
@ 2011-02-03 23:05 Michael Treibton
2011-02-04 4:20 ` Bart Schaefer
0 siblings, 1 reply; 6+ messages in thread
From: Michael Treibton @ 2011-02-03 23:05 UTC (permalink / raw)
To: zsh-users
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Printing ^C, ^D key presses at end of prompt when pressed
2011-02-03 23:05 Printing ^C, ^D key presses at end of prompt when pressed Michael Treibton
@ 2011-02-04 4:20 ` Bart Schaefer
2011-02-04 10:03 ` Philippe Troin
0 siblings, 1 reply; 6+ messages in thread
From: Bart Schaefer @ 2011-02-04 4:20 UTC (permalink / raw)
To: zsh-users
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Printing ^C, ^D key presses at end of prompt when pressed
2011-02-04 4:20 ` Bart Schaefer
@ 2011-02-04 10:03 ` Philippe Troin
2011-02-04 15:25 ` Bart Schaefer
0 siblings, 1 reply; 6+ messages in thread
From: Philippe Troin @ 2011-02-04 10:03 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-users
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Printing ^C, ^D key presses at end of prompt when pressed
2011-02-04 10:03 ` Philippe Troin
@ 2011-02-04 15:25 ` Bart Schaefer
2011-02-05 23:54 ` Philippe Troin
0 siblings, 1 reply; 6+ messages in thread
From: Bart Schaefer @ 2011-02-04 15:25 UTC (permalink / raw)
To: zsh-users
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Printing ^C, ^D key presses at end of prompt when pressed
2011-02-04 15:25 ` Bart Schaefer
@ 2011-02-05 23:54 ` Philippe Troin
2011-02-06 1:38 ` Bart Schaefer
0 siblings, 1 reply; 6+ messages in thread
From: Philippe Troin @ 2011-02-05 23:54 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-users
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Printing ^C, ^D key presses at end of prompt when pressed
2011-02-05 23:54 ` Philippe Troin
@ 2011-02-06 1:38 ` Bart Schaefer
0 siblings, 0 replies; 6+ messages in thread
From: Bart Schaefer @ 2011-02-06 1:38 UTC (permalink / raw)
To: zsh-users
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; )
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-02-06 1:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-03 23:05 Printing ^C, ^D key presses at end of prompt when pressed Michael Treibton
2011-02-04 4:20 ` Bart Schaefer
2011-02-04 10:03 ` Philippe Troin
2011-02-04 15:25 ` Bart Schaefer
2011-02-05 23:54 ` Philippe Troin
2011-02-06 1:38 ` Bart Schaefer
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).