Linked by Thom Holwerda on Sat 31st Jan 2009 20:47 UTC, submitted by Oliver
Permalink for comment 346498
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
Linked by Thom Holwerda on 04/16/13 9:29 UTC
Linked by Thom Holwerda on 04/15/13 22:44 UTC
More Features »
Sponsored Links



Member since:
2006-10-08
This is understandable. UNIX's standard scripting shell is the Bourne shell /bin/sh which is not a Bourne Again shell using another name (or symlink or the like). #!/bin/sh is standard in UNIX, while #!/bin/bash seems to be standard in Linux, with a "symlink workaround" to stay compatible to UNIX (/bin/bash@ -> /bin/sh). The philosophy in the background is: As long as you don't use BASH specific functionalities, and as long as you want maximal interoperability for your scripts, declare it the UNIX standard way.
The C shell as a dialog shell has been chosen by other BSDs, too, such as FreeBSD.
BASH is installable on NetBSD (as an additional package) without any problems and you can use it, if you like, but not everyone wants to have BASH on the system.
Remember, when your system crashes and you have only ro access to /, you'll be happy to have the standard scripting shell and an excellent dialog shell available.
Well, it's one of these OSes that after installing it, you must make it usable manually, tailoring it to follow your tastes. "
That's what "usable" is defined. :-) Instead of putting everything users could need onto the disk in one rush, the user is encouraged to define exactly what he will need. So he installs the system and gets exactly a system fitting his particular needs, instead a "one does everything" approach that causes problems. Personally, I prefer this "tailoring approach" over anything else, especially for server purposes. BUt that's very individual, I think.