In Windows, when using the CLI, only one program is used (cmd.exe). You send the input to cmd.exe, and cmd.exe in turn sends you the output (displays the output on the screen that is):

enter image description here

But in Linux, there are two programs that are used: the Terminal and the Shell.

You send the input to the Terminal (for example: gnome-terminal), and gnome-terminal in turn sends this input to the Shell (for example: bash), and then bash sends the output to gnome-terminal, and gnome-terminal in turn sends you the output.

enter image description here

My question is: Why the Terminal and the Shell are two separate programs in Linux and not one program like in Windows?

  • 2
    related: unix.stackexchange.com/questions/4126/…
    – Sundeep
    Apr 13, 2017 at 15:01
  • The short answer: Because we (in unix) likes when things "just works", by the Divide et impera. For the longer answer read the above link. ;) Many GREAT answers.
    – clt60
    Apr 13, 2017 at 15:03
  • If they were combined, I would be forced to run X11, which I don't want to be doing. I'm running OpenBSD in a VM which I SSH into.
    – Kusalananda
    Apr 13, 2017 at 15:03
  • As far as I can make out from the cmd.exe Wikipedia page, cmd.exe corresponds to the Unix terminal, and the Win32 console acts like the shell (or the other way around), but I could be wrong there.
    – Kusalananda
    Apr 13, 2017 at 15:15

5 Answers 5


Your premise is incorrect. The role of the "terminal" in Windows is played, more or less, by conhost.exe - the console subsystem isn't designed in such a way to make it interchangeable as terminals are in Linux (and there are other differences, for example, when you start a console-mode process such as cmd.exe not already attached to a console, the system libraries that start the process will take care of creating one for you), but it is a separate layer managed by a separate process.


I'd say 1) because of history, 2) because it's a good idea.

Usually we call gnome-terminal or xterm a terminal emulator. In the times of yore, there were no terminal emulators, since there were no graphical user interfaces. All there was, was proper terminals, devices with a screen and a keyboard that connected via a serial cable to the computer. Shells were useful then, too, and were written to support taking commands from terminals. (Probably from arbitrary file descriptors, but that doesn't matter.)

With something like Linux virtual terminals and GUI's, it was useful to make them emulate the original terminals, so that old pieces of software would just work, or at least would with minimal changes. That doesn't only mean the shell, but also other programs that interface the "terminal". (ls? vi? emacs?)

Also, the separation is a good idea, since it allows one to swap the terminal emulator and the shell independent of each other. I can use Bash on xterm, or zsh on gnome-terminal, or Bash over an SSH connection, or...

If the parts were tied together, this choice would be harder.

Incidentally, I'm not exactly sure about cmd.exe implementing the terminal emulation part in itself either. I haven't touched a compiler on Windows in some time, but if I recall correctly, it's possible to create a "console application" without involving cmd.exe. See here and here.

  • Indeed command shell and terminal are provided by different programs in Windows: the terminal emulator (called “console” in Windows) is Csrss in older versions and Conhost in newer versions, and can be replaced with alternatives such as Console2 or Conemu. Apr 14, 2017 at 21:24

gnome-terminal will run bash as a default application, but xterm, gnome-terminal and familys are intended to run arbitrary command, not just shell, you can run for instance :

xterm -e /bin/bash
xterm -e /usr/local/bin/fish
xterm -e tail -f /var/log/messages
xterm -e man ls

in last case, xterm will show me ls man page, if I quit, xterm will exit.

in case of /var/log/messages, I might use xterm options to set font or change color.

note that gnome-terminal also use -e syntax to run commands.


The Windows world is very different from the Unix world. One of the differences is that on Windows an executable has special data inside it which tell the operating system what kind of executable it is; for the purpose of this question, there are tree kinds of executables:

  • Executables which run in the traditional graphical subsystem. They promise to create their own windows if needed, and to read and respond to messages generated by the graphical subsystem.

  • Executables which run in the console subsystem. They require the operating system to create a special kind of window for them (a console). The console takes over the chores of respoding to messages, and gives the program a simpler environment.

  • Executables which run in the post-Windows 8 "Modern UI" subsystem. Those are sort-of like programs which run in the graphical subsystem, but use a different API (and are treated as a separate class of processes by the OS).

cmd.exe is not the only program which runs in a console. There are myriads of console programs, including ports of a very large number of GNU utilities (see for example the GnuWin32 project) and PowerShell, an alternative console-based shell for Windows 7 and newer, very very much more flexible and powerfull than cmd.exe.

When a console-based program runs in console, you don't interact directly with the program, you interact with the console subsystem which mediates between user's input and the running program; for example, the console subsystem translates keystrokes into the encoded characters expected by the console-based program and uses a specified font file to translate characters output by the program into the pretty little pictures the user sees.


I think , because in Linux you can have several shell (bash ksh ....)

In Windows only have 1 program, the cmd. And now Microsoft need 2 programs to add more funcionality (power shell)

In Linux only need change the shell to improve your requirements

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .