7

In Linux, each terminal is associated with a new shell process. For example, here I have two xterm terminals, and each xterm terminal has an associated shell process:

ps listing with 2 xterm and bash processes

I am wondering if in the old days when terminals were real devices and not software emulation, did ancient Unix (for example UNIX V7) create a new shell process for each (real) terminal, or did all terminals share the same shell process?

chicks
  • 397
  • 1
  • 4
  • 15
user7681202
  • 1,837
  • 12
  • 17
  • If you're going for really ancient, looking at https://www.bell-labs.com/usr/dmr/www/hist.html , there were up to two shell processes: Processes (independently executing entities) existed very early in PDP-7 Unix. There were in fact precisely two of them, one for each of the two terminals attached to the machine. – ninjalj Dec 22 '17 at 11:56
  • Even older, https://retrocomputing.stackexchange.com/questions/8361/process-model-in-early-unix claims one process per terminal really was the model on early Research Unix. – tripleee Jan 16 '23 at 19:39

2 Answers2

13

Each terminal gets its own set of processes: first getty, which sets the terminal link up and waits for a login, then replaces itself with login to handle the actual login, and finally login runs the user’s shell. So yes, each terminal gets its own shell (once a user has logged in).

This doesn’t happen automatically, it’s set up by init which uses the information in /etc/ttys to determine where to start gettys.

Stephen Kitt
  • 121,835
  • 17
  • 505
  • 462
  • Now that I think about it, it makes sense for each terminal to get its own shell process, because if there was only one shell process, then what if one terminal executed a command that takes a long time to finish executing, now the shell will not be able to process new incoming commands requests from the other terminals (because the shell must wait for the currently running command to finish executing before it can do that). – user7681202 Apr 25 '17 at 20:14
  • @user7681202 Not exactly. A properly written multi-terminal shell would start processes in the background; the primary issue is with waiting for input on multiple file descriptors at the same time: in UNIX V7 it would have to be done using by polling, wasting CPU cycles. The system calls to do it properly - "poll" or "select" - only appeared in Unix System V and BSD respectively. – Leo B. Apr 25 '17 at 22:50
  • 2
    A shell process needs to be associated with a user and also (most importantly) with the access rights of the user. It wouldn't make sense also from a security viewpoint to share shell processes between users. – tofro Apr 26 '17 at 10:34
  • 1
    Since when did every user on a multi-user system want to use the same shell - or even the same window manager? These processes need to be specific to both with the terminal and the user. – alephzero May 01 '17 at 22:00
  • 1
    @Leo B. Even this is not exactly how Unix kernels, as for System 7, works. select() and poll() are part of the later BSD networking API, but the Unix process model generally do already have a block and wait for resource concept. These multi-tasking and multi-user systems won't do well with polling at all. If a process interacts with device its device driver uses system calls to wakeup and sleep systemcalls which are operating on wakeup channels. That's the way even in old Unix days a device communication is usually done. – Johann Klasek May 07 '17 at 11:34
  • 1
    @Johann My point is that before BSD of SysV is was impossible for a process to wait for input on multiple file descriptors at the same time without an explicit try-to-read/sleep loop because there was no poll() nor select() system calls. The device driver implementation details are irrelevant. – Leo B. May 11 '17 at 01:38
  • Sorry, you right, overlooked the point it is referring to. In old days one have to do it somehow with non-blocking I/O polling channels and wait on appropriate signals (if any exists) ... probably neither an elegant solution nor very portable. – Johann Klasek May 19 '17 at 08:45
  • @LeoB As far as I remember, V7 does also not have a "try to read" method. read(2) always blocks. there is no non-blocking I/O, nor FIONREAD. That is all a BSD addition. I know, because I wrote an imitation of the VMS "phone" command, and I had to fork() to read the 2 terminals of the participants. – Rhialto supports Monica Dec 17 '19 at 14:52
  • I think it's worth noting here that UNIX was one of the first systems to not treat the shell as a core part of the kernel/operating system. The notion that the shell could, and indeed should, be just another user program is maybe obvious only in hindsight. – RETRAC Sep 13 '20 at 15:15
4

It wouldn't make much sense. Terminals are generally used by different people, and each one needs a shell process with a different user ID. Writing a shell able to serve multiple sessions in case a user logs in on multiple terminals would not be of much benefit as such sessions would be unlikely to be active at the same time.

Stephen Kitt
  • 121,835
  • 17
  • 505
  • 462
Leo B.
  • 19,082
  • 5
  • 49
  • 141
  • Even with terminals which aren’t real devices, they can still be used by different people ;-). – Stephen Kitt Apr 25 '17 at 20:51
  • @Stephen So? What exactly in my statement are you objecting to? – Leo B. Apr 25 '17 at 22:40
  • 1
    Leo, a comment isn’t necessarily an objection (I didn’t downvote your answer). You wrote “When terminals were real devices, they would be used by different people”; I’m just adding that this is still sometimes the case even with non-physical terminals. – Stephen Kitt Apr 26 '17 at 07:37
  • That is true; but what is the consequence of that addition with regard to the discussion? Am I missing something? – Leo B. Apr 26 '17 at 08:24
  • Is that better? Feel free to roll back if you disagree. – Stephen Kitt Apr 26 '17 at 09:44
  • OK, but the point is that one person is more likely to use multiple virtual terminals than multiple real terminals at the same time, and attempting to save RAM or swap space by sharing a shell process among terminal sessions has even less sense than it has today. Nowadays one gnome-terminal process in Linux serves multiple terminal windows because a for a heavy GUI application it makes sense; not that much for a command-line shell process which uses much less memory. – Leo B. Apr 26 '17 at 22:06
  • Yes, I agree. (And it’s a shame GNOME Terminal is a heavy GUI application, but that’s another story.) – Stephen Kitt Apr 26 '17 at 22:26