Different Types of Shells in Linux Explained: Bash, sh, Zsh, Fish and More

A Linux shell is both a command interpreter and a programming language. It reads what you type, expands variables and wildcards, applies quoting rules, starts programs, connects commands into pipelines, manages foreground and background jobs, and runs scripts. Bash is the most practical starting point for general Linux use, a POSIX-oriented shell such as sh is the safer target for portable scripts, zsh is aimed at highly configurable interactive work, and fish prioritizes friendly defaults over Bash and POSIX syntax compatibility.

Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.

The important distinction is between the shell you use interactively at a terminal and the interpreter a script declares. You can use fish for your daily command line while running a script with Bash or /bin/sh. Choosing the right interpreter, rather than assuming that every shell accepts the same language, prevents many portability and startup problems.

#	Preview	Product	Price
1		The Linux Command Line, 3rd Edition: A Complete Introduction	$27.94	Buy on Amazon
2		The Linux Command Line, 2nd Edition: A Complete Introduction	$11.34	Buy on Amazon
3		Linux Command Line: A Simple Beginner’s Guide to Linux Commands and Terminal Basics	$1.99	Buy on Amazon
4		Linux Pocket Guide: Essential Commands	$19.75	Buy on Amazon
5		Linux Command Reference Guide: 500+ Essential Commands and Examples for Everyday Use (Rheinwerk...	$33.91	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

What a shell does in Linux

When you open a terminal, a shell usually starts as a user-space process. It displays a prompt, reads a command line, parses its syntax, performs expansions, and either executes a built-in operation or asks the operating system to start an external program. A command such as cat report.txt | grep error > errors.txt involves several shell responsibilities:

• recognizing the pipeline and redirection operators;
• expanding the filename and any variables or command substitutions;
• creating the pipe between the two programs;
• redirecting the second program’s output to a file; and
• tracking the processes as a foreground job.

Shells also provide programming constructs: variables, conditionals, loops, functions, exit statuses, and input/output redirection. A script is therefore a program interpreted by a particular shell language. The command names may look familiar across shells, but syntax for arrays, conditionals, quoting, globbing, functions, and startup configuration can differ substantially.

#1 Best Overall

Sale

The Linux Command Line, 3rd Edition: A Complete Introduction

$27.94

Buy on Amazon

Most shells have interactive and non-interactive modes. An interactive shell reads commands from a terminal and normally provides line editing, history, completion, and job control. A non-interactive shell reads a script or a command supplied by another program. Features intended to make typing pleasant are not a substitute for declaring the correct interpreter in a script.

The main Linux shell families

sh: the portability baseline

sh names the traditional Bourne shell interface and, in modern usage, commonly means a POSIX shell language. It is not necessarily one single executable. On one distribution, /bin/sh may point to a Bash-compatible implementation; on another, it may point to Dash or a different POSIX shell. That implementation detail matters when a script depends on behavior beyond the POSIX baseline.

Portable sh scripts favor simple variables, command substitution, functions, tests, loops, and redirections defined by the POSIX shell language. They avoid Bash arrays, extended conditional syntax, and other extensions unless the script explicitly chooses Bash. A shebang such as #!/bin/sh tells the operating system which interpreter the script expects; it does not magically convert Bash syntax into portable syntax.

Use sh when the script must run in a minimal recovery environment, across varied Unix systems, or under a distribution’s system-script policy. Still test the exact target shell: POSIX-like shells can differ in details such as shell variables and filename expansion.

Bash: the general-purpose default

Bash means “Bourne-Again SHell.” It is a reimplementation and extension of the historical Bourne shell, incorporating ideas from Korn and C shells. GNU describes it as intended to implement the IEEE POSIX Shell and Tools specification while adding interactive and programming improvements.

Those extensions make Bash a practical first shell for Linux learners. It is widely documented, appears in many tutorials, and is commonly available on Linux installations. Bash adds conveniences such as indexed and associative arrays, richer conditional expressions, shell options, programmable completion, and interactive history controls. These features are useful, but they create a boundary: a script using them must declare Bash rather than sh.

Rank #2

The Linux Command Line, 2nd Edition: A Complete Introduction

$11.34

Buy on Amazon

Use a Bash shebang when Bash syntax is intentional:

#!/usr/bin/env bash

Using /usr/bin/env bash asks the environment to locate Bash through PATH; an explicit path such as #!/bin/bash can be preferable when a system policy requires a fixed location. Whichever form you choose, make the declaration agree with the deployment environment and test the script with that interpreter.

Dash: a small script-oriented shell

Dash is the Debian Almquist shell. Debian documentation labels it “good for shell script” and uses it as a small, fast, POSIX-oriented interpreter for scripts. Its compact design is useful where startup overhead and a limited language surface matter, but it is not intended to provide Bash’s interactive experience or extensions.

A common failure occurs when a script is run with sh on a system whose /bin/sh resolves to Dash, even though the author tested it with Bash. Bash-specific constructs such as [[ ... ]], arrays, or certain parameter expansions then produce syntax errors. The fix is not to change commands at random: either rewrite the script to the POSIX language and keep #!/bin/sh, or declare Bash and require Bash explicitly.

Korn-shell variants: ksh and mksh

The Korn-shell family occupies a middle ground between historical Unix scripting and modern interactive features. Traditional ksh has a long enterprise-Unix heritage, while mksh is a maintained Korn-shell version found on some systems. Korn-style syntax and behavior can be valuable when maintaining existing software, but the command available on one operating system may not be the same dialect available on another.

Do not assume that a script written for one Korn-shell implementation is identical to a script written for another. Declare the intended interpreter, consult that system’s manual page, and test language features such as arrays, arithmetic, and pattern expansion on every target platform.

Rank #3

Linux Command Line: A Simple Beginner’s Guide to Linux Commands and Terminal Basics

$1.99

Buy on Amazon

Zsh: powerful interactive customization

Zsh most closely resembles the Korn shell among the standard shells. It is known for extensive completion, sophisticated globbing, configurable prompts, and a large set of interactive options. These capabilities make it attractive when the terminal itself is a major productivity tool.

Zsh can emulate POSIX shells, but its default mode is not POSIX-compatible. That distinction is essential. A command line that works in zsh’s default language is not automatically valid in sh, and a script with a #!/bin/zsh shebang should be treated as zsh code. POSIX emulation is a deliberate mode that must be configured; it is not the shell’s normal behavior.

Choose zsh for interactive customization when you are prepared to maintain its configuration and to keep zsh-specific scripts separate from portable scripts. If a project specifies Bash or POSIX shell syntax, run it with the specified interpreter instead of relying on your login shell.

Fish: friendly by design, deliberately different

Fish is designed around an immediately useful interactive experience. Its official introduction highlights syntax highlighting, autosuggestions, and completion interfaces, and its defaults are intended to be useful without an elaborate configuration. This can make everyday command entry easier, especially for users who value visible feedback and discoverable completion.

Fish has its own language. Its design follows POSIX where doing so does not conflict with its user-focused goals, but that is a design objective rather than a claim of full POSIX syntax compatibility. Bash scripts, POSIX scripts, and fish scripts should therefore be treated as different programs unless they have been deliberately written for a compatible interpreter.

For example, a Bash script that begins with #!/usr/bin/env bash should be executed with Bash even if fish is the user’s interactive shell. Conversely, a fish script needs a fish shebang and fish syntax. Keep interactive preference and script portability as separate decisions.

Rank #4

Sale

Linux Pocket Guide: Essential Commands

$19.75

Buy on Amazon

Interactive shell versus script interpreter

Your login shell is the shell configured for your account, often used when a login session starts. The currently running shell is the process that is handling your present prompt. They can differ: you might log in to Bash and then start zsh, or open a terminal that launches a shell selected by the terminal or desktop configuration.

A script’s shebang is a third, independent choice. It controls the interpreter used when the executable script is launched directly. This separation explains why changing your preferred terminal shell does not rewrite existing scripts and why a script should never rely on whichever shell happens to be interactive at the time.

How to check which shell you are using

Use both of these checks because they answer different questions:

1. Print the configured login-shell value:

   printf '%sn' "$SHELL"

   This environment variable commonly reflects the account’s configured login shell, but it may not identify the process currently interpreting your commands.

2. Inspect the current shell process:

   ps -p $$ -o comm=

   The special parameter $$ identifies the current shell process. The command prints the process name for that shell.

If the values differ, you have likely started one shell from inside another or inherited an environment prepared by a parent process. To understand shell-specific behavior, consult the relevant manual page, such as man bash, man dash, man zsh, or man fish, rather than inferring compatibility from the prompt alone.

How to choose a shell

For portable scripts

Start with the POSIX language and declare #!/bin/sh when that is sufficient for the target systems. Avoid extensions, then test under the actual /bin/sh implementation on each supported distribution. If the script needs Bash features, use a Bash shebang instead of calling it portable.

For learning Linux and general automation

Bash is a sensible starting point because its documentation and tutorial ecosystem are extensive and its extensions are useful for many administrative tasks. Learn which constructs are Bash-only so that examples copied into a system script do not silently create a portability dependency.

Best Value

Sale

Linux Command Reference Guide: 500+ Essential Commands and Examples for Everyday Use (Rheinwerk Computing)

$33.91

Buy on Amazon

For an enhanced interactive prompt

Choose zsh when advanced completion, globbing, and deep configuration are priorities. Choose fish when highlighting, autosuggestions, and useful defaults matter more than preserving Bash syntax. Neither choice changes the interpreter declared by an existing script.

For boot and system scripts

Follow the target distribution’s policy and the interpreter required by the script. Never assume that /bin/sh means Bash. A system script that relies on a particular extension must name that shell explicitly and ensure it is installed in the deployment environment.

Moving scripts between shells safely

Cross-shell migration requires more than replacing the first line. Check each language area independently:

• Quoting: verify how spaces, empty values, backslashes, and nested quotes are handled.
• Arrays: Bash and some Korn variants provide array features that are absent from portable sh.
• Command substitution: test nested substitutions and how their output is split or preserved.
• Globbing: shells differ in options, unmatched patterns, recursive patterns, and expansion timing.
• Conditionals: replace Bash-specific tests with POSIX forms when targeting sh.
• Startup files: interactive initialization and non-interactive script environments are not interchangeable.
• Exit status and pipelines: confirm how failures are propagated and how the target shell handles pipeline status.

Run the migrated script with the declared interpreter, not merely by typing its filename from your preferred shell. Test empty arguments, filenames containing spaces, missing files, failed commands, and paths containing wildcard characters. These cases expose language differences that a successful “happy path” run can hide.

Common mistakes and their fixes

Assuming every sh is Bash

Symptom: a script works when invoked with Bash but fails when launched through /bin/sh. Fix: either remove Bash extensions and test as POSIX shell code, or change the shebang to Bash and document that requirement.

Using the login-shell variable as proof

Symptom: $SHELL reports one shell while behavior matches another. Fix: compare it with ps -p $$ -o comm=; the first value describes configuration, while the second identifies the current process.

Running a script from the wrong shell

Symptom: a fish or Bash script produces syntax errors when pasted into another shell. Fix: execute the file with its declared interpreter and preserve the shebang when making it executable.

Confusing similar commands with compatible languages

Symptom: basic commands work during migration, but loops, arrays, completion settings, or wildcard behavior breaks later. Fix: review syntax and expansion rules feature by feature and read the target shell’s manual.

Quick Recap

SaleBestseller No. 1

The Linux Command Line, 3rd Edition: A Complete Introduction

$27.94

Bestseller No. 2

The Linux Command Line, 2nd Edition: A Complete Introduction

$11.34

Bestseller No. 3

Linux Command Line: A Simple Beginner’s Guide to Linux Commands and Terminal Basics

$1.99

SaleBestseller No. 4

Linux Pocket Guide: Essential Commands

$19.75

SaleBestseller No. 5

Linux Command Reference Guide: 500+ Essential Commands and Examples for Everyday Use (Rheinwerk Computing)

$33.91

Practical decision checklist

• Need maximum script portability? Target POSIX sh and verify the actual implementation.
• Need a broadly documented Linux shell with useful extensions? Use Bash and declare it explicitly for scripts.
• Need advanced interactive completion and globbing? Evaluate zsh, remembering that its default mode is not POSIX-compatible.
• Need syntax highlighting, autosuggestions, and no-required-configuration usability? Evaluate fish, while keeping Bash and POSIX scripts separate.
• Maintaining existing Unix software? Identify whether it expects Bash, a Korn variant, Dash, or another interpreter before editing it.
• Unsure what is running? Check both $SHELL and the process command, then consult the relevant man page.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.