Why does the Bash shell run scripts in subshells? What is the advantage of doing so?

  • while this is an interesting question, did you do any research that you can share?
    – pLumo
    Apr 30, 2020 at 12:01
  • What lead you to ask this question? Dot scripts (scripts that are sourced) are not run in subshells, so you will have to give a bit more context to you issue. ... and technically, a script is usually not in a subshell but in a child shell to the invoking shell, i.e. in a separate process altogether.
    – Kusalananda
    Apr 30, 2020 at 12:05
  • @pLumo @Kusalananda I am learning Bash and what led me to ask was that at first I thought it's so that done this way so that control can return to the parent shell immediately and the user can carry on with her other tasks. But then I realized that is not the case (the shell waits for the subshell to finish) and for it to run in background we have to specifically give the command (&) whether we use ./``script` or source script. So what I thought would have been the most predictable rationale doesn't seem to be the reason.Online I found that different shells have slightly different policies
    – Lavya
    Apr 30, 2020 at 12:17
  • 3
    the parent shell does not necessarily wait. That is just the default ... Btw: you can edit your question and add information.
    – pLumo
    Apr 30, 2020 at 12:26
  • 1
    If it's about scripts that you run as executables (in opposition to sourcing them) then you should not think of them as "running Bash scripts". Think about each as "running an executable using some interpreter". It so happens the interpreter (from shebang) may be bash, but it may be something else (e.g. awk or python). In all cases the script does not affect your current shell (while a sourced script would be able to), so this is very consistent. The shell may be other than Bash or there may be no shell at all; it doesn't matter for a script with proper shebang. Apr 30, 2020 at 12:43

1 Answer 1


The shell, well, initially called the "user interface" of a system, was given the responsibility of executing programs (a.k.a tasks). To call a task, the shell would, in turn, ask the kernel to execute the task. The kernel manage the memory the task would use and the permissions to read or write to files. To ask the kernel to "execute" a program, the basic method is to fork a new task (which gives it a new PID (process number)) and then to exec the new program inside that new PID. The kernel would receive a list of arguments:

int execve(const char *filename, char *const argv[], char *const envp[]);

Basically asking the kernel to execute filename with arguments argv[]. The kernel does what is asked to do and when the program terminates the control returns to the parent process.

Taking the shell as the executor of programs, it is an obvious extension that it could also execute text files that some interpreter could understand. That is the mechanism of the shebang #! /interpreter which the kernel also understand.

So, a shell could (and sometimes do) "execute an script", but the most natural execution sequence is to ask the kernel to do as with any other program: load the program and give it control of the process (PID).

It is expected that any program executed inside a different PID doesn't pollute the parent PPID. That is: changes in one PID doesn't affect the parent PID.

So, when "an script" gets executed it (usually) gets a new PID. Whether it is called subshell or a child shell is sometimes confusing, but what matters is that it runs inside a different PID. Usually a child process (PID).

  • Perfect. Thank you!
    – Lavya
    May 1, 2020 at 5:51

You must log in to answer this question.

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