Bash Shell Scripts And Bad Interpreter

Beware! A Linux Bash shell scripts might fails to execute at all after uploaded from a different operating system. For example, from Windows OS to Redhat Linux.

Why? It is due to different encoding format implemented in different OS!

To confirm the shell scripts could run properly, always conduct testing upon finishing transfer. For example, duplicate a copy of the shell scripts transferred, remark all the lines of the shell scripts except the very first line where normally begin as #!/bin/sh (Sha-bang), append one simple line such as echo "test", then save and execute it. If the scripts fails to execute with error messages : Bad interpreter : no such file or directory, it might due to file encoding format!

Most commercial UNIX system default to Bourne shell /bin/sh (hence, called Bourne shell scripts) whereas Linux system default to Bash shell /bin/bash (hence, called Bash shell scripts). A symbolic link /bin/sh pointing to /bin/bash is usually created during Linux setup.

The first line of most UNIX shell scripts is #!/bin/sh. The two characters #!, known as sha-bang, tells the UNIX operating system that this file contains a set of commands to be fed to the command interpreter specified, which is /bin/sh.

This very first line #!/bin/sh can be omitted if only a set of generic system commands are used, or not using internal shell directives at all. Best practice is to include this line anyway.

If the UNIX shell scripts fails to execute with rejected error messages : Bad interpreter : no such file or directory,

1. Run command ls -la /bin/sh to confirm the specify path of command interpreter (the shell) is correct.
   
   In Linux system, it should be a soft link to /bin/bash. Verify that /bin/bash exists and create the soft link named /bin/sh if the link is not exists.
   
   Run the command ln -s /bin/bash /bin/sh to create a soft link (symbolic link) called /bin/sh pointing to the physical file /bin/bash.
   
   If the path is valid, then
   
   
2. Make a copy of the scripts file.
   Next, run command dos2unix YoursScriptsFileName.
   Finally, execute chmod 755 YoursScriptsFileName.
   
   If this step works, it means the scripts file encoding format is not compliance to UNIX/Linux format. Chance is there if the file being transfer from other platform like Windows OS.
   
   Running command od YoursScriptsFileName and compare the first line of octal format of the file contents to the octal output of command od BackupScriptsFileName will tell the different.