Find the answer to your Linux question:
Results 1 to 4 of 4
Hello reader, I hope this new thread will give way to questions regarding virtual/pseudo terminals. To start things up, here are points others may want to clarify: 1. Terminal vs ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Dec 2010
    Posts
    5

    Exclamation Pseudo Terminal


    Hello reader,

    I hope this new thread will give way to questions regarding virtual/pseudo terminals.

    To start things up, here are points others may want to clarify:

    1. Terminal vs Pseudo Terminal. and
    2. Interpretation of Control Sequences

    cheers!

  2. #2
    Linux Newbie tetsujin's Avatar
    Join Date
    Oct 2008
    Posts
    117
    Quote Originally Posted by ierosvin View Post
    Hello reader,

    I hope this new thread will give way to questions regarding virtual/pseudo terminals.

    To start things up, here are points others may want to clarify:

    1. Terminal vs Pseudo Terminal. and
    2. Interpretation of Control Sequences

    cheers!
    Are you asking about terminals versus pseudo-terminals? I'm assuming that you are...

    1: pseudo TTYs vs. TTYs... I guess you could say pseudo TTYs are just a particular type of TTY device.

    I mean, if you log in to your machine via SSH or run an Xterm, that's a pseudo-TTY. Pseudo-TTYs are mostly what people use for shell sessions these days, I'd say. The fact that it's using a PTY is just an implementation detail.

    First it's important to understand what a TTY device is. It's kind of like a pipe, except the file descriptors on each end support two-way communication with the other end. But beyond that, the device itself implements a bunch of stuff that's meant to support the usual usage of TTY devices, which is for implementing an interactive login session on a hardware or software terminal.

    For instance, when a program is run on a particular TTY, that TTY becomes the process's "controlling terminal". The TTY device itself will send signals to the process under certain circumstances: if the connection ends (hangup), if the user types one of the special control characters to terminate a job or stop (suspend) it, if the size of the text window changes, and so on.

    The TTY device also manages session options like the input mode (like the line-buffered, input-echoing mode normally used by the shell, or the unbuffered "raw" modes normally used by full-screen apps, ncurses programs, etc.), settings for the different special keystrokes that issue the interrupt or stop signals, and so on.

    So TTY devices have kind of a special role. But they're also the type of device used for controlling serial ports and so on: basically, a serial port could be connected to a piece of terminal hardware somewhere, and used to run a login session... So therefore, it's a TTY. This is why serial ports on Linux are called /dev/ttyS0 or /dev/ttyUSB0, etc. The device drivers have the capabilities of a TTY device so they can be used for logins... so even if you're not using the device as a TTY, it's a TTY device nonetheless.

    Control characters like CTRL-C and CTRL-Z are normally handled by the TTY device itself. Once received, the result is that the TTY device issues a particular signal to processes running on that TTY.

  3. #3
    Just Joined!
    Join Date
    Dec 2010
    Posts
    5
    Great knowledge regarding TTYs tetsujin!

    for Control Sequences, im talking about Escape Sequences such as ^[A, ^[0;30m, etc., not the signals. Sorry for the confusion.

    Where could we possibly get a complete list of these sequences?
    Is it the terminal that sends these sequences all the time?
    Or can an application also send control sequence to the terminal?


  4. $spacer_open
    $spacer_close
  5. #4
    Linux Newbie tetsujin's Avatar
    Join Date
    Oct 2008
    Posts
    117
    Quote Originally Posted by ierosvin View Post
    Great knowledge regarding TTYs tetsujin!

    for Control Sequences, im talking about Escape Sequences such as ^[A, ^[0;30m, etc., not the signals. Sorry for the confusion.

    Where could we possibly get a complete list of these sequences?
    Is it the terminal that sends these sequences all the time?
    Or can an application also send control sequence to the terminal?
    Ah, OK.

    Some of these escape sequences are sent by the terminal: mainly as a result of various keystrokes that aren't part of the regular character set, like function keys or arrow keys.

    Others are sent by application code. For instance if you were to run "screen" or "alpine" or "nano" - these programs all take control of the terminal and issue various escape sequences in order to do things like move the cursor around, change colors and character attributes, and so on.

    There are lots of different types of terminals out there: though I think these days people mostly just use terminal emulators like xterm. But in the old days there were pieces of hardware that did nothing but act as a terminal on a serial line. Different models of terminal could have entirely different sets of escape sequences. So when an application wants to send escape codes to the terminal it should really know what type of terminal it is, and what escape codes it supports. There are two commonly-used mechanisms for this.

    The first is the "termcap" system - it's less common these days - but there would be a file called /etc/termcap which would contain a bunch of terminal definitions.

    The more common mechanism these days is "terminfo" - you can get a list of the codes supported by your current terminal by running "infocmp"

    Both mechanisms identify the type of the current terminal using the environment variable $TERM - it is assumed that this has been set correctly by someone somewhere along the line. Normally the login process should handle this: if you're logging in on a local terminal (virtual console or serial terminal) the login system should already know the proper value to set to $TERM. If you're logging in via telnet or ssh, your end should already know the correct value of $TERM and pass it to the site you're logging in to. And an xterm obviously knows it's an xterm, so it sets $TERM accordingly.

    Both mechanisms also support a certain set of identifiers used to identify the function of each escape sequence. For instance, terminfo identifies the code generated when the arrow keys are pressed with kcuul, kcudl, kcufl, and kcubl (key cursor {up, down, forward, back} line, etc. I guess) - while termcap uses ku, kd, kr, kl for the keys... If your system is terminfo-based you can use "infocmp" to see the terminal definition in terminfo form and "infocmp -C" to see it in termcap form. See also man 5 terminfo, as that has a listing of the different codes supported by terminfo and their equivalents in termcap.

    Most of the time when people try to write anything moderately complex using the terminal, they don't write and read the escape codes directly: instead, they usually go through a library like ncurses. That way, they can focus more on doing what they're trying to do and not have to worry so much about whether their terminal supports a particular capability they're trying to use.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •