Quote:
Originally Posted by
Clovis_Sangrail
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.
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.
Quote:
bash is also supposed to be backwards-compatible to sh, right?
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.
Quote:
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.
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
- String operations, so you can do echo ${string:offset:length} instead of echo $string | cut
- var=$(command) instead of var=`command`, since $( ) nest properly and never split
- Mathematics with VAR=$((A+B)) instead of let VAR=A+B
- Better and more complex conditionals with if [[ ... ]] instead of if [ ... ]
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.