Echoed escape sequences doesn't interpreted in Linux tty

Question

Prerequisites

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:

Excerpt from manual:

LINE/LOCAL

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.

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.

Answer 1

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?

Answer 2

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).

Answer 3

...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
abc^[[D

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...]