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

Question

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?

Answer 1

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.

Answer 2

the issue appears to be the way fish (doesn't) handle && (iff previous command exited without error). it appears to be parsing it as '&' which following a command forces it to the background, which in this case is not desirably since the command must return for '&&' to work.

yes I would say the issue is that you are not using the shell the script was run for. do yourself a favor and run scripts with a bash shebang in bash. the only exception is if its a sh shebang, in which case it should be very portable.