38

Why is bash the default shell in most OSes (Ubuntu, Fedora, OSX, etc.)? Why is it that a lot of advanced users mostly use zsh? If it is that good, why is it not the default?

I use both I don't see a difference for all my tasks are simple :)

  • 5
    Everything is a Gaussian curve: if it's true that most advanced users use ksh, then it's also true that most people use a different shell, and this in itself would explain why ksh is not the default shell. However I don't think that's the reason, let's wait for some killer answer that I'm sure this question will receive. – kos Jun 20 '15 at 20:07
  • 1
    Actually, I believe ubuntu uses dash as default shell... – Bakuriu Jun 21 '15 at 11:22
  • 1
    This has a good answer, I vote we leave it open. – Seth Jun 25 '15 at 1:59
33

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.

  • 1
    When you copy-paste things from elsewhere, you're supposed to clearly indicate that this is the case. – muru Jun 20 '15 at 20:44
  • 1
    @muru I did provide the link to the original post, but I see your point that it could of been clearer. – Mark Kirby Jun 20 '15 at 20:47
  • What is the source of your comment that zsh has a few quirks with regard to scripting? Never mind, I see that the comment came from elsewhere. – Scooter Jun 21 '15 at 4:13
  • 1
    You also have fish (which is incompatible with the sh syntax). – Léo Lam Jun 21 '15 at 6:49
  • 1
    Would you explain what was deficient about the Korn shell editing? It always seemed to work OK for me, even in the 90s. – Jonathan Leffler Jun 21 '15 at 8:28
8

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.

1

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).

  • 1
    Any language that cares about amounts of whitespace is not "well designed", but I agree that popularity is the key. – Nagora Jun 21 '15 at 16:37
  • 1
    @Nagora: opinions vary. FWIW, you can always write Haskell with braces and semicolons instead of whitespace, and I suppose Python has similar fallbacks. Only, nobody does this, because indentation-based grouping is just amazing for readability. – leftaroundabout Jun 21 '15 at 20:01
1
  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.
0

"Critical Mass" is the main answer, IMO. Bash is not just for command line work, it's for scripting and there's a huge, huge number of Bash scripts out there. No matter how much better an alternative is now for interaction, the need to be able to just "plug and play" those scripts outweighs such advantages. As such, the only shell that can realistically unseat Bash now is one that is completely backwards compatible and the most likely candidate for that is...the next version of Bash.

  • 1
    You can use any and all bash scripts as is no matter what your default shell is. That is what the she-bang (#! /bin/bash) means at the top of the script. – Panther Jun 20 '15 at 22:35
  • 1
    @bodhi.zazen As long as the bash shell exists in the system. I've known at least a version of Solaris that doesn't include bash. – Tulains Córdova Jun 20 '15 at 23:37
  • @bodhi.zazen There's a mental cost in having to switch between two shells - one for interaction and one for scripting. It's generally not worth the bother. – Nagora Jun 21 '15 at 16:36
  • 1
    @Nagora What's the mental cost of running a script? – kos Jun 21 '15 at 17:00
  • @kos if you're literally just running scripts, none. If you have to maintain and adapt scripts then you need to keep in mind often quite small differences between the different underlying shells, in which case there is an ongoing metal cost and a context-switching cost when you do have to do some work in the "other" syntax. – Nagora Jun 25 '15 at 7:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.