When default shell is not bash-compatible, why do bash scripts not work well

bashchshfishshell-script

My default shell is fish, because it's a lot nicer. But often when I run scripts, I get errors that seem to be from the bash script being processed by fish. I think this is because the script writer assumed that the default shell is bash, but I don't understand the mechanism.

For instance, the CrashPlan install.sh script starts with a bash shebang:

~/CrashPlan-install> head install.sh
#!/bin/bash

#############################################################
# Linux Client Installer Script
#############################################################

So when I run ./install.sh it should be processed by bash, right? The default terminal shell should be irrelevant. Yet, when my default shell is fish, running scripts like this causes fish to return errors, as if it's processing the script:

fish: Expected a command name, got token of type “Run job in background”. Did you mean
 “COMMAND; and COMMAND”? See the help section for the “and” builtin command by typing “help and”.
Standard input: sed -imod "s|Exec=.*|Exec=/usr/local/crashplan/bin/CrashPlanDesktop|" 
 /home/username/Desktop/CrashPlan.desktop && rm -rf /home/username/Desktop/CrashPlan.desktopmod

Is this because of a misconfiguration of my computer or because the script is written in a non-portable way?

Best Answer

So when I run ./install.sh it should be processed by bash, right?

Indeed. That's exactly what the shebang is for.

Troubleshooting

Save the following as test.sh and try to run it from fish.
```
#!/bin/bash

true && true
```
It works on my computer, and it should on yours.
Check if the first line of install.sh contains only the characters #!/bin/bash.

Invisible characters (such as a CR linebreak) could confuse fish.
Run
```
/bin/bash --version
```
to check that bash is actually bash and hasn't been accidentially replaced/modified over time.

install.sh

$SRC_USER is just a synonym the script creates for $SUDO_USER.

As a result, when the script is run with root privileges, the command

su ${SRC_USER} -c "sed -imod \"s|Exec=.*|Exec=${GUISCRIPT}|\" ${DESKTOP_LAUNCHER} && rm -rf ${DESKTOP_LAUNCHER}mod"

automatically uses the sudo user's default shell, which is fish.

To override this default, add the instruction -s /bin/bash to the su command.

Related Solutions

Should I put .sh and .rb file extensions on all the scripts

You can do wildcard commands like ls *.rb or cp *.sh if you want to organize your scripts in the future.

Start early or regret later, in my opinion.

Editors like vim will also be able to apply the correct syntax highlighting based on shebang or file extension.

This can also be accomplished by using modelines in various editors. E.g. for vim:

# vim: ft=sh

Writing shell scripts that will run on any shell (using multiple shebang lines?)

Which shell executes scripts when there's no shebang line (#!/path/to/shell) at the beginning? I assume /bin/sh but I can't confirm.

The kernel refuses to execute such scripts and returns ENOEXEC, so the exact behavior depends on the program you run such a script from.

bash 4.2.39 – uses itself
busybox-ash 1.20.2 – uses itself
dash 0.5.7 – runs /bin/sh
fish 1.23.1 – complains about ENOEXEC, then blames the wrong file
AT&T ksh 93u+2012.08.01 – uses itself
mksh R40f – runs /bin/sh
pdksh 5.2.14 – runs /bin/sh
sh-heirloom 050706 – uses itself
tcsh 6.18.01 – runs /bin/sh
zsh 5.0.0 – runs /bin/sh
cmd.exe 5.1.2600 – looks at you funny.

In glibc, functions execv() or execve() just return ENOEXEC. But execvp() hides this error code and automatically invokes /bin/sh. (This is documented in exec(3p).)

What is considered "best practices" in terms of writing shell scripts that will run on any platform? (ok, this is sort of open-ended)

Either stick to sh and only POSIX-defined features, or just go full bash (which is widely available) and mention it in your requirements if distributing it.

(Now that I think of it, Perl – or perhaps Python – would be even more portable, not to mention having a better syntax.)

Always add the shebang line. If using bash or zsh, use #!/usr/bin/env bash instead of hardcoding the shell's path. (However, the POSIX shell is guaranteed to be at /bin/sh, so skip env in that case.)

(Unfortunately, even /bin/sh is not always the same. The GNU autoconf program has to deal with many different quirks.)

Is it possible to write a script that tries to use zsh and falls back to bash if zsh is not available? I've tried putting two shebang lines, like below, but it just errors with bad interpreter: /bin/zsh: no such file or directory out if I try it on a machine without zsh.

There can only be one shebang line; everything after the newline character isn't even read by the kernel, and treated as a comment by shells.

It's possible to write a script that runs as #!/bin/sh, checks which shell is available, and runs exec zsh "$0" "$@" or exec bash "$0" "$@" depending on the result. However, the syntax used by bash and zsh is so different in various places that I would not recommend doing this for your own sanity.