0

I cannot use any console based text editors because my Ctrl+S is blocked by console output control -- Ctrl+S normally means stop scrolling under console or terminal, and my screen is eating that key, and not passing to the console based text editors that I'm using (which normally associate with saving the file).

I cannot prove that until I installed dte today, which has a special mode of

-K Start in a special mode that continuously reads input and prints the name and numeric code of each pressed key.

and here is my output:

$ dte -K
Press any key combination, or use Ctrl+D to exit
   C-A          0x1000041     
   C-A          0x1000041     
   C-X          0x1000058     
   C-C          0x1000043     
   C-D          0x1000044   

$ echo $TERM
screen

As we can see that even Ctrl+C can be passed to text editor, but I've pressed Ctrl+S (then Ctrl+Q) many times during this process but they all get eaten by my screen.

How to enable my Ctrl+S and Ctrl+Q for console based text editors within screen?

The machine is Debian WSL:

$ uname -rm
4.4.0-19041-Microsoft x86_64

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

UPDATE:

The problem is only under screen. xterm or xterm-256color alone are just fine:

$ dte -K
Press any key combination, or use Ctrl+D to exit
   C-X          0x1000058     
   C-S          0x1000053     
   C-Q          0x1000051     
   C-C          0x1000043     
   C-D          0x1000044     

$ echo $TERM
xterm

UPDATE 2:

Confirmed from man screen that it is indeed screen causing the problem:

       C-a s,             (xoff)            Send a control-s  to  the  current
       C-a C-s;                             window.
       ------------------------------------------------------------------------
       C-a q,             (xon)             Send a control-q  to  the  current
       C-a C-q                              window.

and I've found doc about it:

When flow-control is turned off, screen ignores the XON and XOFF characters, which allows the user to send them to the current program by simply typing them (useful for the emacs editor, for instance).

but I haven't found how to turn off flow-control by default to all screen windows.

1
  • 1
    The screen command defflow off should set flow-control off by default.
    – meuh
    Commented Jun 6, 2021 at 12:26

1 Answer 1

0

To disable Ctrl+S and Ctrl+Q in terminal, add this line at the end of the .bashrc script:

stty -ixon

The stty man page describes the ixon option as:

[-]ixon
       enable XON/XOFF flow control

An explanation of why this ancient feature exists and what it relates to can be found in this excellent answer:

Long before there were computers, there were teleprinters (a.k.a. teletypewriters, a.k.a. teletypes). Think of them as roughly the same technology as a telegraph, but with some type of keyboard and some type of printer attached to them.

Because teletypes already existed when computers were first being built, and because computers at the time were room-sized, teletypes became a convenient user interface to the first computers – type in a command, hit the send button, wait for a while, and the output of the command is printed to a sheet of paper in front of you.

Software flow control originated around this era – if the printer couldn't print as fast as the teletype was receiving data, for instance, the teletype could send an XOFF flow control command (Ctrl+S) to the remote side saying "Stop transmitting for now", and then could send the XON flow control command (Ctrl+Q) to the remote side saying "I've caught up, please continue".

And this usage survives in Unix because modern terminal emulators are emulating physical terminals (like the vt100) which themselves were (in some ways) emulating teletypes.

1
  • Thanks! Although I tried stty -ixon within screen after your suggestion, but Ctrl+S / Ctrl+Q are still got eaten by my screen. I guess xterm or xterm-256color alone are just fine proves/indicates that. I.e., xterm alone just fine, but when I start screen within it, the problem occurs.
    – xpt
    Commented Jun 4, 2021 at 20:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .