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?

  • If you're going for really ancient, looking at 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

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.

  • 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). 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 1 '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. May 7 '17 at 11:34

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.

  • Even with terminals which aren’t real devices, they can still be used by different people ;-). 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. Apr 26 '17 at 7: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 8:24
  • Is that better? Feel free to roll back if you disagree. Apr 26 '17 at 9:44

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.