Terminal emulator

Example image of a Bash session, taken in Gentoo Linux.

A terminal emulator or console emulator is a computer program that simulates the operation of a computer terminal on any display device. It is usually accessible by pressing CTRL + ALT + T simultaneously. A terminal emulator within a graphical user interface is commonly known as a terminal window.

Terminal emulators incorporate features such as process control, input/output redirection, file listing and reading, protection, communications, and a command language for writing batch instruction sequences or scripts. One of the best known languages or interpreters is the Bourne Shell, which was the interpreter used in the first versions of Unix and became a de facto standard.

When entering the commands in the emulator, a command interpreter analyzes the sequence of characters entered and, if the syntax of the command is correct, executes it, resorting to the functions offered by the operating system or the program that represents, either a database manager, an FTP session, etc. The response to the user is rendered on the monitor; It is an interactive way of working, that is, user and machine communicate successively.

Brief historical review

Since its inception, computers had small text terminals to interact with their users. A terminal consists solely of a keyboard and a screen capable of displaying text. These terminals were connected to the computer through a serial interface (more or less, a simple cable). A computer could have several terminals connected simultaneously.

With the proliferation of minicomputers, the same person was forced to operate several terminals on his desk, one for each computer. Since these computers already had communication networks, the suitability of being able to control several computers from the same terminal became clear. To make this possible, an emulator program was written that basically allows one computer to pretend to be a terminal on another computer. This is how the first terminal emulators for Unix were born.

The usefulness of the terminal emulator became even greater with the advent of personal computers in businesses. The workers now had a desktop computer and a terminal on their desk. This was not only a nuisance for the worker. It also meant an extra cost for the company since it had to maintain two different pieces of equipment, the communications network and the serial connections of the terminals. The use of a terminal emulator made it possible to eliminate the old physical terminal as well as all the serial cables, giving added value to the communications network. In addition, the cost of a terminal emulator license is significantly lower than the cost of a physical terminal.

Today, terminal emulators for personal computers are still in use in those organizations that maintain central systems (Banks and Public Administrations, essentially), as well as in most modern operating systems, of which which include GNU/Linux, since advanced users of the latter tend to use terminal emulators for most system administration tasks.

The terminal emulators have evolved into modern remote desktops.

Typology

All terminal emulators are very simple, just sending and receiving text characters over a communications network. The characters sent correspond to keystrokes and the characters received correspond to the displayed screen. The only difference between them is the type of emulated physical terminal. Although there is a wide variety of terminals (both physical and emulated), almost all of them are variations of two basic models:

• The VT-100 range. These are terminals manufactured by DEC and used mainly on their VAX and later computers. Especially popular is the VT-320 model.
• The range 3270. They are terminals manufactured by IBM for all your central computers. They are more sophisticated than the VT-100 terminals as they have cursor and fields that the user can fill before being sent to the central computer. That is, not every keystroke is sent but the set of everything typed on the screen once the "Enter" button is pressed.

The difference between terminals is in the character set used, the control codes they use (for example, to clear the screen) and the different character codes that correspond to each key.

Some terminal emulators

The terminal emulator par excellence is Telnet. It is a standard application of the TCP/IP protocol stack. However, Telnet is a "lowest common denominator" emulator, that is, excessively simple.

On Unix computers the default terminal emulator is Term, which has its graphical desktop version in xterm. This one has some improvements such as the possibility of visualizing text in color by means of certain control codes.

In the field of personal computers, putty and ssh stand out. However, these leave out the 3270 terminals. The most widespread commercial products are Extra! and Reflection from AttachmateWRQ company.

With the proliferation of Web technologies, some companies like Jacada and AttachmateWRQ are trying to market a new generation of emulators that run in the Web browser, either directly (via an applet), or via an intermediate server (a Web application). In addition, AttachmateWRQ offers solutions for web application integration through its VERASTREAM solution. This solution, on the other hand, allows to modernize the legacy application (resident in the host) and give it a web aspect.

Shell Categories

They can be divided into four categories: Bourne-like, C-console-like, non-traditional, and historical.

Compatible with Bourne shell

• Bourne shell (sh) -- Written by Steve Bourne, when he was at Bell Labs. It was first distributed with UNIX Version 7, in 1978, and improved over the years.
• Almquist shell (ash) -- It was written as a replacement of the Bourne shell with BSD license; the FreeBSD sh, NetBSD (and its derivatives) are based on ash and have been improved according to POSIX for the occasion.
• Bourne-Again shell (bash) -- It was written as part of the GNU project to provide it with a superset of functionality with the Bourne shell, usually the default shell in most of the GNU/Linux distributions.
• Debian Almquist Shell (dash) -- Dash is a modern ash replacement in Debian.
• Korn shell (ksh) -- Written by David G. Korn, while he was at Bell Labs.
• Z shell (zsh) -- Considered as the most complete: it is the closest thing that exists to encompass a superset of sh, ash, bash, csh, ksh, and tcsh.

Compatible with the C shell

• C shell (csh) written by Bill Joy, while at the University of California, Berkeley. It was first distributed with BSD in 1979.
• TENEX C shell (tcsh).

Other or exotic

• Fish, a friendly and interctiva shell, first launched in 2005.
• Mush, a smart shell like video games that operates like an MUD.
• zoidberg, a modular shell written in Perl, completely configured and operated in Perl.
• rc, the default shell of Plan 9 from Bell Labs and Unix Version 10 written by Tom Duff. Inferno and Unix-based operating systems have been compiled.
• is shell (es), a rc compatible shell written in the mid 90s.
• scsh (Scheme Shell).

Configuration files for shells

A shell reads configuration files in multiple circumstances under different shell dependencies. This table shows the configuration files of the most popular shells:

Explanation:

• "no" means the shell won't read the file at all.
• "yes" means that the file is always read by the shell.
• "login" means that the file is read if the shell is a session shell (loging shell).
• "n/login" means that the file is read if the shell is not a session shell.
• "int." means a file is read if it is an interactive shell.
• "i.login" means that a file is read if the shell is interactive session.

Historical

• Thompson shell (sh) -- The first shell Unix was written by Ken Thompson in Bell Labs. Distributed with version 1 to 6 of Unix, from 1971 to 1975. It is considered very rudimentary for modern standards and is not used in current systems. There are some available parts of it: Ancient UNIX Systems.
• PWB shell or Mashey shell (sh) -- A version of Thompson's shell, created by John Mashey and others, while at Bell Labs. Distributed with the Programmer's Workbench UNIX in 1976.

Non-Unix Shells

Within the Microsoft Windows suite of operating systems, the analogue is the programs command.com, or cmd.exe for Windows NT-based operating systems, and Windows PowerShell introduced with Windows Server 2008.

Nomenclature: Consoles v/s CLI v/s TUI v/s TTY v/s Terminal v/s Emulation v/s Shell

Few terms used in computing have suffered as many ups and downs throughout technical progress as intensely as command interpreter.

Historically, the console was a data terminal (that is, a physical device), but since such devices are almost non-existent, the word came to be used as a synonym for "CLI screen". The expression console is most commonly used in PC games to refer to the window where commands can be entered.

On the other hand, a terminal emulator (or TTY) is a program that allows you to imitate those old terminals, to access various services still in force under that type of format (such as Telnet). Examples of these programs are: HyperTerminal, Xterm, putty and SSH.

With the development of GUIs, window systems provide some kind of emulation for text mode, to correctly run programs that use TUI (such as Linux's Midnight Commander). In this way, both Unixes shells (under X) and old DOS programs (under MS Windows) are executed with this text mode emulator. What's more, some important programs (like Bash) also act as terminal emulators. Thus, the expressions text emulator, console and terminal sometimes end up being used as synonyms.

It is common to mix the three things together to refer to a single concept: the place where the command line interface can be used.

For example, if we connect a keyboard and monitor to a PC and make it boot into GNU/Linux in text mode, most users will say that it has a shell. If from that shell the KDE graphical mode of the same PC is started, the screen will light up with backgrounds and buttons. If a window is opened with the xterm program, it will be called console. If in that console we execute SSH and communicate through the network with a remote computer, we will say that we have an open terminal. In all three cases we will work with a shell, say Bash, and the differences in functionality are minimal.