This question already has an answer here:

Given a shell script file that begins as


# (bash script here),

and has been chmod +xed, is there any difference in running ./script and bash script from the command-line?

marked as duplicate by Archemar, Anthon, dhag, jimmij, Drav Sloan Aug 13 '15 at 15:18

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


It depends on your $PATH. ./script will run /bin/bash script. bash script will use whatever bash comes first in your path, which isn't necessarily /bin/bash, and could be a different version of Bash.

  • Okay, that makes sense; is there a "preferred" or "recommended" way to do it? I've always seen ./script but recently saw a couple answers on Unix.SE using bash script. – wchargin Nov 11 '13 at 21:49
  • 1
    The more generic "bash script" version is useful if you are testing against different versions of bash. Imagine ~/bin is first in $PATH and ~/bin/bash symlinks to ~/bin/bash_versions/4.2.45/bash or ~/bin/bash_versions/4.1.11/bash or other versions. If you tried to do the same thing with /bin/bash, you would need to be root (to alter /bin) and would undoubtedly eventually break something in your distro. – Joe Atzberger Nov 11 '13 at 22:48
  • 2
    @WChargin People sometimes write bash script instead of ./script in usage instructions so that they don't need to explain how to give script execution permissions or what to do on the (non-Linux) systems where bash isn't in /bin. – Gilles Nov 12 '13 at 0:10
  • @Gilles Excellent; that clears it up. Thanks. – wchargin Nov 12 '13 at 2:35

There are two differences:

  • ./tryit.sh will not run if bash is not located in /bin, but bash tryit.sh will run if bash is anywhere on your PATH. This is because ./tryit.sh will use the shell from the bang path (/bin/bash), but bash tryit.sh will use the first bash shell on the PATH.
  • ./tryit.sh will not run if the execute bit is not set, but bash tryit.sh will run the script. You have excluded this case by specifying the bit has been set. Some edits may clear the bit causing a working command to start failing.

The command bash tryit.sh invokes bash telling it that the commands to be executed are found in the file tryit.sh. Many programs such as awk, perl, python, bash, sh, ksh, work in this manner. This is a standard idom for Unix programs that process command files.

  • 1
    Can you please point me to something that elaborates on your second point? "./tryit.sh will not run if the execute bit is not set, but bash tryit.sh will run the script". Documentation? Articles? Anything. – Slothworks Aug 13 '15 at 7:05
  • @Slothworks FWIW, source tryit.sh won't care about the status of the +x bit either :) In any case, I think the source way is much better than using the fairly huge bash binary itself to run a script which lacks the +x flag. I've never had a situation when I had to (mis)use bash as a trigger to run such non-executable script. – syntaxerror Aug 13 '15 at 8:32
  • @syntaxerror I am aware of source being able to do that, with its set of nuances of course. I merely wish to look at some content that expands on @BillThor's second point; maybe elaborating (more than the single line in the answer itself) on why bash can run a script which lacks the +x flag etc. – Slothworks Aug 13 '15 at 9:25
  • In a nutshell: IMO using bash itself (instead of its built-in commands) for running a script I'd almost compare to "committing a crime." – syntaxerror Aug 13 '15 at 9:29
  • @syntaxerror See my update. – BillThor Aug 13 '15 at 18:22

They are subtly different and easy to make a mistake.

The one you should use (which I'll write in two forms)

bash ./script

My reasoning is that this is explicit, in case you've changed directory.

non explicit forms

bash script

Are less safe. bash script will search the current directory then the directories in the PATH environment variable, script by itself is searched only in PATH directories. Running a different command than intended could clobber your files.

  • 3
    You seem to be answering a different question. The OP is not asking about the difference between bash script and bash script but bash ./script and ./script. If you run ./script, your $PATH is irrelevant, since you are giving a full path, the shell will never look for script in your $PATH variable. – terdon Nov 11 '13 at 16:43
  • Upon re-reading I think you are correct, there's probably a typo in his question " is there a difference between ./script and bash script" which is what I answered – X Tian Nov 11 '13 at 16:52
  • 1
    @XTian No, there isn't a typo - the difference between ./script and bash script is exactly what I'm asking. However, I fail to see how you've answered this. Also, you seem to imply in your answer that simply writing script will "look in the current directory for script ... then search through the ... PATH" if it doesn't find it; unless I'm mistaken, I don't believe this is the case. Running script will only find a file on the path: $ touch script; $ script; bash: script: command not found. – wchargin Nov 11 '13 at 21:54
  • @WChargin Ok, so there isn't a typo, my bad. I'm only trying to warn you that bash ./script is much safer than bash script. In the latter, if script is not found in your cwd, then the PATH is searched, and if found will be used to read commands from (it doesn't even have to e executable!). There's no difference between ./script vs bash ./script but a big difference when ./ is omitted. ps I sometimes come across people with dot in their PATH, you are correct, bash doesn't search for commands there normally. – X Tian Nov 12 '13 at 13:59

If I remember correctly from the top of my head, the following two are identical:

$ ./script


$ source script

So using the ./ "command" will in fact invoke source under the hood, which on its part is a bash builtin command. Or, in another interpretation they might be called aliases of each other. However: The first invocation requires you, the user, to set the +x (=executable) flag with chmod for owner or group, otherwise you will get a "permission denied" error, whilst execution using the source command is even possible without the +x flag. So the latter will sometimes be your life-saver whenever you want to run a bash script off an NTFS-formatted pendrive, for instance, since chmod cannot work there.

I think that will answer your question as well in some way.

Because, for that reason, bash script and source script cannot be exactly the same; the one is calling the bash program itself with your script given as a parameter, whilst the other is calling one of bash's builtin commands with your script as a parameter. Though the result will most probably be the same (at least in everyday use), the ways how to get there are somewhat different in both cases.

  • 2
    Um, no.  . script and source script are equivalent in bash and the other shells in which . and source mean the same thing.  ./script runs the script in a separate process.  . script runs the script in the current shell process, which (a) might not be bash, and (b) lets the script alter your main shell's environment.  This requires that you have read permission to the script.  ./script runs the script in a new process, using the interpreter specified in the shebang, provided the user has both read and execute permission. – Scott Aug 13 '15 at 8:41
  • Wait a moment...I have never written anything about the . command. That's yet another pair of shoes. I only mentioned ./script and source script in my answer, but not . ./script. Yes it can be confusing at times. Ah, and big thanks for the downvote. :P Yay, that felt so refreshing. – syntaxerror Aug 13 '15 at 9:03

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