Shell flow control notes
Linux-related notes
Shell, admin, and both:
|
Problem
Occasionally I hit a key combo that seems to completely incapacitate my shell (SSH or local).
Reason
The culprit was Ctrl-S, which is linked to the flow control of incoming data on a shell.
Used as a feature, it lets you stop things from scrolling off-screen on hardware terminals. This is useful for things like modem lines.
If/when interpreted, VSTOP (ASCII control character DC3, 0x13) tells the other side "stop sending me updates" and VSTART (DC1, 0x10) says "alright, continue."
In various contexts, Ctrl-S is set to send VSTOP, Ctrl-Q to set VSTART, which means hitting them tells the other side to stop updating your shell. This can be annoying if Ctrl-S is a key combination in some application, like it is in emacs.
IXON controls whether VSTART and VSTOP in incoming data in incoming data.
IXOFF controls whether a sending side will send these codes - typically when its input queue is full. (verify)
- ttys will generally do this, ptys will not?(verify)
Check and fix
To check whether this interpretation is enabled, run
stty -a
The output would likely
- start = ^Q
- stop = ^S
- ixon -ixoff meaning IXON (respecting VSTART, VSTOP) is on, IXOFF (whether tty driver send them(verify)) is off.
One workaround to my issue is to undefine START and STOP, which implies there is no key combo that cause them to be sent.
stty start undef stty stop undef
Another way is to disable the ixon/ixoff feature:
stty -ixon
When added to a shell login script, you may wish to only do this for ttys (not for scripts).
I had one case where stty was not installed on all related hosts, so I settled on:
test -t 0 && (which stty 2>&1 >/dev/null) && stty start undef test -t 0 && (which stty 2>&1 >/dev/null) && stty stop undef
Notes
The screen package (see above) also has this option. I've yet to figure out whether it may set ixon back on(verify).
This function may also be mapped to scroll lock -- but only to text-mode terminals; this is rarely emulated by windowed shells.