UNIX for Advanced & Expert Users

More than a warning, a strictly conforming portable script must not use it. The reason is POSIX doesn't defines a pathname for the POSIX shell and in particular /bin/sh is not guaranteed to be that one.

A compliant OS is required, when in POSIX mode, to pick the POSIX shell when executing a shebang-less script. The shebang is therefore useless for portable shell scripts as it either has no effect or a negative one when you happen to mistakenly pick a shell you think is POSIX but is not, like /bin/sh on Solaris 10 and older.

The Shell Command Language specs states:

The construct "#!" is reserved for implementations wishing to provide that extension. If it were not reserved, the Shell and Utilities volume of POSIX.1-2008 would disallow it by forcing it to be a comment. As it stands, a strictly conforming application must not use "#!" as the first two characters of the file.

korn shell is secure

always bash

---------- Post updated at 01:39 PM ---------- Previous update was at 01:39 PM ----------

can you justify?

@vinodchauhan123 vs @pandeesh

@pandeesh Please take note of the title of the thread and take the time to propose your argument with supporting evidence, rather than question the views of another poster without any supporting evidence.

bash, because without it, my OS would seem a mere shell of its actual self.

on the real tho -- i use bash because its the shell i've used since Fresh Prince of Bel Air had new episodes... I've never had a roadblock with bash that ever made me think that another shell was 'better' suited overall- - maybe for a particular instance, but rarely for an entire solution.

I've always liked bash for the command history that works with the arrow keys and the directory-name & executable-name autocomplete. My employer recently wanted a login menu script in ksh, and after dabbling with it I like ksh too, for the scripting capabilities it has over the standard sh. Apparently ksh is also strictly backwards-compatible with sh, so much so that (I've read) that AT&T ksh93 is being supplied as the standard /bin/sh in Solaris11. bash is also supposed to be backwards-compatible to sh, right? I suspect that you could spend a whole lot of time learning what bash can do that ksh can't and how, and vice-versa.

I doubt -- and hope -- their ksh isn't 100% compatible, since Solaris' usual idea of backwards compatibility is denying you all future features in the standard /bin/whatever, making you use /crazy/path/to/modern/whatever if you want them. Any shell that calls itself a Bourne shell, including bash, dash, ksh, pdksh, ash, and a few others are supposed to handle the standard Bourne features. The primary difference between bash and ksh is the way they handle arrays. In bash you do VAR=( a b c d e f ), in ksh you do set -a VAR ...

Another major difference is the order they handle pipes. In Bourne shells, echo asdf | read VAR won't work because 'read' will end up in a subshell, but in KSH that order is reversed -- the rightmost thing ends up in your local shell. This is a handy feature but profoundly not how Bourne shell handles it, so KSH could be considered incompatible that way... could conceivably alter the meaning of some code.

ksh also has the ability to handle floating point numbers, which bash and sh don't.

For the most part if you stick to strict sh code, it will work great in all three shells.

Some really nice things that vanilla sh doesn't have and its descendents generally do include
All these features are becoming more and more standard now. There's just a few holdouts left -- like Solaris' ancient crusty /bin/sh which AFAIK had none of the above for 'compatibility reasons'... If they're finally updating it, that's lovely.