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?

  • 1
    is it set as an executable file?
    – jsolarski
    Commented Feb 10, 2011 at 15:06
  • yes, the file is executable, which is why I would think it would just run on its own.
    – muttley91
    Commented Feb 10, 2011 at 15:23
  • 1
    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. Commented Feb 10, 2011 at 15:28
  • 1
    How do you start it, and what is the errormessage? Commented Feb 10, 2011 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.
    – user7509
    Commented Mar 9, 2014 at 13:39

3 Answers 3

  1. Make sure you start the script with ./script or full path or whatever. Just script may not work (it works if the directory is in $PATH, like /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 now-a-days (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.

  • 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
    Commented Feb 10, 2011 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
    Commented Feb 11, 2011 at 8:26
  • 1
    Or, preferably, #!/usr/bin/env bash, which is slightly more portable.
    – Sparhawk
    Commented Mar 9, 2014 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.

  • No, I set it to bash just out of habit anyway.
    – muttley91
    Commented Feb 10, 2011 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.

  • 1
    Word choice is slightly misleading here. Commands won't be overridden. If you have a command in current working directory that happens to have same name as a the one living in system directories, say echo for example, the one in your directory will be used simply because that directory is set in PATH variable before the /bin. Shell simply looks for commands in particular directories depending on their order in PATH, and doesn't override/destroy anything. But yes, this has implications Commented Jul 22, 2018 at 8:14

You must log in to answer this question.

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