Can escape sequences be entered directly from keyboard to terminal for VT100 and similar?
TL;DR:
In video terminals, like the VT100, can control characters and escape sequences only be sent by an application from the host computer to the terminal? Or can they also be sent directly by the user from the keyboard to the terminal? That is, the user controlling the terminal from the keyboard, rather than an application controlling the terminal from the host computer?
Long version:
I'm trying to understand how video terminals worked by the example of the VT100 family.
I found the following diagram of a VT102 in the VT102 user guide (Figure 1-1).
I assume that on the computer-side of the communication line, there is a driver for this type of terminal, and behind the driver there is an application that reads its input from the terminal and writes its output to the terminal (through the driver). This application might be a shell, or any other application that needs to get input from the user and/or show output to the user.
What I understood so far:
- When a user of the terminal types a character on the keyboard, this character is immediately transmitted to the computer (i.e. the VT100 family uses character-at-a-time mode, there is no local processing of characters entered by the user).
- The receiving application on the computer can then read this character from the terminal driver and do with it whatever it has to do with it.
- Every character that the writes to its output (which is the terminal driver) is sent to the terminal where it is displayed on the screen (except control characters and escape sequences, see below).
- If the application-specific purpose of a character sent from the terminal to the application is such that the user should see it on the screen, then the application must send this character back to the terminal so that it gets displayed on the terminal screen. That is, the VT100 family uses, in most cases, no local echo However, for the VT102, local echo is a setting that can be enabled, see here. This becomes obvious if the application on the computer is something like vi. There, not all characters that the user types must appear on the screen. In particular, characters typed in command mode must not be displayed, whereas characters typed in insert mode must be displayed. This modes are application-specific and neither the terminal nor the terminal driver could know if a given typed character should be displayed or not. So, in these cases, it must be the application that controls the display of user-typed characters.
First of all, are these assumptions correct?
Now to the question. The terminal understands and interprets certain control characters and escape sequences that can be sent from the computer to the terminal. Each of them has an associated control function (e.g. move the cursor on the terminal screen). When the terminal receives such a control character or escape sequence, it does not display it, but executes the associated control function. This stands in contrast to the display characters (non-control characters and not part of an escape sequence) which the terminal just displays on the screen when it receives them.
Control characters, escape sequences, and display characters can be intermixed in any way (there is only a single transmission line from the computer to the terminal anyway). All the control characters and escape sequences that the VT102 understands are explained in the Received Character Processing section of the VT102 user guide.
Control characters are ASCII control characters. The set of control characters understood by the VT10, including the associated control functions, is listed here.
Escape sequences are sequences of characters that start with a special "escape character". The escape sequences understood by the VT102 are the ANSI escape sequences, and they are described in the Escape and Control Sequences section of the VT102 user guide. They always start with the ESC character followed by some other characters.
Control functions associated with VT102 control characters and escape sequences include positioning the cursor on the screen, deleting text on the screen, and setting display attributes (like text colour or font style). This allows applications to control what the user sees on the terminal screen (for example, vi redraws the entire terminal screen when it is started).
Now, my question is, are these control characters and escape sequences only meant to be sent from the application to the terminal? Or is there a way that a user enters them directly into the terminal, e.g. via the keyboard?
The Transmitted Characters section of the VT102 user guide describes all the characters that can be generated with the keyboard. They include control characters and some escape sequences. Are all these characters always sent to the computer without interpretation by the terminal?
For example, if the user hits the ← cursor key, the VT102 user guide says here that this generates the ESC [ D
escape sequence. This is the ANSI escape sequence to move the cursor one position back (see here). So, is this escape sequence still sent to the application rather than being interpreted by the terminal? And then the application interprets it and has to send something back to take an appropriate action on the terminal (probably the ESC [ D
again)?
Or is there a set of control characters or escape sequences that the terminal directly interprets when the user types them on the keyboard (maybe a reduced, different set)?
EDIT
This is a diagram of the VT102 in off-line mode (i.e. when not connected to a computer), see here:
This makes it obvious that in off-line mode anything typed on the keyboard is directly re-routed to the receiver, and thus probably treated as if it would come from the computer.
My question was if in on-line mode (see diagram above) any control characters pressed on the keyboard are directly interpreted by the terminal rather than being sent to the computer?
terminal vt100 escape-codes
New contributor
|
show 1 more comment
TL;DR:
In video terminals, like the VT100, can control characters and escape sequences only be sent by an application from the host computer to the terminal? Or can they also be sent directly by the user from the keyboard to the terminal? That is, the user controlling the terminal from the keyboard, rather than an application controlling the terminal from the host computer?
Long version:
I'm trying to understand how video terminals worked by the example of the VT100 family.
I found the following diagram of a VT102 in the VT102 user guide (Figure 1-1).
I assume that on the computer-side of the communication line, there is a driver for this type of terminal, and behind the driver there is an application that reads its input from the terminal and writes its output to the terminal (through the driver). This application might be a shell, or any other application that needs to get input from the user and/or show output to the user.
What I understood so far:
- When a user of the terminal types a character on the keyboard, this character is immediately transmitted to the computer (i.e. the VT100 family uses character-at-a-time mode, there is no local processing of characters entered by the user).
- The receiving application on the computer can then read this character from the terminal driver and do with it whatever it has to do with it.
- Every character that the writes to its output (which is the terminal driver) is sent to the terminal where it is displayed on the screen (except control characters and escape sequences, see below).
- If the application-specific purpose of a character sent from the terminal to the application is such that the user should see it on the screen, then the application must send this character back to the terminal so that it gets displayed on the terminal screen. That is, the VT100 family uses, in most cases, no local echo However, for the VT102, local echo is a setting that can be enabled, see here. This becomes obvious if the application on the computer is something like vi. There, not all characters that the user types must appear on the screen. In particular, characters typed in command mode must not be displayed, whereas characters typed in insert mode must be displayed. This modes are application-specific and neither the terminal nor the terminal driver could know if a given typed character should be displayed or not. So, in these cases, it must be the application that controls the display of user-typed characters.
First of all, are these assumptions correct?
Now to the question. The terminal understands and interprets certain control characters and escape sequences that can be sent from the computer to the terminal. Each of them has an associated control function (e.g. move the cursor on the terminal screen). When the terminal receives such a control character or escape sequence, it does not display it, but executes the associated control function. This stands in contrast to the display characters (non-control characters and not part of an escape sequence) which the terminal just displays on the screen when it receives them.
Control characters, escape sequences, and display characters can be intermixed in any way (there is only a single transmission line from the computer to the terminal anyway). All the control characters and escape sequences that the VT102 understands are explained in the Received Character Processing section of the VT102 user guide.
Control characters are ASCII control characters. The set of control characters understood by the VT10, including the associated control functions, is listed here.
Escape sequences are sequences of characters that start with a special "escape character". The escape sequences understood by the VT102 are the ANSI escape sequences, and they are described in the Escape and Control Sequences section of the VT102 user guide. They always start with the ESC character followed by some other characters.
Control functions associated with VT102 control characters and escape sequences include positioning the cursor on the screen, deleting text on the screen, and setting display attributes (like text colour or font style). This allows applications to control what the user sees on the terminal screen (for example, vi redraws the entire terminal screen when it is started).
Now, my question is, are these control characters and escape sequences only meant to be sent from the application to the terminal? Or is there a way that a user enters them directly into the terminal, e.g. via the keyboard?
The Transmitted Characters section of the VT102 user guide describes all the characters that can be generated with the keyboard. They include control characters and some escape sequences. Are all these characters always sent to the computer without interpretation by the terminal?
For example, if the user hits the ← cursor key, the VT102 user guide says here that this generates the ESC [ D
escape sequence. This is the ANSI escape sequence to move the cursor one position back (see here). So, is this escape sequence still sent to the application rather than being interpreted by the terminal? And then the application interprets it and has to send something back to take an appropriate action on the terminal (probably the ESC [ D
again)?
Or is there a set of control characters or escape sequences that the terminal directly interprets when the user types them on the keyboard (maybe a reduced, different set)?
EDIT
This is a diagram of the VT102 in off-line mode (i.e. when not connected to a computer), see here:
This makes it obvious that in off-line mode anything typed on the keyboard is directly re-routed to the receiver, and thus probably treated as if it would come from the computer.
My question was if in on-line mode (see diagram above) any control characters pressed on the keyboard are directly interpreted by the terminal rather than being sent to the computer?
terminal vt100 escape-codes
New contributor
1
Does anyone else remember when CSI was Control Sequence Introducer ( <esc>[ ), not Crime Scene Investigation? ... {sigh} I was a nerd too soon.
– RichF
2 days ago
1
Indeed. And all my VMS screen-updatey code used the 8-bit CSI (0x9B) rather than ESC [ when the terminal would support it. When you're optimizing for minimal character output on a slow async line, every octet counts.
– another-dave
2 days ago
It's worth noting in passing that a large number of intermediaries such as modems could be put into a loopback mode that would produce the same effect as local mode.
– Walter Mitty
2 days ago
There was also the paper-clip method of terminal testing: Bend a paper clip and put one end in pin 2 and the other in pin 3 to effectively create a local echo. Depending on the terminal & serial port configuration, additional paper clips may be required for hardware handshaking.
– manassehkatz
2 days ago
1
Clippy: "I see you're trying to improvise a loopback connector. Can I .... wait, wait, what are you doing? Put me down! Ow, that hurts!"
– another-dave
2 days ago
|
show 1 more comment
TL;DR:
In video terminals, like the VT100, can control characters and escape sequences only be sent by an application from the host computer to the terminal? Or can they also be sent directly by the user from the keyboard to the terminal? That is, the user controlling the terminal from the keyboard, rather than an application controlling the terminal from the host computer?
Long version:
I'm trying to understand how video terminals worked by the example of the VT100 family.
I found the following diagram of a VT102 in the VT102 user guide (Figure 1-1).
I assume that on the computer-side of the communication line, there is a driver for this type of terminal, and behind the driver there is an application that reads its input from the terminal and writes its output to the terminal (through the driver). This application might be a shell, or any other application that needs to get input from the user and/or show output to the user.
What I understood so far:
- When a user of the terminal types a character on the keyboard, this character is immediately transmitted to the computer (i.e. the VT100 family uses character-at-a-time mode, there is no local processing of characters entered by the user).
- The receiving application on the computer can then read this character from the terminal driver and do with it whatever it has to do with it.
- Every character that the writes to its output (which is the terminal driver) is sent to the terminal where it is displayed on the screen (except control characters and escape sequences, see below).
- If the application-specific purpose of a character sent from the terminal to the application is such that the user should see it on the screen, then the application must send this character back to the terminal so that it gets displayed on the terminal screen. That is, the VT100 family uses, in most cases, no local echo However, for the VT102, local echo is a setting that can be enabled, see here. This becomes obvious if the application on the computer is something like vi. There, not all characters that the user types must appear on the screen. In particular, characters typed in command mode must not be displayed, whereas characters typed in insert mode must be displayed. This modes are application-specific and neither the terminal nor the terminal driver could know if a given typed character should be displayed or not. So, in these cases, it must be the application that controls the display of user-typed characters.
First of all, are these assumptions correct?
Now to the question. The terminal understands and interprets certain control characters and escape sequences that can be sent from the computer to the terminal. Each of them has an associated control function (e.g. move the cursor on the terminal screen). When the terminal receives such a control character or escape sequence, it does not display it, but executes the associated control function. This stands in contrast to the display characters (non-control characters and not part of an escape sequence) which the terminal just displays on the screen when it receives them.
Control characters, escape sequences, and display characters can be intermixed in any way (there is only a single transmission line from the computer to the terminal anyway). All the control characters and escape sequences that the VT102 understands are explained in the Received Character Processing section of the VT102 user guide.
Control characters are ASCII control characters. The set of control characters understood by the VT10, including the associated control functions, is listed here.
Escape sequences are sequences of characters that start with a special "escape character". The escape sequences understood by the VT102 are the ANSI escape sequences, and they are described in the Escape and Control Sequences section of the VT102 user guide. They always start with the ESC character followed by some other characters.
Control functions associated with VT102 control characters and escape sequences include positioning the cursor on the screen, deleting text on the screen, and setting display attributes (like text colour or font style). This allows applications to control what the user sees on the terminal screen (for example, vi redraws the entire terminal screen when it is started).
Now, my question is, are these control characters and escape sequences only meant to be sent from the application to the terminal? Or is there a way that a user enters them directly into the terminal, e.g. via the keyboard?
The Transmitted Characters section of the VT102 user guide describes all the characters that can be generated with the keyboard. They include control characters and some escape sequences. Are all these characters always sent to the computer without interpretation by the terminal?
For example, if the user hits the ← cursor key, the VT102 user guide says here that this generates the ESC [ D
escape sequence. This is the ANSI escape sequence to move the cursor one position back (see here). So, is this escape sequence still sent to the application rather than being interpreted by the terminal? And then the application interprets it and has to send something back to take an appropriate action on the terminal (probably the ESC [ D
again)?
Or is there a set of control characters or escape sequences that the terminal directly interprets when the user types them on the keyboard (maybe a reduced, different set)?
EDIT
This is a diagram of the VT102 in off-line mode (i.e. when not connected to a computer), see here:
This makes it obvious that in off-line mode anything typed on the keyboard is directly re-routed to the receiver, and thus probably treated as if it would come from the computer.
My question was if in on-line mode (see diagram above) any control characters pressed on the keyboard are directly interpreted by the terminal rather than being sent to the computer?
terminal vt100 escape-codes
New contributor
TL;DR:
In video terminals, like the VT100, can control characters and escape sequences only be sent by an application from the host computer to the terminal? Or can they also be sent directly by the user from the keyboard to the terminal? That is, the user controlling the terminal from the keyboard, rather than an application controlling the terminal from the host computer?
Long version:
I'm trying to understand how video terminals worked by the example of the VT100 family.
I found the following diagram of a VT102 in the VT102 user guide (Figure 1-1).
I assume that on the computer-side of the communication line, there is a driver for this type of terminal, and behind the driver there is an application that reads its input from the terminal and writes its output to the terminal (through the driver). This application might be a shell, or any other application that needs to get input from the user and/or show output to the user.
What I understood so far:
- When a user of the terminal types a character on the keyboard, this character is immediately transmitted to the computer (i.e. the VT100 family uses character-at-a-time mode, there is no local processing of characters entered by the user).
- The receiving application on the computer can then read this character from the terminal driver and do with it whatever it has to do with it.
- Every character that the writes to its output (which is the terminal driver) is sent to the terminal where it is displayed on the screen (except control characters and escape sequences, see below).
- If the application-specific purpose of a character sent from the terminal to the application is such that the user should see it on the screen, then the application must send this character back to the terminal so that it gets displayed on the terminal screen. That is, the VT100 family uses, in most cases, no local echo However, for the VT102, local echo is a setting that can be enabled, see here. This becomes obvious if the application on the computer is something like vi. There, not all characters that the user types must appear on the screen. In particular, characters typed in command mode must not be displayed, whereas characters typed in insert mode must be displayed. This modes are application-specific and neither the terminal nor the terminal driver could know if a given typed character should be displayed or not. So, in these cases, it must be the application that controls the display of user-typed characters.
First of all, are these assumptions correct?
Now to the question. The terminal understands and interprets certain control characters and escape sequences that can be sent from the computer to the terminal. Each of them has an associated control function (e.g. move the cursor on the terminal screen). When the terminal receives such a control character or escape sequence, it does not display it, but executes the associated control function. This stands in contrast to the display characters (non-control characters and not part of an escape sequence) which the terminal just displays on the screen when it receives them.
Control characters, escape sequences, and display characters can be intermixed in any way (there is only a single transmission line from the computer to the terminal anyway). All the control characters and escape sequences that the VT102 understands are explained in the Received Character Processing section of the VT102 user guide.
Control characters are ASCII control characters. The set of control characters understood by the VT10, including the associated control functions, is listed here.
Escape sequences are sequences of characters that start with a special "escape character". The escape sequences understood by the VT102 are the ANSI escape sequences, and they are described in the Escape and Control Sequences section of the VT102 user guide. They always start with the ESC character followed by some other characters.
Control functions associated with VT102 control characters and escape sequences include positioning the cursor on the screen, deleting text on the screen, and setting display attributes (like text colour or font style). This allows applications to control what the user sees on the terminal screen (for example, vi redraws the entire terminal screen when it is started).
Now, my question is, are these control characters and escape sequences only meant to be sent from the application to the terminal? Or is there a way that a user enters them directly into the terminal, e.g. via the keyboard?
The Transmitted Characters section of the VT102 user guide describes all the characters that can be generated with the keyboard. They include control characters and some escape sequences. Are all these characters always sent to the computer without interpretation by the terminal?
For example, if the user hits the ← cursor key, the VT102 user guide says here that this generates the ESC [ D
escape sequence. This is the ANSI escape sequence to move the cursor one position back (see here). So, is this escape sequence still sent to the application rather than being interpreted by the terminal? And then the application interprets it and has to send something back to take an appropriate action on the terminal (probably the ESC [ D
again)?
Or is there a set of control characters or escape sequences that the terminal directly interprets when the user types them on the keyboard (maybe a reduced, different set)?
EDIT
This is a diagram of the VT102 in off-line mode (i.e. when not connected to a computer), see here:
This makes it obvious that in off-line mode anything typed on the keyboard is directly re-routed to the receiver, and thus probably treated as if it would come from the computer.
My question was if in on-line mode (see diagram above) any control characters pressed on the keyboard are directly interpreted by the terminal rather than being sent to the computer?
terminal vt100 escape-codes
terminal vt100 escape-codes
New contributor
New contributor
edited 2 days ago
weibeld
New contributor
asked 2 days ago
weibeldweibeld
22117
22117
New contributor
New contributor
1
Does anyone else remember when CSI was Control Sequence Introducer ( <esc>[ ), not Crime Scene Investigation? ... {sigh} I was a nerd too soon.
– RichF
2 days ago
1
Indeed. And all my VMS screen-updatey code used the 8-bit CSI (0x9B) rather than ESC [ when the terminal would support it. When you're optimizing for minimal character output on a slow async line, every octet counts.
– another-dave
2 days ago
It's worth noting in passing that a large number of intermediaries such as modems could be put into a loopback mode that would produce the same effect as local mode.
– Walter Mitty
2 days ago
There was also the paper-clip method of terminal testing: Bend a paper clip and put one end in pin 2 and the other in pin 3 to effectively create a local echo. Depending on the terminal & serial port configuration, additional paper clips may be required for hardware handshaking.
– manassehkatz
2 days ago
1
Clippy: "I see you're trying to improvise a loopback connector. Can I .... wait, wait, what are you doing? Put me down! Ow, that hurts!"
– another-dave
2 days ago
|
show 1 more comment
1
Does anyone else remember when CSI was Control Sequence Introducer ( <esc>[ ), not Crime Scene Investigation? ... {sigh} I was a nerd too soon.
– RichF
2 days ago
1
Indeed. And all my VMS screen-updatey code used the 8-bit CSI (0x9B) rather than ESC [ when the terminal would support it. When you're optimizing for minimal character output on a slow async line, every octet counts.
– another-dave
2 days ago
It's worth noting in passing that a large number of intermediaries such as modems could be put into a loopback mode that would produce the same effect as local mode.
– Walter Mitty
2 days ago
There was also the paper-clip method of terminal testing: Bend a paper clip and put one end in pin 2 and the other in pin 3 to effectively create a local echo. Depending on the terminal & serial port configuration, additional paper clips may be required for hardware handshaking.
– manassehkatz
2 days ago
1
Clippy: "I see you're trying to improvise a loopback connector. Can I .... wait, wait, what are you doing? Put me down! Ow, that hurts!"
– another-dave
2 days ago
1
1
Does anyone else remember when CSI was Control Sequence Introducer ( <esc>[ ), not Crime Scene Investigation? ... {sigh} I was a nerd too soon.
– RichF
2 days ago
Does anyone else remember when CSI was Control Sequence Introducer ( <esc>[ ), not Crime Scene Investigation? ... {sigh} I was a nerd too soon.
– RichF
2 days ago
1
1
Indeed. And all my VMS screen-updatey code used the 8-bit CSI (0x9B) rather than ESC [ when the terminal would support it. When you're optimizing for minimal character output on a slow async line, every octet counts.
– another-dave
2 days ago
Indeed. And all my VMS screen-updatey code used the 8-bit CSI (0x9B) rather than ESC [ when the terminal would support it. When you're optimizing for minimal character output on a slow async line, every octet counts.
– another-dave
2 days ago
It's worth noting in passing that a large number of intermediaries such as modems could be put into a loopback mode that would produce the same effect as local mode.
– Walter Mitty
2 days ago
It's worth noting in passing that a large number of intermediaries such as modems could be put into a loopback mode that would produce the same effect as local mode.
– Walter Mitty
2 days ago
There was also the paper-clip method of terminal testing: Bend a paper clip and put one end in pin 2 and the other in pin 3 to effectively create a local echo. Depending on the terminal & serial port configuration, additional paper clips may be required for hardware handshaking.
– manassehkatz
2 days ago
There was also the paper-clip method of terminal testing: Bend a paper clip and put one end in pin 2 and the other in pin 3 to effectively create a local echo. Depending on the terminal & serial port configuration, additional paper clips may be required for hardware handshaking.
– manassehkatz
2 days ago
1
1
Clippy: "I see you're trying to improvise a loopback connector. Can I .... wait, wait, what are you doing? Put me down! Ow, that hurts!"
– another-dave
2 days ago
Clippy: "I see you're trying to improvise a loopback connector. Can I .... wait, wait, what are you doing? Put me down! Ow, that hurts!"
– another-dave
2 days ago
|
show 1 more comment
1 Answer
1
active
oldest
votes
Well, as usual with complex matter the answer is a mixture of Yes/If.
First of all, are these assumptions correct?
Yes, the assumptions stated are perfect good and correct. In general. In detail there can be diversions, most depending on line characteristics (like blocking and error correcting modems), and ways the computer/its OS is designed.
Now, my question is, are these control characters and escape sequences only meant to be sent from the application to the terminal? Or is there a way that a user enters them directly into the terminal, e.g. via the keyboard?
Yes, there is. And you presented already all parts necessary.
In
- Off-Line mode (
SETUP
-4
-SETUP
), as well as - Local mode
every key press is right away handed to the receive function and interpreted. THat way one can try out whatever function combination needed without much software tools. Well, at least that's the way we did it to check functions and parameters when debugging :))
Or is there a set of control characters or escape sequences that the terminal directly interprets when the user types them on the keyboard (maybe a reduced, different set)?
No. None at all. Wouldn't make much sense anyway. Either output displayed (characters and operations) is controlled by the host, or the host just interpretes the input, assuming everything the user does is legal anyway - or doesn't care what's displayed anyway.
Especially the later may seem strange, but it was quite handy back then to keep programs simple. Why care for stuff a sane user wouldn't do anyway.
Ok, that helped.So for controlling the terminal from your keyboard in off-line or local mode, are you confined to those control characters that your keyboard can generate with a single key press, like those here? Or can you somehow freely compose ANSI escape sequences on your keyboard and send to your terminal in off-line or local mode?
– weibeld
2 days ago
Serial lines could be really slow, so normally there is no timeout and you can type one character at a time.
– grahamj42
2 days ago
@weibeld No, there is (usually) no time out (as graham already pointed out). After all, a computer could as well have a hickup when sending out characters (like a priority task pushing the user task away) right in the middle of an escape sequence. Also, what would be a timeout be good for? How to recover from a half ESC sequence - which may not have been one at all? Any setting of a timeout for escape sequences would create more harm than good. No, only host programs may do so to detect the ESC key alone. So feel free to assemble whatever ESC sequence you want by hand.
– Raffzahn
2 days ago
1
@Raffzahn If I understand you correctly, when the user types ESC on the keyboard, this character is sent to the host computer in the same way as any other character?
– weibeld
2 days ago
1
@Random832 Ah ok, now I understand the comments with the timeout. In local mode you can just type any stream of characters on the keyboard, and they will be handled by the receiver of the terminal like the stream of characters that usually comes from the computer. In this way, you can simulate the effects of any output of your application. And no timeout in local mode: you can typeESC
on the keyboard and, for example, only one minute later[
, and this would still be interpreted as a valid escape sequence by the receiver of the terminal. If I understand it correctly.
– weibeld
10 hours ago
|
show 6 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
weibeld is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8843%2fcan-escape-sequences-be-entered-directly-from-keyboard-to-terminal-for-vt100-and%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Well, as usual with complex matter the answer is a mixture of Yes/If.
First of all, are these assumptions correct?
Yes, the assumptions stated are perfect good and correct. In general. In detail there can be diversions, most depending on line characteristics (like blocking and error correcting modems), and ways the computer/its OS is designed.
Now, my question is, are these control characters and escape sequences only meant to be sent from the application to the terminal? Or is there a way that a user enters them directly into the terminal, e.g. via the keyboard?
Yes, there is. And you presented already all parts necessary.
In
- Off-Line mode (
SETUP
-4
-SETUP
), as well as - Local mode
every key press is right away handed to the receive function and interpreted. THat way one can try out whatever function combination needed without much software tools. Well, at least that's the way we did it to check functions and parameters when debugging :))
Or is there a set of control characters or escape sequences that the terminal directly interprets when the user types them on the keyboard (maybe a reduced, different set)?
No. None at all. Wouldn't make much sense anyway. Either output displayed (characters and operations) is controlled by the host, or the host just interpretes the input, assuming everything the user does is legal anyway - or doesn't care what's displayed anyway.
Especially the later may seem strange, but it was quite handy back then to keep programs simple. Why care for stuff a sane user wouldn't do anyway.
Ok, that helped.So for controlling the terminal from your keyboard in off-line or local mode, are you confined to those control characters that your keyboard can generate with a single key press, like those here? Or can you somehow freely compose ANSI escape sequences on your keyboard and send to your terminal in off-line or local mode?
– weibeld
2 days ago
Serial lines could be really slow, so normally there is no timeout and you can type one character at a time.
– grahamj42
2 days ago
@weibeld No, there is (usually) no time out (as graham already pointed out). After all, a computer could as well have a hickup when sending out characters (like a priority task pushing the user task away) right in the middle of an escape sequence. Also, what would be a timeout be good for? How to recover from a half ESC sequence - which may not have been one at all? Any setting of a timeout for escape sequences would create more harm than good. No, only host programs may do so to detect the ESC key alone. So feel free to assemble whatever ESC sequence you want by hand.
– Raffzahn
2 days ago
1
@Raffzahn If I understand you correctly, when the user types ESC on the keyboard, this character is sent to the host computer in the same way as any other character?
– weibeld
2 days ago
1
@Random832 Ah ok, now I understand the comments with the timeout. In local mode you can just type any stream of characters on the keyboard, and they will be handled by the receiver of the terminal like the stream of characters that usually comes from the computer. In this way, you can simulate the effects of any output of your application. And no timeout in local mode: you can typeESC
on the keyboard and, for example, only one minute later[
, and this would still be interpreted as a valid escape sequence by the receiver of the terminal. If I understand it correctly.
– weibeld
10 hours ago
|
show 6 more comments
Well, as usual with complex matter the answer is a mixture of Yes/If.
First of all, are these assumptions correct?
Yes, the assumptions stated are perfect good and correct. In general. In detail there can be diversions, most depending on line characteristics (like blocking and error correcting modems), and ways the computer/its OS is designed.
Now, my question is, are these control characters and escape sequences only meant to be sent from the application to the terminal? Or is there a way that a user enters them directly into the terminal, e.g. via the keyboard?
Yes, there is. And you presented already all parts necessary.
In
- Off-Line mode (
SETUP
-4
-SETUP
), as well as - Local mode
every key press is right away handed to the receive function and interpreted. THat way one can try out whatever function combination needed without much software tools. Well, at least that's the way we did it to check functions and parameters when debugging :))
Or is there a set of control characters or escape sequences that the terminal directly interprets when the user types them on the keyboard (maybe a reduced, different set)?
No. None at all. Wouldn't make much sense anyway. Either output displayed (characters and operations) is controlled by the host, or the host just interpretes the input, assuming everything the user does is legal anyway - or doesn't care what's displayed anyway.
Especially the later may seem strange, but it was quite handy back then to keep programs simple. Why care for stuff a sane user wouldn't do anyway.
Ok, that helped.So for controlling the terminal from your keyboard in off-line or local mode, are you confined to those control characters that your keyboard can generate with a single key press, like those here? Or can you somehow freely compose ANSI escape sequences on your keyboard and send to your terminal in off-line or local mode?
– weibeld
2 days ago
Serial lines could be really slow, so normally there is no timeout and you can type one character at a time.
– grahamj42
2 days ago
@weibeld No, there is (usually) no time out (as graham already pointed out). After all, a computer could as well have a hickup when sending out characters (like a priority task pushing the user task away) right in the middle of an escape sequence. Also, what would be a timeout be good for? How to recover from a half ESC sequence - which may not have been one at all? Any setting of a timeout for escape sequences would create more harm than good. No, only host programs may do so to detect the ESC key alone. So feel free to assemble whatever ESC sequence you want by hand.
– Raffzahn
2 days ago
1
@Raffzahn If I understand you correctly, when the user types ESC on the keyboard, this character is sent to the host computer in the same way as any other character?
– weibeld
2 days ago
1
@Random832 Ah ok, now I understand the comments with the timeout. In local mode you can just type any stream of characters on the keyboard, and they will be handled by the receiver of the terminal like the stream of characters that usually comes from the computer. In this way, you can simulate the effects of any output of your application. And no timeout in local mode: you can typeESC
on the keyboard and, for example, only one minute later[
, and this would still be interpreted as a valid escape sequence by the receiver of the terminal. If I understand it correctly.
– weibeld
10 hours ago
|
show 6 more comments
Well, as usual with complex matter the answer is a mixture of Yes/If.
First of all, are these assumptions correct?
Yes, the assumptions stated are perfect good and correct. In general. In detail there can be diversions, most depending on line characteristics (like blocking and error correcting modems), and ways the computer/its OS is designed.
Now, my question is, are these control characters and escape sequences only meant to be sent from the application to the terminal? Or is there a way that a user enters them directly into the terminal, e.g. via the keyboard?
Yes, there is. And you presented already all parts necessary.
In
- Off-Line mode (
SETUP
-4
-SETUP
), as well as - Local mode
every key press is right away handed to the receive function and interpreted. THat way one can try out whatever function combination needed without much software tools. Well, at least that's the way we did it to check functions and parameters when debugging :))
Or is there a set of control characters or escape sequences that the terminal directly interprets when the user types them on the keyboard (maybe a reduced, different set)?
No. None at all. Wouldn't make much sense anyway. Either output displayed (characters and operations) is controlled by the host, or the host just interpretes the input, assuming everything the user does is legal anyway - or doesn't care what's displayed anyway.
Especially the later may seem strange, but it was quite handy back then to keep programs simple. Why care for stuff a sane user wouldn't do anyway.
Well, as usual with complex matter the answer is a mixture of Yes/If.
First of all, are these assumptions correct?
Yes, the assumptions stated are perfect good and correct. In general. In detail there can be diversions, most depending on line characteristics (like blocking and error correcting modems), and ways the computer/its OS is designed.
Now, my question is, are these control characters and escape sequences only meant to be sent from the application to the terminal? Or is there a way that a user enters them directly into the terminal, e.g. via the keyboard?
Yes, there is. And you presented already all parts necessary.
In
- Off-Line mode (
SETUP
-4
-SETUP
), as well as - Local mode
every key press is right away handed to the receive function and interpreted. THat way one can try out whatever function combination needed without much software tools. Well, at least that's the way we did it to check functions and parameters when debugging :))
Or is there a set of control characters or escape sequences that the terminal directly interprets when the user types them on the keyboard (maybe a reduced, different set)?
No. None at all. Wouldn't make much sense anyway. Either output displayed (characters and operations) is controlled by the host, or the host just interpretes the input, assuming everything the user does is legal anyway - or doesn't care what's displayed anyway.
Especially the later may seem strange, but it was quite handy back then to keep programs simple. Why care for stuff a sane user wouldn't do anyway.
answered 2 days ago
RaffzahnRaffzahn
48.1k5109194
48.1k5109194
Ok, that helped.So for controlling the terminal from your keyboard in off-line or local mode, are you confined to those control characters that your keyboard can generate with a single key press, like those here? Or can you somehow freely compose ANSI escape sequences on your keyboard and send to your terminal in off-line or local mode?
– weibeld
2 days ago
Serial lines could be really slow, so normally there is no timeout and you can type one character at a time.
– grahamj42
2 days ago
@weibeld No, there is (usually) no time out (as graham already pointed out). After all, a computer could as well have a hickup when sending out characters (like a priority task pushing the user task away) right in the middle of an escape sequence. Also, what would be a timeout be good for? How to recover from a half ESC sequence - which may not have been one at all? Any setting of a timeout for escape sequences would create more harm than good. No, only host programs may do so to detect the ESC key alone. So feel free to assemble whatever ESC sequence you want by hand.
– Raffzahn
2 days ago
1
@Raffzahn If I understand you correctly, when the user types ESC on the keyboard, this character is sent to the host computer in the same way as any other character?
– weibeld
2 days ago
1
@Random832 Ah ok, now I understand the comments with the timeout. In local mode you can just type any stream of characters on the keyboard, and they will be handled by the receiver of the terminal like the stream of characters that usually comes from the computer. In this way, you can simulate the effects of any output of your application. And no timeout in local mode: you can typeESC
on the keyboard and, for example, only one minute later[
, and this would still be interpreted as a valid escape sequence by the receiver of the terminal. If I understand it correctly.
– weibeld
10 hours ago
|
show 6 more comments
Ok, that helped.So for controlling the terminal from your keyboard in off-line or local mode, are you confined to those control characters that your keyboard can generate with a single key press, like those here? Or can you somehow freely compose ANSI escape sequences on your keyboard and send to your terminal in off-line or local mode?
– weibeld
2 days ago
Serial lines could be really slow, so normally there is no timeout and you can type one character at a time.
– grahamj42
2 days ago
@weibeld No, there is (usually) no time out (as graham already pointed out). After all, a computer could as well have a hickup when sending out characters (like a priority task pushing the user task away) right in the middle of an escape sequence. Also, what would be a timeout be good for? How to recover from a half ESC sequence - which may not have been one at all? Any setting of a timeout for escape sequences would create more harm than good. No, only host programs may do so to detect the ESC key alone. So feel free to assemble whatever ESC sequence you want by hand.
– Raffzahn
2 days ago
1
@Raffzahn If I understand you correctly, when the user types ESC on the keyboard, this character is sent to the host computer in the same way as any other character?
– weibeld
2 days ago
1
@Random832 Ah ok, now I understand the comments with the timeout. In local mode you can just type any stream of characters on the keyboard, and they will be handled by the receiver of the terminal like the stream of characters that usually comes from the computer. In this way, you can simulate the effects of any output of your application. And no timeout in local mode: you can typeESC
on the keyboard and, for example, only one minute later[
, and this would still be interpreted as a valid escape sequence by the receiver of the terminal. If I understand it correctly.
– weibeld
10 hours ago
Ok, that helped.So for controlling the terminal from your keyboard in off-line or local mode, are you confined to those control characters that your keyboard can generate with a single key press, like those here? Or can you somehow freely compose ANSI escape sequences on your keyboard and send to your terminal in off-line or local mode?
– weibeld
2 days ago
Ok, that helped.So for controlling the terminal from your keyboard in off-line or local mode, are you confined to those control characters that your keyboard can generate with a single key press, like those here? Or can you somehow freely compose ANSI escape sequences on your keyboard and send to your terminal in off-line or local mode?
– weibeld
2 days ago
Serial lines could be really slow, so normally there is no timeout and you can type one character at a time.
– grahamj42
2 days ago
Serial lines could be really slow, so normally there is no timeout and you can type one character at a time.
– grahamj42
2 days ago
@weibeld No, there is (usually) no time out (as graham already pointed out). After all, a computer could as well have a hickup when sending out characters (like a priority task pushing the user task away) right in the middle of an escape sequence. Also, what would be a timeout be good for? How to recover from a half ESC sequence - which may not have been one at all? Any setting of a timeout for escape sequences would create more harm than good. No, only host programs may do so to detect the ESC key alone. So feel free to assemble whatever ESC sequence you want by hand.
– Raffzahn
2 days ago
@weibeld No, there is (usually) no time out (as graham already pointed out). After all, a computer could as well have a hickup when sending out characters (like a priority task pushing the user task away) right in the middle of an escape sequence. Also, what would be a timeout be good for? How to recover from a half ESC sequence - which may not have been one at all? Any setting of a timeout for escape sequences would create more harm than good. No, only host programs may do so to detect the ESC key alone. So feel free to assemble whatever ESC sequence you want by hand.
– Raffzahn
2 days ago
1
1
@Raffzahn If I understand you correctly, when the user types ESC on the keyboard, this character is sent to the host computer in the same way as any other character?
– weibeld
2 days ago
@Raffzahn If I understand you correctly, when the user types ESC on the keyboard, this character is sent to the host computer in the same way as any other character?
– weibeld
2 days ago
1
1
@Random832 Ah ok, now I understand the comments with the timeout. In local mode you can just type any stream of characters on the keyboard, and they will be handled by the receiver of the terminal like the stream of characters that usually comes from the computer. In this way, you can simulate the effects of any output of your application. And no timeout in local mode: you can type
ESC
on the keyboard and, for example, only one minute later [
, and this would still be interpreted as a valid escape sequence by the receiver of the terminal. If I understand it correctly.– weibeld
10 hours ago
@Random832 Ah ok, now I understand the comments with the timeout. In local mode you can just type any stream of characters on the keyboard, and they will be handled by the receiver of the terminal like the stream of characters that usually comes from the computer. In this way, you can simulate the effects of any output of your application. And no timeout in local mode: you can type
ESC
on the keyboard and, for example, only one minute later [
, and this would still be interpreted as a valid escape sequence by the receiver of the terminal. If I understand it correctly.– weibeld
10 hours ago
|
show 6 more comments
weibeld is a new contributor. Be nice, and check out our Code of Conduct.
weibeld is a new contributor. Be nice, and check out our Code of Conduct.
weibeld is a new contributor. Be nice, and check out our Code of Conduct.
weibeld is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8843%2fcan-escape-sequences-be-entered-directly-from-keyboard-to-terminal-for-vt100-and%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Does anyone else remember when CSI was Control Sequence Introducer ( <esc>[ ), not Crime Scene Investigation? ... {sigh} I was a nerd too soon.
– RichF
2 days ago
1
Indeed. And all my VMS screen-updatey code used the 8-bit CSI (0x9B) rather than ESC [ when the terminal would support it. When you're optimizing for minimal character output on a slow async line, every octet counts.
– another-dave
2 days ago
It's worth noting in passing that a large number of intermediaries such as modems could be put into a loopback mode that would produce the same effect as local mode.
– Walter Mitty
2 days ago
There was also the paper-clip method of terminal testing: Bend a paper clip and put one end in pin 2 and the other in pin 3 to effectively create a local echo. Depending on the terminal & serial port configuration, additional paper clips may be required for hardware handshaking.
– manassehkatz
2 days ago
1
Clippy: "I see you're trying to improvise a loopback connector. Can I .... wait, wait, what are you doing? Put me down! Ow, that hurts!"
– another-dave
2 days ago