2

In a diagram from APUE,

  • Where is a physical terminal device or virtual console for the terminal emulator read and write with?

  • what process open, read and write with some physical terminal device or virtual console? Is it the terminal emulator?

enter image description here

Tim
  • 101,790

1 Answers1

4

See What are the responsibilities of each Pseudo-Terminal (PTY) component (software, master side, slave side)? for lots of useful context.

The point of a terminal emulator is to emulate the physical terminals of old. None of the connections in the APUE diagram correspond to anything physical. When it starts a shell, the terminal emulator opens the PTY master, allocates a PTY slave, sets the appropriate line discipline (if necessary), and execs the shell with the corresponding file descriptors as standard input etc. The terminal emulator’s job then consists of emulating the behaviour of a physical terminal, implementing the display (typically using X or Wayland), and the user input (ditto).

Stephen Kitt
  • 434,908
  • Thanks. Where should a physical terminal be added to the diagram? Does a physical terminal hide behind the window manager, and communicate with the terminal emulator via the window manager? – Tim Jun 02 '18 at 13:25
  • A physical terminal wouldn’t be added to this diagram. See chapter 18 and figure 18.2 in APUE for physical terminals. – Stephen Kitt Jun 02 '18 at 13:35
  • Thanks. In this scenario, what process opens, reads and writes with the device file of a physical terminal device or virtual console? Is it the terminal emulator? – Tim Jun 02 '18 at 13:37
  • When you have a physical terminal, there is no terminal emulator because there’s nothing to emulate — you have the physical device. The same applies to virtual consoles. The terminal is typically managed by the init process with the help of getty. – Stephen Kitt Jun 02 '18 at 13:43
  • Does the terminal emulator have file descriptors to the physical terminal or virtual console? If yes, by inheriting them from getty? – Tim Jun 02 '18 at 13:51
  • I think you’re missing an important aspect of this: you use either a physical terminal (or virtual console), or a terminal emulator. I’ll say it again (see my previous comment): if you’re using a physical terminal or virtual console, there is no terminal emulator. So there is no terminal emulator to give file descriptors to. – Stephen Kitt Jun 02 '18 at 13:54
  • Sorry for misunderstanding. I was asking a slightly different question in my last comment from your earlier comment. I think if the terminal emulator process doesn't have file descriptors to the physical terminal or virtual console, how it can read and write to my physical terminal? – Tim Jun 02 '18 at 14:09
  • Oh, I take it you’re asking how the terminal emulator has access to display its window on your physical screen, and receive input from your physical keyboard? It does so by being an X client, or Wayland client, or whatever display server you’re using. It doesn’t know about the keyboard or screen as such, it receives input events an issues display requests. – Stephen Kitt Jun 02 '18 at 14:48
  • Do you mean a terminal emulator is a client of a windowing system server, and the windowing system server has opened the file descriptors for the physical terminal and virtual console? – Tim Jun 02 '18 at 15:08
  • That’s pretty much it, yes. Note that the display server usually doesn’t use the terminal capabilities of the device it’s driving; it drives the display and keyboard etc. directly. – Stephen Kitt Jun 02 '18 at 15:14
  • what does " use the terminal capabilities of the device" mean? – Tim Jun 02 '18 at 15:22
  • The display server could read the keyboard by reading from /dev/ttyX (for some value of X), but it doesn’t. And it doesn’t write to the terminal to produce the display output, nor does it receive mice events from it. – Stephen Kitt Jun 02 '18 at 15:37