Quickly, back to your first question. Though it isn't strictly necessary to use the shebang, it is better safe than sorry. Some systems may not know where to go or what to do with the script. So, if you know the system that the script is for doesn't need a shebang, you don't, need to use it. But if you don't know for sure, you better use it.

It depends. The exec() call itself will always fail. Whether there is a fallback to invoke /bin/sh depends on what was compiled into the program making the call. Well-behaved utilities (e.g., find with the "-exec" option, awk invoking an external process) do, when they see the ENOEXEC error, invoke /bin/sh to interpret the file. awk actually goes the extra mile and reads the beginning of the file first to see if it looks like a script, rather than a binary perhaps intended for a different OS or architecture. But none of that behavior is anything that is built into the library, and certainly not part of the system call itself, making it very much a YMMV thing.

1 members found this post helpful.

Well, those are are just conventions as noted above... Nothing stops you from writing a program that probes for file types. You could programatically try to load it as a word document or as an image file even if exec() fails... So, the best thing is not to assume anything, and, again, write the damned shebang. In the extension that this thread has already, we could write like a couple thousands of shebang lines :P

Do note that /bin/sh is usually identical to /bin/bash with POSIX restrictions enabled. (That is "built in" to the bash executable, and is based on the name with which bash is called. /bin/sh is usually just a symlink to bin/bash.)

Create a script that would echo the shell's signatures like echo "$0" > ~/shell-info or cat "/proc/$$/cmdline" > ~/shell-info.txt; then run it.

And perhaps ps u "$$" as well. Or perhaps check shell-specific variables like "$BASH", "$BASH_VERSION", and "$BASHPID".

This can't be relied upon to be true. Many distributions like Debian are now setting /bin/sh to be dash by default, which is a very strict POSIX shell.

You can never be certain what will happen if you use non-POSIX features (e.g. arrays) inside a /bin/sh script. Some interpreters will continue accept them if they support them, but others will choke. It all depends on which interpreter the system is set to use, and whether the code in question is actually anti-posix or just undefined according to it.

In short, when writing #!/bin/sh scripts, always stick to POSIX-defined code only. If you want to use the features of a specific shell features, your shebang needs to explicitly point to that interpreter.

As above, in fact I'd go with the even shorter version
and say always specify the shell you want, unless you are just messing about and know what your current shell really is/does.
See my previous post about PROD systems

The key is "the default is usually the /bin/sh"...

If the program invoking the script (via exec) is programmed to use the default then it is true.

If it is is not programmed, then no default exists, the "usually" is for the case where there is a default.

Granted, the sentence is not as clear as it could be. This particular "default" only exists in command line shells... it doesn't exist anywhere else.

The system call execve (lies at the base of all the exec calls) has the kernel perform all "#!" interpretations. If either "#!" doesn't exist, OR the name of the executable following the #! doesn't exist in the script, the error is "ENOEXEC".

The invoking program should then have a "default" implemented. By convention, command interpreters do have a default (several actually). Some just fork themselves and attempt to process the command. Others will take the value of environment variable "SHELL", and exec that combined with the script as a parameter. Yet others will do both - if the SHELL environment variable doesn't exist, then they will use a fork of themselves.

NOTE: bash, when it does this, only passes the exported symbol list, so the forked shell doing the processing does not have the nonexported symbols. I'm not sure about other shells, but I think this is the convention. It does make the environment of the script equivalent to that of a fork/exec sequence, even if the exec part is not done.

Now, as stated,this is only for those formats identified as "scripts". The kernel allows additional formats - the usual default is ELF, scripts, and java... All three examine the first couple of bytes to determine if they are applicable, then the system goes to the next one (and no, I'm not sure what the order is. I would think it would go ELF, Java, then scripts). It is also possible to have aout format, as well as other modules that get kernel modules loaded for support (one that handles java, em86, and wine, is binfmt_misc, but you have to have all the right options selected).

Heh, I just noticed my typo. "Features of shell features", indeed.

And you're right, of course. The only reason to single out /bin/sh explicitly is the large amount of confusion surrounding it. The position it occupies in the OS is unclear to many, it's often conflated with other shells and, perhaps worst of all, non-posixly-defined features will usually continue to function with it if the underlying interpreter is compatible. It's one of the kings of gotchas.

Yeah, I avoid it like the plague.
As you say, you never really know what you're actually(!) going to get....

On Linux I go bash, on Solaris, HP-UX etc, I usually go ksh; partly for historical reasons and partly because most others do on those platforms, so its simpler/kinder to stick to that.
Most of the built-ins in ksh work unaltered in bash, but the reverse is not true, as bash has continued to be developed, whereas the last official ksh release seems to be ksh93 http://kornshell.com/.

External cmds eg 'find' are a whole other bucket of fish

Despite its name, ksh is still actively developed. Its last version is ksh93u+ (June 2012).

There are ksh93 specific features, bash specific features and occasionally differences in implementation so you need to stick with either POSIX compliant constructions or features implemented and supported the same way with bash and ksh to write scripts portable between both of these shells.

Interesting to know ksh is till being developed; thx.