Can escape sequences be entered directly from keyboard to terminal for VT100 and similar?












5















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



enter image description here



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:



enter image description 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?










share|improve this question









New contributor




weibeld is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 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


















5















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



enter image description here



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:



enter image description 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?










share|improve this question









New contributor




weibeld is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 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
















5












5








5








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



enter image description here



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:



enter image description 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?










share|improve this question









New contributor




weibeld is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












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



enter image description here



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:



enter image description 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






share|improve this question









New contributor




weibeld is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




weibeld is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 2 days ago







weibeld













New contributor




weibeld is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 2 days ago









weibeldweibeld

22117




22117




New contributor




weibeld is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





weibeld is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






weibeld is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 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





    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












1 Answer
1






active

oldest

votes


















6














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.






share|improve this answer
























  • 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 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













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.










draft saved

draft discarded


















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









6














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.






share|improve this answer
























  • 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 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


















6














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.






share|improve this answer
























  • 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 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
















6












6








6







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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










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





















  • 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 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



















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












weibeld is a new contributor. Be nice, and check out our Code of Conduct.










draft saved

draft discarded


















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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

"Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

Alcedinidae

Origin of the phrase “under your belt”?