Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

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

On our school system, we're able to run script files without typing bash or csh or what have you without indicating what script type it is. On Ubuntu, however, I'm required to type bash script.bash for example. Is this always necessary in Ubuntu, or is it some setting I can change?

share|improve this question
is it set as an executable file? – jsolarski Feb 10 '11 at 15:06
yes, the file is executable, which is why I would think it would just run on its own. – muttley91 Feb 10 '11 at 15:23
What error do you get when you type ./script ? Are you sure that the script was not changed from a Windows editor placing an extra char at the end of lines ? That would break the first line pointing that the script must be executed with bash. – João Pinto Feb 10 '11 at 15:28
How do you start it, and what is the errormessage? – user unknown Feb 10 '11 at 16:40
+1 for not using .sh for bash scripts. Generally file extensions are not used for executable scripts in the UNIX world, though. – nyuszika7h Mar 9 '14 at 13:39
up vote 15 down vote accepted
  1. Make sure you start the script with ./script or full path or whatever. Just "script" may not work (it works if it's in the path like in /usr/bin), since on UNIX systems it's not a habit to have the current directory in your path (for security reasons, and it's good!)

  2. Make sure the script is executable, for example: "chmod +x script" will made it executable.

  3. Make sure, you have #!/bin/bash as the first line in your script. Also make sure, that it's not edited with some kind of Windows editor, since those often uses the "DOS type" of eol (end of line) which differs from the UNIX one (if the checklist above is OK, but you got "bad interpreter: no such file or directory" or so, even if it's /bin/bash, this is often the reason, as the non-printable - so you usually don't see it - \r will be treated as the part of the path of the interpreter)

Others already mentioned: it's important to have /bin/bash if you use bash features, also /bin/sh was symlinked to /bin/bash, but nowdays (as far as I noticed) it's symlinked to "dash" which won't provide bash compatibility, only the POSIX "sh". It's quite important, even quite expensive softwares at our firm have this issue: scripts contain #!/bin/sh as the first line but it depends on bash functionalities as well.

share|improve this answer
So I will have to run it like so: ./script, as I have discovered. This is better than having to type "bash" each time, and it makes sense. I believe I knew this before, it just slipped my mind. Oh well, thanks! – muttley91 Feb 10 '11 at 17:25
In theory you can put the current working directory into the PATH variable so then you can use just "script" instead of "./script" but I warn you: this is really not a habit on UNIX systems and it can be a security problem! Also it's not nice in a school to learn things in a way which has never been the solution on UNIX systems, so I would avoid this solution ... – LGB Feb 11 '11 at 8:26
Or, preferably, #!/usr/bin/env bash, which is slightly more portable. – Sparhawk Mar 9 '14 at 14:46

Make sure the first line of the file reads:


If the shebang is #!/bin/sh, you should not use any bash-specific features, only POSIX features. Even if /bin/sh is a symlink to bash, bash will run in a POSIX compatibility mode when run as sh, disabling some (but not all) bash features.

You'll also need to make sure the script is executable, of course.

share|improve this answer
No, I set it to bash just out of habit anyway. – muttley91 Feb 10 '11 at 15:24

An alternative, strongly discouraged way is adding . to PATH.




The problem with this approach is that in the former case, any system command could be overridden with executables from the current directory, and in the latter case, unknown commands could still be overridden.

Consider the following:

File: ls


./my_malicious_script &>/dev/null
/bin/ls "$@"

Most likely you wouldn't even notice until it's too late.

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.