Most people who use Linux for a while end up assuming "shell" just means bash, since that's usually what's running the first time they open a terminal. But bash is only one member of a much larger family of shells, and depending on what you're doing, a different one might genuinely serve you better. This article breaks down the shell types you're most likely to run into on a Linux system, what each one is actually built for, and how to check or change which one you're running.
What a shell actually does
A shell is a command line interpreter. It's the program that sits between you and the operating system, reading the commands you type, figuring out what you mean, and asking the kernel to do the actual work. When you type ls or cd /var/log, you're not talking to the operating system directly; you're talking to the shell, and the shell translates that into system calls the kernel understands.
"A shell" is a concept, not a single piece of software, similar to how "a browser" describes a category that includes Chrome, Firefox, and Safari. Each one renders web pages, but they're built differently and behave differently in the details. Shells work the same way: each one interprets commands, but the syntax, features, and behavior can vary quite a bit from one to the next, which is exactly why it's worth knowing which one you're actually using.
The main types of shells in Linux
sh (Bourne shell / POSIX shell)
sh refers to the original Bourne shell, written by Stephen Bourne at Bell Labs in the 1970s, and it's the shell the POSIX standard is modeled after. On most modern Linux systems, /bin/sh isn't literally the historical Bourne shell anymore; it's usually a symlink to a smaller, POSIX-compliant shell like dash. The name stuck around as shorthand for "the basic, portable shell," and scripts that start with #!/bin/sh are generally expected to avoid any syntax that isn't part of the POSIX spec.
bash (Bourne Again Shell)
Bash, short for "Bourne Again Shell," is the shell most Linux distributions have shipped as the default for decades, which is a big part of why "shell" and "bash" get used interchangeably. It was written by Brian Fox for the GNU Project as a free replacement for the Bourne shell, and according to the official GNU Bash manual, it implements the IEEE POSIX shell specification while adding its own extensions, things like command history, tab completion, associative arrays, and more capable scripting logic than the original Bourne shell offered. If you want a deeper look at bash specifically, we've covered that in more detail in our piece on what bash actually is and how it works.
dash (Debian Almquist Shell)
Dash is a minimal, fast shell that many Debian-based distributions use as the actual target of the /bin/sh symlink, precisely because it starts up faster and uses fewer resources than bash. It sticks closely to POSIX and skips most of bash's interactive conveniences, which makes it a good fit for running system startup scripts where speed matters more than features.
zsh (Z shell)
Zsh builds on bash-like syntax and adds a lot of quality-of-life features on top: richer autocompletion, easier theming, and a large ecosystem of frameworks like Oh My Zsh for customizing it further. It's been the default interactive shell on macOS since Catalina, and plenty of Linux users switch to it for the same reasons, even though bash usually remains available underneath for scripts.
ksh (Korn shell)
The Korn shell was developed at Bell Labs in the early 1980s and introduced several features that later showed up in bash, including command history and improved scripting constructs. It's less common as a default shell today, but it still turns up in some enterprise Unix environments and older scripts that were written before bash became the standard.
csh and tcsh (C shell and its successor)
The C shell uses syntax that looks more like the C programming language, which some users find more intuitive and others find awkward for scripting. Tcsh is an enhanced version with better interactive features like command completion. Neither is common as a default shell on Linux today, but they still show up on some BSD systems and in certain legacy scripts.
fish (friendly interactive shell)
Fish is built specifically for interactive use, with syntax highlighting, autosuggestions, and sane defaults out of the box rather than requiring a bunch of configuration to get there. The tradeoff is that it's less POSIX-compliant than the others, so scripts written for bash or sh often need adjustments to run correctly under fish.
None of these are "wrong" choices; they trade off differently between speed, interactive features, compatibility, and how closely they stick to the POSIX standard. A sysadmin writing a script meant to run on almost any Unix-like machine might deliberately target sh for portability, while a developer who lives in the terminal all day might prefer zsh or fish for the day-to-day conveniences.
Why the shell you use actually matters
This isn't just semantics. If you write a script starting with #!/bin/bash and it uses bash-specific features like arrays or [[ ]] conditional syntax, that script can break or behave unexpectedly if it's actually executed by a different shell, such as dash, which is what sh points to on many Debian-based systems. This is a genuinely common source of "it worked on my machine" bugs when moving scripts between servers or containers.
It also matters when you're troubleshooting. If a command behaves strangely, the shell you're in, along with its configuration files and environment variables, is one of the first things worth checking, well before you start suspecting the operating system itself. On a server, the shell your account launches into is often set up during initial provisioning, alongside other system-level settings that get configured when the machine boots up.
How to check which shell you're using
Before troubleshooting anything shell-related, it helps to know what you're actually running. There are a couple of quick ways to check.
The simplest is to run:
echo $SHELL
This prints the path to your default login shell, something like /bin/bash or /usr/bin/zsh. Keep in mind this shows your configured default, not necessarily the shell process currently running if you've launched something else on top of it.
For the shell that's actually active right now, try:
ps -p $$
This shows the process running in your current session, which is more reliable if you've switched shells temporarily. You can also check /etc/passwd for your account's assigned login shell, which is what runs by default whenever you log in.
How to switch shells
If you decide you want to try a different shell, either just for a session or as your permanent default, both are straightforward.
To try a shell temporarily, just type its name and hit enter, like running zsh or fish directly from your current session. This starts a new shell process on top of your existing one, and typing exit drops you back to where you started.
To change your default login shell permanently, use the chsh command:
chsh -s /usr/bin/zsh
You'll need to log out and back in for the change to take effect, and the path needs to match wherever that shell is actually installed on your system, which you can confirm with which zsh or by checking /etc/shells for the list of shells your system recognizes as valid options.
At a glance: how these shells compare
| Shell | Known for | Best fit for |
|---|---|---|
| sh | The original POSIX-standard shell | Scripts that need to run portably across almost any Unix-like system |
| bash | The default interactive shell on most Linux distributions | General day-to-day use and scripts that need broad compatibility |
| dash | A minimal, fast, POSIX-compliant shell | Running system startup scripts where speed matters more than features |
| zsh | Bash-like syntax with richer autocompletion and theming | Interactive daily use, especially with frameworks like Oh My Zsh |
| ksh | An early shell that influenced many of bash's features | Enterprise or legacy Unix environments |
| csh/tcsh | C-like syntax, with tcsh adding better interactive features | Legacy scripts and some BSD systems |
| fish | Syntax highlighting and autosuggestions out of the box | Interactive use, though less POSIX-compliant for scripting |
Conclusion
Bash gets most of the attention, but it's one entry in a much wider family of Linux shells, each built with different priorities around speed, portability, or interactive convenience. Knowing the differences between sh, bash, dash, zsh, ksh, csh, and fish helps you pick the right one for the job and troubleshoot faster when a script behaves differently than you expect.
Thanks for reading! If you're looking for reliable infrastructure, xTom provides enterprise-grade dedicated servers and colocation services, while V.PS offers scalable, production-ready NVMe-powered VPS hosting perfect for any workload. You can also explore IP transit, shared hosting, and general IT services for whatever your infrastructure needs.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
Frequently asked questions about types of shells in Linux
What's the difference between a shell and a terminal?
They're not the same thing. The terminal (or terminal emulator) is the window or application that displays text and passes your keystrokes along; the shell is the program running inside it that actually interprets your commands. You could open the same terminal application and run bash, zsh, or fish inside it; the terminal itself doesn't change.
What shell does Linux use by default?
Most Linux distributions, including Ubuntu, Debian, and Fedora, use bash as the default interactive shell for user accounts, though system scripts often run under a lighter shell like dash for speed. It's worth checking your specific distribution's defaults, since some, like Kali or certain Arch-based setups, ship with zsh instead.
Which Linux shell should I use?
It depends on what you're optimizing for. Bash is the safest default for compatibility since it's available on nearly every Linux and Unix system you'll connect to, which matters a lot for scripts. Zsh or fish are worth considering if you spend a lot of time typing commands interactively and want more built-in conveniences, since neither is guaranteed to be present on a server you don't control.
Can I have multiple shells installed on the same system?
Yes, and it's common. Having bash, zsh, and fish all installed at once causes no conflicts; you simply choose which one to launch interactively or set as your default login shell with chsh. Scripts also specify their own interpreter via the shebang line at the top of the file, so different scripts on the same system can rely on different shells without issue.
Is zsh better than bash?
"Better" depends on what you're optimizing for. Zsh offers more built-in interactive features like richer autocompletion and easier customization through frameworks like Oh My Zsh, while bash has broader compatibility and is nearly guaranteed to be present on any Linux or Unix system you connect to. For scripting that needs to run reliably across many machines, bash (or plain POSIX sh) is usually the safer bet.
