Why is bash the default shell in most OS?

Solution 1:

I did some reading on this and the conclusion seems to be that it is the default shell of GNU (used by most Linux based OS), and therefore simply comes packaged as part of GNU, while also having 20 years of development behind it making it stable and well rounded, it is simply the best all rounder, meeting the needs of all but the most advanced users.

For more, read Why is bash standard on Linux? (the same question on Unix & Linux).

Just to add a bit more to this, there are many other shells to try, if you are interested, here's a few from this answer:

• Zsh has more advanced interactive facilities, but a few quirks when it comes to scripting (less so now than back in the days). In the early to mid-1990s when Linux was in its infancy, zsh was virtually unknown.

• Ksh was the de facto standard on commercial unices since the mid-1980s, but it was proprietary software until 2000, so not an option on Linux. Also, ksh had subpar command line editing capabilities, compared with bash.

• Pdksh, a free clone of ksh, would have been an option, but it was not well-known and had poor command line edition capabilities. (Pdksh is no longer a very active project, even though it's still used in some BSDs, now that ATT ksh is free.)

• Some distributions install an ash variant as /bin/sh. Ash (by which I mean any of the loose family of shells called ash) is designed to be small and fast, with no interactive features (it's only for editing scripts). The ash revival is relatively recent; in the 1990s the existing variants lacked a lot of features.

• Tcsh was the most advanced interactive shell until zsh came along, but it's incompatible with sh and not so good with scripting.

Solution 2:

The Bourne Shell (sh back in the day) of the AT&T branch of Unix was improved upon and superceded by the Korn Shell, ksh. ksh also came out of AT&T Bell Labs and was not GPL (current version is Eclipse Public License). The C-shell, csh came out of the Berkeley version of Unix and was also not GPL (BSD license) and also used different syntax than sh. The Z-shell, zsh is an improvement on sh but not GPL (MIT-like license). Bash was an improvement on sh, used the GPL and from GNU. Just on license alone Bash would have probably been the choice for a GPL operating system. Particularly with a shell being a core part of a distro.

But Bash was also a GNU project, giving it, I think, more active development and making contributions easier than a legacy product out of Berkeley Unix or AT&T Unix. A very good case could be made that zsh is and has been a better shell than Bash, but not enough so to overcome it's different license and non-GNU project status.

Back when Linux distros were first appearing and choosing their default shell (early to mid-90s), there was no github (2008) or even a SourceForge (1999). At that point, I think GNU projects had a real advantage over non-GNU projects in getting noticed and drawing and including new developers. So distros could look at Z-shell as better, but also expect that Bash would be getting good support and maintenance going forward, and also have more features added to it, allowing it to catch up to zsh.

Now that Bash has had years of default status, it's become a defacto standard, with books written about it. There is one book that covers both Bash and Z-shell, but no book that covers it exclusively, while there are multiple that do so for Bash.

And at this point, if distros were to change the default for upgrades of an existing system, it would break setups as some of initialization files have different names (e.g. .bashrc versus .zshrc) and the content of the files may have incompatible syntax. So they would be very reluctant to do that, leaving new downloads to have zsh as the default and upgrades to have bash. Two different defaults for the same distro is something they probably don't want to have to support and users/companies also don't want to deal with as well.

Solution 3:

The Unix shell languages are all ugly. Some particularly (csh), some maybe a bit less (ksh? I don't know actually), but really when it comes to aspects like readability and rigidness for big projects, none of them can get close to well-designed general purpose languages such as Python, C# or Haskell. So, when you want something solid, you will never choose any of the shell flavours at all.

You do choose them when you want to quickly get simple stuff done. For this, you need:

• Concise syntax, and enough consistency so you can actually memorise it (it's hard to look up shorthand operators). It matters a lot if your shell is installed everywhere, because you really rather wouldn't memorise more than one of these kludge monsters.
• Good interactive features, so you can hack right into the terminal and get stuff working without having to switch between multiple script files.
• The ability to grab any script snippet from anywhere and have it just work. sh compatibility is a big plus here, and once again the more popular the better.

So you see, popularity is rather a bigger point in these shell languages than it is for general-purpose languages. Hence even if ksh is a bit “better” as a language in itself, there is not really so much advatage in using it if bash is just a bit more popular (which it was, in the relevant sector, since it was first chosen as the default for GNU).

The people who do make the switch are deliberate about it and experienced enough to easily handle switching to their favourite shell. OTOH, a rookie who's forced to work with a less popular shell will be quickly confused if they ask the internet for something and it doesn't work. Hence, any distro that's not only aimed at Unix veterans takes quite some risk if it makes anything but bash the standard, a step from which relatively few people would benefit (and only a little).

Solution 4:

1. It was there when it was needed
2. It has enough eye candy that beginning users can spend a week customizing their prompt.
3. The common use cases it is good enough (the most common being start a single command)
4. Where it is not good enough perl, python and lua can take up the slack.
5. perl makes a terrible interactive shell
6. although fish, ksh or zsh may theoretically be a better shell there is not enough of an improvement for me to bother when perl works so well or portability is an issue so I'm targeting dash anyway.