The Linux virtual terminal (tty) is an emulation of VT102 - Virtual terminal subsystem source.

The real VT100 (nearly the same as VT102) has the following behavior (I suppose):

  • In the LINE mode all typed characters are first transmitted to the computer and then, returned to the terminal. Nothing is displayed on the terminal screen before returning from the host.
  • The escape sequences are no exception - they are parsed and executed only after returning from the host. That is, if I want to change the font color to red, I should type ESC[0;31m, this sequence goes to the computer, echoed back, VT102 receive this, parse and apply. There is no other way to change the terminal font color (in the LINE mode). I am not sure if the VT102 had different font colors though, but that is an example.

Picture from manual:

enter image description here

Excerpt from manual:


The LINE/LOCAL feature allows the operator to easily place the terminal in either an ON-LINE or a LOCAL (off-line) condition. When the terminal is on-line (ON-LINE indicator is lit) all characters typed on the keyboard are sent directly to the computer and messages from the computer are displayed on the screen. In the LOCAL condition (LOCAL indicator is lit), the terminal is electrically disconnected from the computer; messages are not sent to or received from the computer; and characters typed on the keyboard are echoed on the screen directly.

Source: VT100 series video terminal technical manual, third Edition, July 1982.

The question

Why does the Linux tty behave in a different way?

I put the bash into the sleep mode, so it doesn't interfere, then type Esc[0;31m and get just plain text, the color haven't changed - so, escape sequence has no effect.

enter image description here

I were ask the similar question couple of years ago - Why i can't send escape sequences from keyboard, but can do it from another tty?, but now I got the knowledge about VT102 Linux subsystem and want to understand why it works this way - not identically to the real hardware terminal in this aspect.

enter image description here

  • 1
    There is no such thing as "sleep mode". There is the sleep utility that just sleeps. While that utility is running, just like when any other utility is running in the foreground, the input that you type is buffered. If the utility reads its standard input stream, it would see what you typed, otherwise the shell would get it when the utility terminates. Until something reads what you have typed, it can not be interpreted as a colour-changing escape sequence.
    – Kusalananda
    May 11, 2019 at 14:53
  • @Kusalananda I agree. It is just abstract phrase, pointing to the fact that bash is not interfere. "I put the bash into the sleep mode, so it doesn't interfere" - how it can be rephrased to better, while saving sense and clarity? "Disable bash" - also isn't right.
    – MiniMax
    May 11, 2019 at 15:03
  • @Kusalananda "I use the sleep program to stop the bash from interfering" - good?
    – MiniMax
    May 11, 2019 at 15:07

3 Answers 3


Firstly, this question was asked on Retrocomputing, but the community found it more suitable for this site. But I got an answer in the comment section, so copy it here:

The Linux virtual console emulates a (sort of) VT102 terminal in ON-LINE mode connected to a Linux (serial) tty device. The Linux tty driver doesn't normally echo back the escape control character, and instead echos ^[. If you don't want the tty driver to do this, then use stty -ctlecho. Also real VT102 terminals don't support colour, it works with the Linux virtual console anyways because its not really VT102 compatible.

I have tried the stty -ctlecho and it works almost as expected - only one subquestion - is the real VT102 also wasn't displaying characters after person press ESC and start type escape sequence, so the person were type it in the blind manner?


Long question, reduced to

Why the Linux tty behaves in different way?

Actually it's not the tty, but the application (such as your shell) which controls what and how characters are echoed. You can use the stty application to change the terminal mode temporarily (some shells will change it back), e.g.,

stty -cooked

(making it "raw", telling the terminal driver to not interfere).

  • But I disabled bash by sleep 10m command, so it is not interfering. Anyway the stty is the right approach. I added answer by myself.
    – MiniMax
    May 11, 2019 at 14:40
  • stty -cooked works too, but stty -ctlecho more convenient, because it is disabling only the unneeded part. More fine grained way.
    – MiniMax
    May 11, 2019 at 14:46
  • Well, it IS the tty controlling the echo behavior, it's part of the tty's state. But application can change the state May 11, 2019 at 15:06
  • The tty driver is a program, which is not the same thing as the tty. May 11, 2019 at 15:12

...type it in the blind manner

We are getting close, I think. You did quite a nice documentation. Just the demo is missing! In your old Q send-escape-sequences-from-keyboard you only show what does NOT work! And both the titles??? Can you not make that clearer? And a screenshot like mine (in my answer to above linked Q)

Nobody was meant to enter one of these long sequences blindly. On a nicely setup VTxxx you would have special keys and special bindings, maybe shell functions, where the CSs are stored. On a system like that, everything is coordinated. Linux and xterm are emulating it because it's the only thing close to a standard.

But yes, the Escape key does mean: the next key is not input, but a command. So somebody has to start hold back the bytes and check for a predefined sequence.

But if the sequence gets impossible, the shell falls out of Escape mode and starts echoing again. Press Escape, [, then 1,1,1...and the bracket and two "1" get lost.

Try to enter [32m after an Escape...the "m" reappears again, which means, the shell gave up on that sequence. The useless ^[[32 is lost, I should say, somewhere.

Knock out bash/readline, put tty out of work: you will be left with just a kid's toy where you can place colored letters (bold, underlined, blinking, invisible) all over your screen.

I don't understand your Q. An "echoed Escape sequence" is for me one that did not make it to the target and really got reflected. Like when I try to use Left Arrow at the read prompt (after typing abc):

$  read

At the normal prompt, when I type "abc", then Escape, then blindly "[D" the cursor moves left. The Arrow key is just an easier way to generate that.

To get your sequences through, use echo -e '\e...' or echo '^[...' (with ctrl-V). That way the shell sends the escape and does not interpret (cook?) it.

And with stty -echoctl and sleep 1000 you have even discovered a way to throw a CS into tty's face directly. Sorry: tty's driver's face.

[here I need an even better change-color-while-bash-is-sleeping-and-tty-offguard jpeg...]

You must log in to answer this question.

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