Why aren’t new terminals that use another language? It seems so antiquated getting errors for not writing the functions in the correct order among other things.

Aiwendil has a good answer but I’d just like to add this nitpick (also @kromonos@fapsi.be ): bash and fish aren’t terminals, they’re shells


I never said something else. So there is no need to impute a “mistake” to me.

Edit: OK, my fault. I saw the confusion. But it must also be said that to make such a precise distinction is to quibble over little things.
An end user sees “terminal” and not “shell” in the menu.


I guess a mixture of POSIX compatibility, backward compatibility and non-interactive shell use-cases.

Being somewhat POSIX compatible offers a way to write scripts that work on many systems independent of the actual shell implementation (bash, dash, zsh…). But this means major overhauls of the shell “language” are out of question…

Backward compatibility gets important for things that ignored the first point and used features only available in bash. Given that bash is the default for 30 years for linux now there are probably plenty of examples.

And while bash is not the smallest shell it is also not the largest one…and rather configurable at compile-time when it comes to supported features. This makes it a viable option as “shell-script” interpreter for systems that hardly have any interactive shell usage. It’s not a completely bare-bone shell so you get a bit of “comfort” for scripts but you can remove unnecessary things like interactive command line editing with lib readline…I can imagine some embedded systems find uses for such a shell.

And it’s not that there aren’t alternatives…Microsoft’s Powershell is probably the most successful one “recently”. But changing all existing “workflows” from a text-based one to an object based one is not a trivial task…and in addition you run in new problems with any new shell design (For example I really dislike the overly verbose interactive useage of powershell but that’s rather subjective)


The other answers are great. But consider the following, as well.

All the mainstream package managers rely on POSIX-ish shell interpreters. Arch Linux PKGBUILD files require bash syntax, specifically.

RPM and .deb package formats literally embed shell scripts to perform pre- and post-installation tasks. They treat these scripts like hooks.

For instance, a common task would be to create requires users and directories for a program. Quite literally something like mkdir -p /var/lib/myprogram.

I‘d say one of the primary reasons is compatibility. There is a lot of software for the Unix world that expects some kind of environment that behaves similarly to bash - imagine for instance of the bazillion of startup scripts that exist around certain tools. You’d have to be 100% backwards compatible with the bash language if you were to invent something to replace it, otherwise all those things wouldn’t work in your shell.


Why not use POSIX shell?

Shell scripts usually expect something POSIX-compatible, but you don’t have to stick with the default for user-facing tasks. Fish, zsh, powershell, and a whole bunch of niche shells are available to try. Anyhow, in the broad context of Unix default installations bash has a lot of competition.

On several unix-like Oses more than one shell is used depending on context. A great interactive shell with loads of features may be overkill if you just want to execute a script. Some OSes don’t use bash at all.

FreeBSD uses tcsh as its default root shell, but it uses ash shell (sh, it started as a clone of Bourne shell) for users and as the interpreter for system commands. This combo confused me at first and led me down a shell research rabbit-hole. ash is a stripped down shell that aims to be small, fast, and largely POSIX-compliant.

In Ubuntu, bash is the default shell for interactive terminals, but dash is used to execute scripts by default. I think that dash started as a debian port of the ash shell.

MacOS and Kali both use zsh as the default shell. I don’t know what they use by default to run scripts, but I would guess that it isn’t bash.

Also, something that took me a while to figure out is that Bourne-Again Shell (bash) is not the same as Bourne Shell (sh). Further, sh does not always denote Bourne shell, but could be ash or dash or something else.

Why fix what isn’t broken?


It runs regular shell scripts, and is made by the GNU project.

I still depend on so many Bash scripts.


As a developer, I really love bash. I can run commands like “ls -l {1…3}_foo” which would list me 1_foo, 2_foo and 3_foo but not 4_foo. This works with almost any command.
Or running subcommands in commands. OK, this is also possible in other terminals like fish.

While it possible, the syntax is different. For sub commands Bash uses $() while Fish only uses (). Also. The double bang does not exist in fish. I don’t know why and don’t know of an alternative in fish.

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word “Linux” in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.


  • Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
  • No misinformation
  • No NSFW content
  • No hate speech, bigotry, etc

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

  • 0 users online
  • 3 users / day
  • 5 users / week
  • 74 users / month
  • 461 users / 6 months
  • 2 subscribers
  • 1.44K Posts
  • Modlog