Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I always declare the shebang line #!/bin/bash in my shell script. Recently, when I called a script that contains an exit call, it killed my terminal. It usually kills the forked process and returned to my terminal prompt. Why might have happened that stopped the forking?


$ bash --version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)
  • I usually invoke script using . script_path or via a symlink to the script.
share|improve this question
How did you invoke it? What version of bash is it? – Keith Mar 14 '11 at 2:29
up vote 4 down vote accepted

The shebang doesn't cause a process to fork UNLESS the script is executable and it is invoked in such a away that it causes the system to evaluate the shebang to see what program/shell to execute the script with.

If, for instance, you were already running in bash and you executed the script with the 'source' command, then the script would be executed inside the shell you were currently running, and the exit would affect that shell process, rather than it being a new shell process which got ended.

How did you execute your script?

Edit 1

If you have a script file that you want to run, you should make it executable with the following command:

chmod +x script

Then if you want to run the script, and if we assume that the script file is in the current directory you use the following command:


Note that this is very different from . script which is just shorthand notation for source script.

The ./script is a relative pathname to the script file, which means search in the current directory to find the script file 'script' and then execute it -- which only works if the script file is executable.

If you have script file that is NOT executable then you can invoke it with:

bash script

But in this case you are specifying which shell to run and the shebang line is ignored.

share|improve this answer
Thank you for your reply. I run it by ". script". The strange thing happens intermittently. As I said, this didn't happen before. – Martin Mar 14 '11 at 3:04
The . is shorthand for the source command. If you want it to fork, you need to make the script executable, and then put it in your path somewhere, then you can execute it by typing the name, or if it is not in the path, by typing a pathname to the script. – Zeke Hansell Mar 14 '11 at 3:16

Since sourcing a script using . causes it to run in the current shell, an exit causes the current shell to exit. You can use return to return from a sourced script as well as from a function. You cannot return from a script that was run directly.

In order to work within these constraints, you can put a conditional test in your script to do the right thing depending on whether it's sourced or run directly.

As the first line after the shebang:


At the point you want to exit or return:

[[ $called != $0 ]] && exit || return
share|improve this answer
Clever trick. Very useful for scripts that must be sourced to work properly, like python virtualenv activate scripts. – hobs Jul 12 '12 at 16:24
@hobs: I include the following line as the first line instead of a shebang in any scripts that must be sourced: [[ $_ != $0 ]] || { echo "This file must be sourced to have any effect."; exit 1; } – Dennis Williamson Jul 12 '12 at 18:22
Exactly. Thanks. – hobs Jul 12 '12 at 18:36

The shebang does not cause a program to fork; whether or not the process forks is dependent on how the script is executed. Sourcing the script will cause it to run in the current interpreter, and using exec will replace the current process entirely.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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