-1

I'd like to know the difference(s) between the text mode that one gets, for example, by opening "terminal" in GNOME, and the text mode that one interacts with in a server linux distribution which doesn't have a GUI.

I know that the program named "terminal" is an emulator. I'd like to know about the mechanisms behind the scenes. How is, for example, a call to scanf() managed in these two cases? If "terminal" realizes GUI-based text mode, what is the source of the other kind of text mode? (I mean the code showing the blinking cursor and moving it, etc.) the BIOS? the kernel? a process in user space?

apadana
  • 123
  • They're all emulated. People haven't been using "real" terminals like the VT100 for ages now. – muru Oct 31 '23 at 06:17
  • @muru, I understand what you mean, but I think text-based user interface is a reality. In this context, the program "terminal" is an emulator because it emulates the text-based UI in desktop environment, not because it emulates those old terminals connected to mainframes via network. – apadana Oct 31 '23 at 06:32
  • @apadana they’re called “terminal emulators” because they emulate terminals; they’re not called “text-mode emulators”. Kitty, xterm etc. also emulate some graphical terminals. – Stephen Kitt Oct 31 '23 at 06:38
  • @StephenKitt, I understand that that is what meant by "terminal emulator". But in my post I used "emulator" in another sense. You probably have heard that in Windows "CMD is a DOS emulator". Similarly, I'm saying that "terminal" is emulating text-based UI. – apadana Oct 31 '23 at 06:46
  • @apadana it's not as much of a reality as you think. You can show images, play videos, etc. on the TTY on Linux. – muru Oct 31 '23 at 06:46
  • @apadana, if a "terminal" (or do you mean a particular application called Terminal?) "emulates" a text-based UI, then what's the underlying original / real text-based UI? The one that's being emulated? That is, if you don't accept real terminals, like the VT100 as the original? (Remember that "emulate" means "to copy, to imitate") – ilkkachu Oct 31 '23 at 08:24
  • @ilkkachu, how can we define a "real terminal"? The term is vague to me. A laptop can be used to send commands to a remote server. Does this make it a "real terminal"? And VT100 is similar to a PC in many ways. – apadana Oct 31 '23 at 10:11
  • @apadana, no, it doesn't, and no, it isn't. A terminal is a screen and a keyboard connected to a serial connection so that characters entered on the keyboard get sent over the wire, and characters from the wire appear on the screen. (Plus some special processing of escape codes, but pretty much only for the purpose of controlling how those characters are drawn on the screen.) A terminal doesn't in itself run any actual end-user application, it's only an interface to a machine that does. – ilkkachu Oct 31 '23 at 10:16
  • Your laptop isn't that, your laptop is a full-fledged computer, with storage and a general-purpose operating system, and applications. Of course you can run an application that connects to a serial line, or one that displays an interface that looks like a terminal interface, i.e. emulates a terminal interface, i.e. is a terminal emulator. But it's not a real terminal. – ilkkachu Oct 31 '23 at 10:17
  • @ilkkachu, You are referring to the original terminals. Nowadays, "thin clients" are sometimes called terminals. – apadana Oct 31 '23 at 10:21
  • Another thing is that you're asking about scanf(). That's a standard function in the C library, implemented within the application program, in user space. Are you asking about how user space programs interface with a real terminal vs. a GUI terminal emulator vs. something else, e.g. a pseudo-terminal set up by the SSH server? Because for most part, there is no difference for the userspace program between those cases, that pretty much being the point of a standard-ish terminal interface. – ilkkachu Oct 31 '23 at 10:22
  • @apadana, no, you are referring to '"terminal"', with quotes. You made the claim that '"terminal" is an emulator.'. That's not how the word is commonly understood, a real, "original" if you will, terminal is a terminal. A terminal emulator is not. Knowing what you're actually trying to refer to is a prerequisite for you getting the answers to the questions you want to ask. I tried to ask if you meant a particular piece of software called "Terminal" (as opposed to any generic "terminal"), but you didn't appear to answer that. – ilkkachu Oct 31 '23 at 10:25
  • If you want to discuss thin clients, you'll have to specify exactly which sort of thin clients you mean. If you want to discuss terminals that are significantly different from terminals like the VT100, you'll have to specify exactly which sort of terminal you mean. – ilkkachu Oct 31 '23 at 10:26
  • @ilkkachu, in the question I mentioned "terminal" in GNOME. I meant the program named Terminal. – apadana Oct 31 '23 at 10:29

2 Answers2

5

In all the cases, the shell sees a TTY or PTY device and a TERM environment variable which will identify the correct set of terminal control codes to use.

When using GNOME's terminal window, the device is a UNIX 98-style PTY: /dev/pts/*. When the terminal window is active and receiving X11/Wayland keyboard events, the GNOME Terminal process translates them into UTF-8 characters and feeds them into the "master" side of the PTY device, so the CLI process gets them from the other (classically known as "slave") side of the PTY device.

Output is handled the same way: the CLI process writes UTF-8 characters and terminal control codes (the correct code set identified by the TERM environment variable) to the PTY device, and the GNOME Terminal process reads them from its side of the PTY device, uses them as input for a simulated terminal, and renders the simulated view as X11/Wayland graphics.

When on a Linux virtual console device (/dev/tty[1..n]), the process is much the same, except the terminal emulation runs within the kernel, and so there is no equivalent of a "master" PTY device visible to the user-space.

If you are operating on a serial console, the CLI process gets a "real" TTY device: a serial port (/dev/ttyS[0..n]). Whatever is at the other end of the serial cable will be responsible of the rest: in these days, it might be another terminal emulator, like a laptop running Linux minicom or a reasonably new version of PuTTY that includes serial port support. Or it might be a real terminal: maybe an actual Digital VT-series terminal, or a HP 700/96.

Or if you are seriously into retrocomputing, it might be an electromechanical monstrosity from the 1930's.

telcoM
  • 96,466
3

telcoM’s answer explains how programs talk to the terminal (real or otherwise).

There’s another part to your question, which is where the terminal handling lives when it’s not provided by a graphical terminal emulator. There are three possibilities nowadays.

  1. Hardware text mode, in-kernel terminal emulation. This relies on the hardware to provide text-mode support, with a thin console layer on top (e.g. vgacon or even mdacon). The kernel writes actual characters (with attributes) to the video buffer, and the hardware character generator is used to translate them into pixels displayed onscreen. The cursor is also handled in hardware (including blinking; see What character is the MS-DOS cursor? for details). In this setup, no “graphical” output is possible (creative use of fonts notwithstanding). Terminal emulation itself, e.g. translation of VT escape codes into character movement, is handled by the kernel.

  2. Framebuffer, in-kernel terminal emulation. This uses a common framebuffer abstraction (fbcon) to provide a text-mode console using a graphical framebuffer. In this variant, the kernel translates characters into pixels, handles the cursor, and the display isn’t limited to text — graphical programs can run too (whether framebuffer-specific, like fbida, or using a framebuffer backend with a library such as SDL or Gtk). Terminal emulation is handled as in the first variant.

  3. Framebuffer, userspace terminal emulation. This uses the same graphics support as the previous variant, but adds a userspace terminal emulator such as kmscon. In this scenario, the translation from text output to pixels on the screen is done inside a program, not the kernel.

Stephen Kitt
  • 434,908
  • Thanks. I enjoyed reading this. Don't the 2nd and 3rd possibilities involve using a display server like Xorg (you are talking of single pixels being manipulated within software)? Do you know actual implementations of these two possibilities? Which possibility is used by a server linux distribution like ubuntu server? – apadana Oct 31 '23 at 10:03
  • 1
    There’s no display server involved anywhere here, the kernel handles the framebuffer. Current distributions generally use option 2, including server variants. I gave a link to an implementation of option 3, kmscon. – Stephen Kitt Oct 31 '23 at 10:12