Unix shell

A Unix shell is the command-line interpreter of Unix-like operating systems, including Linux, that reads commands from a user or a script, expands and parses them, and starts programs as processes. It is both an interactive interface and a complete programming language for automation, which is why it remains central to Linux administration decades after its origin.

In the shell & terminal vocabulary, the shell is distinct from the terminal. The terminal or terminal emulator displays text and passes keystrokes; the shell is the program running inside it that interprets them. Bash, Zsh, dash and fish are all shells, and any of them can run in the same terminal window.

How the shell processes a command line

Every command line passes through a fixed sequence of steps before anything runs. Understanding this order of expansions explains most surprising shell behavior, especially with spaces and special characters.

1. Tokenizing: the line is split into words and operators such as |, > and &&, respecting quotes.
2. Expansions: brace, tilde, parameter and variable, command substitution and arithmetic expansion are applied.
3. Word splitting: unquoted expansion results are split again on the characters in IFS.
4. Pathname expansion: unquoted patterns such as *.log are replaced with matching file names.
5. Redirection setup: input and output are connected to files, pipes or descriptors.
6. Execution: a builtin or function runs inside the shell; an external program is found through PATH and started with fork and exec.

Because word splitting and globbing happen after variable expansion, an unquoted $file containing a space becomes two arguments. The standard defensive habit is to quote every expansion, writing "$file", unless splitting is explicitly intended.

Core features: pipes, redirection and job control

The shell’s lasting power comes from composition: small programs that each do one job, connected by the shell. The pipe passes the standard output of one process to the standard input of the next, while input/output redirection connects streams to files.

When a process finishes, the shell records its exit status in the special parameter $?: zero indicates success, and a nonzero value up to 255 reports a failure or a specific condition. Conditionals, &&, || and the set -e option all build on this convention. Job control with jobs, fg, bg and Ctrl+Z lets an interactive user suspend and resume processes, while terminal multiplexers such as tmux keep sessions alive after disconnection.

Major Unix shells compared

Unix shells share a common ancestry but differ in standards compliance, scripting features and interactive comfort. The POSIX standard defines a portable core language that /bin/sh must implement.

The practical consequence is portability. A script with #!/bin/sh must avoid Bash-only features, called bashisms, because on Debian-based systems it runs under dash. A script that needs arrays or [[ ]] tests should declare #!/bin/bash or #!/usr/bin/env bash explicitly.

Shell environment and startup files

A shell runs with an environment: exported environment variables such as PATH, HOME and LANG that child processes inherit, plus shell-local variables, functions and shell aliases that do not leave the current shell. The PATH variable decides which program a bare command name runs.

Startup behavior depends on the shell mode. A login shell reads system and user profile files, while an interactive non-login shell reads files such as ~/.bashrc or ~/.zshrc. Non-interactive script shells read neither by default, which is why a command that works in a terminal can fail in cron or systemd, where PATH is minimal and aliases do not exist.

Pitfalls and safe scripting practice

Shell scripts are quick to write and easy to get subtly wrong. Experienced administrators follow a few defensive rules that prevent most failures.

• Quote variables to avoid word splitting and unintended glob expansion.
• Use strict mode such as set -euo pipefail in Bash, while understanding its edge cases.
• Never parse `ls` output; iterate over globs or use find with -print0 instead.
• Check scripts with ShellCheck, which catches quoting errors and portability problems.
• Avoid `eval` on untrusted input, which turns data into code and enables injection.
• Move complex logic elsewhere: beyond a few hundred lines, Python or another language is usually easier to maintain.

Tools such as grep, sed and awk are separate programs, not shell features, but they are the shell’s natural partners for text processing in pipelines. Knowing where the shell ends and an external tool begins helps when a pipeline behaves differently across systems.

The short version

A Unix shell is like a skilled assistant who takes typed instructions and carries them out. You write a short sentence, such as list these files or copy that folder, and the assistant finds the right tool and runs it.

Its real strength is chaining tools together: the output of one task becomes the input of the next, like an assembly line. Once a sequence works, it can be saved as a script and repeated automatically, which saves hours of manual work.

Where it makes a difference

A system administrator at a web hosting company needs to find which client sites caused the most server errors overnight across 40 web servers. Instead of opening log files one by one, she runs a single pipeline over SSH on each server that filters access logs for status 500, extracts the host name with awk, counts occurrences with sort | uniq -c and keeps the top ten.

She saves the loop as a Bash script with strict mode, quoted variables and a check with ShellCheck, then schedules it with cron to email a summary every morning. A task that once took about an hour of manual searching now finishes in under a minute, and the team sees problem sites before customers report them.