Knowing difference in coding between BASH and BOURNE, I would like to write a script specific for either. No problem still. But, when checked what /bin/sh actually is, it just seems to link to /bin/bash Question then is : if this difference in shells is so important, why does a given Linux distro, totally ignores that aspect, and just says, well, BASH and BOURNE is actually the same, you know ?! So, the whole theory of making a script specific for a shell, well, forget about it, we will link what shell to whatever other shell we want ?! Are BASH and BOURNE that similar, or what I am missing ?

[root@server ~]# cd /bin [root@server bin]# ls -ltr sh lrwxrwxrwx 1 root root 4 Apr 29 2008 sh -> bash [root@server bin]# ls -ltr bash -rwxr-xr-x 1 root root 615512 Sep 21 2007 bash [root@server bin]#

bash is the 'bourne again' shell. It is a 'clone' (work alike) of the bourne shell. Since no Linux distribution I am aware of includes the original bourne shell, bash is as close as we get in the Linux world. AFAIK, the bourne shell has never been ported to Linux. One fact you must remember is that Linux is NOT UNIX. Linux is a UNIX-like OS, but it is NOT UNIX. If what you want it to program UNIX, then you will have to pony up and purchase a copy of a UNIX OS, because Linux is not EXACTLY the same thing. It is similar, but there Are inevitable differences. In a similar manner, OpenDOS is not MS-DOS, or PC-DOS. The same software may run on all three OS's, but the executable code, as well as the code in the accompanying libraries differs. HTH, Ernie Registered Linux User 247790

OK, that explains a lot already. The UNIX I work on is never my own purchased copy, but I do work a lot with both Unix and Linux, and this issue strikes me, as the setup works against the idea of shells (being different things). The problem may now be that I'm writing scripts, which I will call Bourne scripts, on a Linux machine, but actually containing Bash compatible syntax ... and THEN, I take that script to a machine that does have a correct Bourne shell setup, and to find my Bash code not working (obviously). It's not mandatory for any given distro, to have all shells available, is it ? If one distro would say, well, we don't have Bourne, end of story. What's the consequence ?

Actually, the bash and korn shells are supersets of the Bourne shell, sh. Most *nix versions that carry sh are not POSIX complient. That goes for the unix sh I mostly use - Solaris 9. The Bourne shell does not support such bash/ksh extensions such as parameter expansion, POSIX command substituion, POSIX arithmetic, etc. If it's really important for you to move scripts between bash and sh, you really need to plan for it. If your scripts call external unix commands such as awk or sed, expect other problems. The GNU versions of sed and awk offer extensions that some of the legacy unix versions do not support. Consider that most of the legacy unix systems also provide a bash shell. But, of course, nobody forces anybody to provide any shell.

The first part of the script needs to detect which shell (unless both are installed) then go to section. Playing to the angels Les Paul (1915-2009)

Thanks for the information ... it's sort of important, as I am a user of both different Unix and Linux platforms, and a common usage (of scripts) would be nice. Good you mention sed and awk as well, I use that a lot ... and I'm not always aware of what is shell, what not. I consider AWK to be ... well, pretty much the same on all Unix and Linux platform, but I admit that that is a bit naive. Still, lots of features (parameters) are explictically kept the same, although the tool themselves have got different ppl writing it. It's a bit sad on one part, but on the other hand it is to be expected ... if another system (Unix versus Linux) would be totally the same, well, they would not be different systems, would they ? @jefro : I generally even avoid forcing to use a shell in a script, I have this "let's see what happens attitude". If I find myself having to fix each script, and then one OS says, oh, but OUR shells are in /whatever/directory/sh ... I would end up needing to fix all scripts AGAIN. In that context, I try to fix things, AFTER they appear broken, not before. You know, script never see to fail on one OS, it's only when you move them to another OS, you see the problem. And, I am not a fortune-teller/future-predictor, I'm just a programmer.