8

In the 1970’s we had hardware terminal with CUI (character user interface) interface for input/output.

Now, we have terminal emulators (Ctrl+Alt+Fn) in Unix/Linux world.

In Ubuntu OS, I see seven terminal emulators, where GUI is occupying 7th terminal emulator (Ctrl+Alt+F7).

For example, this is my first terminal (Ctrl+Alt+F1) emulator

$ tty
/dev/tty0

Why does Unix/Linux provide multiple terminal emulators?

  • 7
    There was always a demand for it. A program named "screen" was used when there was only one terminal available. – VPfB Apr 8 '17 at 19:23
  • 7
    @vpfb Screen is still available and an integral part of my work flow! – tpg2114 Apr 9 '17 at 2:43
  • I think what you are asking about here is not terminal emulators (which are programs like xterm, rxvt, &c that run as graphical applications under X), but text-mode terminals that aren't running graphics. The only use I've really found for those (and that not for a good few years) is to debug things when X doesn't work right. OTOH I do most of my real work in xterm windows, and might have anywhere from three to a dozen or more open. – jamesqf Apr 9 '17 at 5:20
  • @jamesqf why don't u call ctrl+alt+f1 as terminal emulator? Because it is not the hardware CUI terminal we had in 1970's – overexchange Apr 9 '17 at 13:00
  • 1
    @overexchange: I don't call them that because that isn't the terminology used by people familiar with them. If you do a search for "linux terminal emulator", you'll get back lots of results, most of which have nothing to do with the text-mode consoles you get with Ctl-Alt-F[1-7]. – jamesqf Apr 9 '17 at 18:07
24

Why does UNIX/Linux provide multiple terminal emulators [on the console]?

For the same reason your GUI terminal emulator likely supports tabs (e.g. GNOME Terminal), and if not (e.g. rxvt), then for the same reason launching a second GUI terminal app instance doesn't just pull the first one to the foreground and exit, forcing you to use the first instance.

I routinely use at least 3 terminal windows in my work, and often more:

  1. Text editor for the server side of the system I'm working on

  2. Text editor for the client side of the same system

  3. Command window for running the server

I rarely need a fourth terminal for running the client program, since it usually runs elsewhere (web app, native GUI app, mobile app, etc.), but if I were developing a CLI client for my server app, I'd have a separate terminal open for it, too.

In the past, before sudo became popular, I kept a root terminal open all the time.

I rarely use Unix/Linux boxes interactively at the console without a GUI these days, but I do often run them headless and access them over SSH. My SSH terminal client of choice supports tabs, configured as above.

One of my current hobby projects has me using a real old glass terminal occasionally, which means I no longer have multiple terminal windows, so I'm finally learning a bit about GNU screen, a program I never had much use for before, since I had either multiple console terminals or multiple GUI terminals. And what does screen do? Among other things, you can configure it to give you multiple virtual terminals on a single screen, just like Linux does with Ctrl-Alt-Fx.

  • 9
    The better bit about screen - other than having multiple terminals on a dumb console terminal - is that you can disconnect, log out, log back in, and reconnect to sessions, and the process(es) or whatever you were doing in the screen terms keep going. – ivanivan Apr 8 '17 at 19:01
  • Adding on to what @ivanivan said, other people can see your screen session and multiple people can view it at the same time. It's like console desktop sharing. – stanri Apr 9 '17 at 5:42
  • Side note: there are some alternatives available to using pure screen superuser.com/q/423310 – moooeeeep Apr 10 '17 at 8:09
17

This is a feature provided by almost all if not all Unix and Unix like running on x86 hardware. Interestingly, virtual consoles were introduced first in a Unix by Microsoft Xenix in the early eighties, and was also available in concurrent CP/M.

This feature was later integrated in AT&T SVR4 Unix, Solaris, and borrowed by BSDs and Linux.

Why does UNIX/Linux provide multiple terminal emulators?

When they were first introduced, there was no graphic environment available for the machines running these Unix implementations. While having a physical terminal connected to a central Unix server through RS232 lines was the standard, connecting multiple terminals to a standard PC running Xenix was overkill if the goal was just for a single user to run multiple interactive programs simultaneously. Virtual terminals provided an elegant and convenient solution to that issue.

Other Unix implementations later provided that same feature to meet the same need.

When graphic environments, especially X11, spread out, being able to see multiple terminal emulators at the same time on the same screen was a significant improvement. The virtual console feature was however generally kept if only because it was still convenient to be able to switch to a console should the graphic environment is frozen or dysfunctional for some reason.

Note that utilities like screen and tmux came much later than virtual terminals to generalize the same functionality. Their advantage is they can be used non only on the local physical console, but also on whatever session, either local or remote (e.g. telnet, ssh). When used on the physical console, virtual consoles are still useful as they are functional in some situations where screen/tmux can't help, like if X11 is frozen, or if a window has captured the focus and doesn't release it.

Container based virtualization like Solaris zones or Linux LXC also provide a method to connect to the container console through zlogin -C zone and lxc-console -t 0 -n container respectively.

4

I suppose one good reason for having extra terminal emulators is that if you do something wrong in your graphical interface and it becomes unusable, you can quickly switch to a terminal emulator and correct all the problems you are having in the graphical interface. This actually happens to quite often when you are making changes to your window manager or other features of the graphical interface. I suppose it would also be useful to have a couple more terminals, however having 6 overtop of the main graphical interface seems a bit excessive.

Also correct me if I am wrong, but isn't it possible to run multiple commands as different users from one single terminal emulator?

  • "if you do something wrong" - that explains why there is a virtual console, not why there are multiple (i.e. answering a different question). "isn't it possible to run multiple commands as different users from one single terminal emulator?" - yes, but their outputs would be mixed up, and running curses programs would be difficult. – Radovan Garabík Apr 10 '17 at 9:10
4

Many of the other questions seem to answer why the feature was introduced.

Still, the actual question is:

Why does Unix/Linux provide multiple terminal emulators?

"does", not "did".

So, focusing on the current time, here are some current reasons:

  • They can be handy. Sometimes, instead of making a new window that covers other windows on the desktop, I can just flip to another terminal. Then, I can change back, so the desktop is the foreground. On occasion (typically when there multiple windows are open) this may be more convenient than placing a terminal window in the background and then, later, trying to make that same window come to the foreground (instead of accidentally selecting a different one of the terminal windows that are on the graphical desktop).

    For instance, I can remember that Alt-Ctrl-F2 is the text editor that looks at one text file (e.g., documentation), and Alt-Ctrl-F3 is used to quickly look at another file (e.g., a configuration file), and Alt-Ctrl-F4 is used for a command prompt, while the graphical desktop can be split between web browsing, E-Mail, music player, etc.
  • Terminal windows can be useful for working with the computer if there is any sort of problem with the graphical display. For people who may have a current need to use a (perhaps customized) computer that doesn't have a graphical video card, this functionality may be essential. There's also the possibility of future needs (possibly with a successor/descendant operating system) that may be in addition to whatever current needs may exist.
    • These text terminals tend to use fewer resources. For instance, they tend to use less memory on a graphics card. So, if a graphics card had a physical malfunction that broke functionality of the 3rd and 4th megabyte of video memory, that might not even affect somebody who is only using the classic text terminals. Simpler processes, which use less resources, can be helpful when working on performing recovery.
  • The code already exists. Therefore, supporting them is easy.
  • The amount of resources for an unused terminal (before logging in) is very small. Even that small amount of memory can be re-claimed by adjusting /etc/ttys
  • The code to support multiple terminals is rather similar to the code to support I/O over serial connections. Developers of operating systems tended to value that a lot. With advancements in virtual machines, the value of using serial connections is less critical than it used to be. Still, some kernel developers (already familiar with the process) may like to use such hardware. Organizations using old hardware may also see benefit in not needing to change the hardware.

In summary, there just isn't much reason not to support this. There is some benefit that some people appreciate, at least some times, and not much cost.

Actually, removing support for this may be more work than just leaving the support there. Although removing support would probably be simple, if anything broke, then identifying and fixing the problem may be a bit challenging. So, reduction in the amount of effort required (to develop the next version of an operating system) is yet another reason to just leave things as is. That means this feature is prone to remain being available.

  • Having an historical perspective is often useful. You tell you want to focus on the present but finally conclude "One of the reasons why Unix/Linux currently provides multiple terminal emulators is because it did provide them in the first place…" – jlliagre Apr 12 '17 at 22:58
  • Yes. It did. If it didn't, it might not today. But since Unix did, that remains a compelling reason why it does. In no way did I mean to minimize usefulness of being familiar with the past. My natural tendency would be to focus on why it was added (and my first draft or two had that in more detail), but my primary reason for trying to focus on the present is that's what the question asked. Plus, other answers mentioned the past, and I tried to make a useful answer by adding to what's been stated, instead of just duplicating what's already said elsewhere on the page. – TOOGAM Apr 13 '17 at 4:37
2

First of what you have asked about is a feature of a kernel named Linux. Not of Unix in general, and not Gnu.

As to why, you would have to ask the authors. However my guess is that, it allows an admin of a non-networked device (here I include a RS232 as a type of network), to login and do some admin work, without logging another user out.

  • Yes the kernels VTs are set up by user-land code, and yes there are some other Unixes that have them. However it is not a general Unix thing. – ctrl-alt-delor Apr 8 '17 at 19:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.