Usage of #!/bin/sh vs #!/bin/bash shell scripts
 

Some question about the usage of shell scripts:

1.) Are the commands of the base shell scripts a subset of bash commands?

2.) Assume I got a long, long script WITHOUT the first line.
How can I find out if the script was originally designed für "sh" or "bash"?

3.) How can I check a given script for syntax (not: logical) errors?

4.) Currently I have to enter

./myscript

to execute a certain script

How can I setup Linux so that the leading ".7" is not necessary any more?

Peter

1) You can look at it that way. By using /bin/sh, you tell bash to run in Bourne Shell "compatibility mode". Any bash specific internal commands and constructs will not be available and generate an error.

2) You can check it for bash specific constructs. Or run it in Bourne shell mode

Bash specific constructs will cause an error.

3) Run it, or check it yourself. There may be automated tools out there, but I am not away of any. Also, any syntax highlighting editor (such as my favorite, emacs) may help you out there as invalid syntax will not be properly highlighted. Open quotes, parens, etc will cause syntax highlighting to go awry.

4) I wouldn't advise it, but you can append '.' to your user's path in their startup files. That will enable running a script (or any binary) in whatever directory the user is currently in.

1) Yes.

2) You'd have to check it for bashisms. In other words check for things that will run in bash but not sh

3) The -n option for "bash" will check syntax of the script file itself. It's buried quite deeply in the manual page for "bash". It's not such a good manual page, but is very worth trying to skim or search. The manual page for "dash" might be more useful if you have it, but that's not "bash"

4) You'll have to put the script into a directory that exists in your $PATH. Usually homemade scripts go in /usr/local/bin/ or /usr/local/sbin/ depending on their nature. You could put it in ~/bin instead, too, if ~/bin/ is in your $PATH. Many distros set up your profile so that it is, but for that to take effect, create ~/bin/ and then log back in again and check your $PATH.

I stand corrected. :)

Speaking of corrections ;) I should add that the -n is accessible via the built-in command "set", so that unnecessary time is not wasted looking for it.

I rather like "bash" and "ksh" and sorta "zsh" but the manual page for "bash" is really overwhelmingly long and hard to read.

You should be aware that there are a number of shell programs, among them BASH, KornShell, C-Shell, some C-Shell derivatives and Bourne Shell (although sh is an emulator as pointed out above).

You are assigned an optional user command interpreter when you log in; on most Linux systems that will be /bin/bash, the Linux default.

However, you may be writing shell programs (scripts) in one of the many command and shell programming languages and the "sh-bang" (pound exclamation point) allows you to execute, say, a C-Shell program in the C-Shell, not in BASH. C-Shell starts, the program executes and the C-Shell goes away when the program completes.

It's used frequently in some work environments where every user is assigned C-shell as the default shell but software is written in KornShell or, maybe, BASH or whatever for some reason or other. It is atypical that you're assigned Bourne Shell by default as Bourne is somewhat limited. That is common in Sun Farms where Sun Microsystems had been the vendor of SunOS (which was BSD which insisted on C-Shell) and carried over to Solaris (AT&T SVR4). BSD -- Berkely Software Distribution -- was the developer of C-Shell. It is typical that BASH is not generally found on Solaris in favor of KornShell (which BASH is derived from, Korn and BASH are pretty much compatible as long as you don't use BASH extensions (of which, in my opinion, there are far too many of). In Solaris, sh is actual Bourne Shell.

Hope this helps some.

It's also worth pointing out that sh is not necessarily the same as bash. In Debian and its derivatives, it's a link to dash.

And, if /bin/sh is linked to bash, an invocation of /bin/sh will drop *some* bashisms, others remain.
As a consequence, a /bin/sh script on CentOS might syntax-error on a Debian derivate or a Unix derivate.
Therefore, a portable #!/bin/sh script (default if there is no #! shebang) should be developed+tested on a Debian derivate.
Or it should be an explicit #!/bin/bash script, that is also portable, because even Unix derivates have got a /bin/bash from open source.