13

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?

5
  • 1
    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
  • 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. Feb 10 '11 at 15:28
  • 1
    How do you start it, and what is the errormessage? 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
19
  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.

3
  • 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
  • 1
    Or, preferably, #!/usr/bin/env bash, which is slightly more portable.
    – Sparhawk
    Mar 9 '14 at 14:46
4

Make sure the first line of the file reads:

#!/bin/bash

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.

1
  • No, I set it to bash just out of habit anyway.
    – muttley91
    Feb 10 '11 at 15:24
0

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

PATH=".:$PATH"

or

PATH="$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

#!/bin/bash

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

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

1
  • 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 Jul 22 '18 at 8:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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