Every other article I write about a specific Linux command quietly assumes you already understand things like why quotes change behavior, what 2>&1 actually does, or why && sometimes runs the next command and sometimes doesn’t. I never got a clean, single explanation of all of this when I started out — I picked it up piecemeal, command by command, over years, and got burned by a few of the sharper edges along the way. This article is the one I wish existed back then: the actual grammar of a shell command line, explained properly, with everything tested and shown running.
The Anatomy of a Command
At its simplest, a shell command line follows this shape:
command [options] [arguments]
- command — the program or shell builtin to run
- options (or “flags”) — modify the command’s behavior, usually prefixed with
-or-- - arguments — the actual data the command operates on (filenames, text, etc.)
$ ls -la /var/log
Here ls is the command, -la is a combined set of short options, and /var/log is the argument.
Short Options vs. Long Options
Most well-behaved Linux tools support two styles of option:
- Short options — single dash, single letter, often combinable:
-l,-a, or combined as-la - Long options — double dash, full word, not combinable:
--all,--human-readable
$ ls -l -a
$ ls -la # equivalent — short options can be bundled together
$ ls --all --long # equivalent, using long form
Long options exist mainly for readability in scripts — tar --extract --verbose --file reads far more clearly six months later than tar -xvf, even though they’re functionally identical. I mix both depending on context: short forms interactively for speed, long forms in scripts meant to be read and maintained by other people.
Options That Take a Value
Some options require an accompanying value, and there are two accepted syntaxes:
$ grep -m 3 pattern file.txt # space-separated
$ grep -m3 pattern file.txt # attached directly (short option only)
$ tar --file=archive.tar ... # long option uses = for its value
$ tar --file archive.tar ... # space also works for most long options
The Double-Dash Terminator: --
This one is underused and genuinely important for safety. -- tells a command “everything after this point is a positional argument, not an option,” even if it starts with a dash. This matters enormously when a filename itself begins with a hyphen:
$ touch -- -myfile.txt
$ ls -- -myfile.txt
-myfile.txt
Without --, ls -myfile.txt would try to interpret -myfile.txt as a cluster of option flags and fail or behave unexpectedly. I make a habit of using -- in scripts whenever a variable is being passed as an argument and its content isn’t fully controlled, precisely to avoid this class of bug — it’s the same defensive habit I mentioned in the wildcards article regarding files named things like -rf.
Quoting: Why It Changes Everything
Quoting controls whether the shell performs expansions (variables, globs, command substitution) on a piece of text before passing it to a command. There are three quoting styles, and they behave differently:
Single Quotes — Nothing Is Expanded
$ echo 'Hello, $name'
Hello, $name
Inside single quotes, everything is completely literal. No variable expansion, no command substitution, no glob expansion. This is what you want for literal strings, regex patterns, or anything you specifically don’t want the shell touching.
Double Quotes — Variables and Command Substitution Still Expand
$ name="World"
$ echo "Hello, $name"
Hello, World
Double quotes suppress word-splitting and glob expansion, but still allow $variable, `command` / $(command), and \ escapes to expand. This is the quoting style I default to for almost everything — it prevents most of the classic bugs (a variable containing spaces or a glob character being accidentally expanded) while still letting you interpolate values.
No Quotes — Full Expansion, Including Word-Splitting
$ files="report one.txt report two.txt"
$ ls $files # BROKEN: word-splits into 4 arguments, not 2 filenames
$ ls "$files" # correct if $files is meant to be one path — but here it's two
Unquoted variables are word-split on whitespace and glob-expanded, which is almost never what you actually want when the value might contain spaces. My rule, without exception: quote every variable expansion unless you have a specific, deliberate reason not to. "$var" should be your reflex, not an afterthought.
Command Substitution
Command substitution runs a command and replaces it with that command’s output, letting you embed the result of one command inside another:
$ echo "Today is $(date +%A)"
Today is Friday
The modern syntax is $(command). You’ll also see the older backtick syntax `command` in legacy scripts — functionally similar for simple cases, but $(...) nests far more cleanly:
$ echo $(echo $(echo "nested works fine"))
nested works fine
Nesting backticks requires awkward escaping ( `echo \`echo inner\ “) that $(...) avoids entirely, which is why virtually all modern style guides recommend $(...) exclusively.
Pipes: Connecting Commands Together
The pipe operator | connects one command’s standard output directly to the next command’s standard input, without any intermediate file:
$ printf 'b\na\nc\n' | sort | head -1
a
Each command in the pipeline runs as its own process, all started roughly simultaneously, with the shell wiring their input/output streams together. This is the foundational idiom behind an enormous amount of everyday Linux work — filtering, transforming, and summarizing data by chaining small, focused tools rather than writing one large program to do everything.
Redirection: Controlling Where Output Goes
Every process has (at minimum) three standard streams:
| Stream | Number | Purpose |
|---|---|---|
| stdin | 0 | Input the program reads |
| stdout | 1 | Normal output |
| stderr | 2 | Error/diagnostic output |
Basic Output Redirection
$ echo "test" > out.txt
$ cat out.txt
test
> overwrites the target file entirely. >> appends instead:
$ echo "append" >> out.txt
$ cat out.txt
test
append
Redirecting Standard Error Specifically
$ ls /nonexistent 2> err.txt
$ cat err.txt
ls: cannot access '/nonexistent': No such file or directory
2> targets file descriptor 2 (stderr) specifically, leaving stdout untouched — genuinely useful for separating real errors from normal output in scripts that need to react differently to each.
Combining stdout and stderr Into One Stream
$ ls /nonexistent file1.txt > combined.txt 2>&1
$ cat combined.txt
ls: cannot access '/nonexistent': No such file or directory
ls: cannot access 'file1.txt': No such file or directory
The order here matters and trips people up constantly: 2>&1 means “make file descriptor 2 point to wherever file descriptor 1 currently points.” Since the > redirection to combined.txt happens first in this line, by the time 2>&1 executes, stdout is already pointed at combined.txt, so stderr joins it there too. Written the other way around (2>&1 > combined.txt), stderr would still go to the terminal, because it copies stdout’s current target (the terminal) before stdout gets redirected to the file. Order of redirections is evaluated strictly left to right.
Discarding Output Entirely
$ some_noisy_command > /dev/null 2>&1
/dev/null is a special device file that silently discards anything written to it — the standard way to suppress output you genuinely don’t care about, commonly used in cron jobs and scripts where you only want to know about failure, detected via exit status, not the routine chatter of successful runs.
Command Chaining Operators
| Operator | Meaning |
|---|---|
; | Run the next command regardless of the previous command’s success or failure |
&& | Run the next command only if the previous one succeeded (exit status 0) |
|| | Run the next command only if the previous one failed (nonzero exit status) |
& | Run the preceding command in the background, don’t wait for it |
$ true && echo "ran because true"
ran because true
$ false || echo "ran because false"
ran because false
I use && constantly for safe multi-step operations where each step genuinely depends on the previous one succeeding — the classic example being cd /some/dir && rm -rf ./*, where the && ensures the destructive rm never runs if the cd itself failed (say, because the directory didn’t exist), which would otherwise leave you deleting files from an unintended location.
Exit Status: How Commands Report Success or Failure
Every command, when it finishes, sets an exit status: 0 conventionally means success, any nonzero value means some kind of failure (the specific nonzero value’s meaning is command-specific, documented per tool). The special variable $? holds the most recently finished command’s exit status:
$ true; echo $?
0
$ false; echo $?
1
true and false here are actual commands whose entire job is to do nothing except succeed or fail respectively — genuinely useful for testing conditional logic in scripts without side effects.
Here-Documents: Multi-Line Input Inline
A here-document lets you feed multi-line text directly into a command’s standard input, written inline in your script rather than referencing a separate file:
$ cat <<EOF
line1
line2
EOF
line1
line2
Everything between <<EOF and the matching EOF on its own line is fed to the command as standard input. This is extremely common for generating config files or multi-line messages from within a script:
cat <<EOF > /etc/myapp/config.inihost = localhost port = 8080 EOF
Note that by default, variables are expanded inside a here-document, just like double quotes. If you want the here-document treated completely literally (no variable expansion), quote the delimiter: <<'EOF' instead of <<EOF.
Positional Parameters and Special Variables
Inside a script or function, arguments are accessible through numbered variables:
$ bash -c 'echo "args: $# / $0 / $@"' arg1 arg2
args: 1 / arg1 / arg2
| Variable | Meaning |
|---|---|
$0 | The script/command name itself (or, as shown above, the first argument passed to bash -c, which fills that role) |
$1, $2, … | Individual positional arguments |
$# | The count of positional arguments (not including $0) |
$@ | All positional arguments, individually quoted when expanded as "$@" |
$* | All positional arguments as a single combined string |
$? | Exit status of the last command |
$$ | Process ID of the current shell |
$! | Process ID of the last backgrounded job |
The "$@" vs "$*" distinction matters a lot in scripts that forward arguments to another command — "$@" correctly preserves each argument as a separate word even if some contain spaces, while "$*" collapses everything into one string, which is rarely what you want when forwarding arguments verbatim.
Command Grouping
Parentheses and curly braces group commands together, but with an important difference:
(cd /tmp && ls) # runs in a SUBSHELL — the cd doesn't affect your current shell
{ cd /tmp && ls; } # runs in the CURRENT shell — the cd DOES persist afterward
(...) spawns a subshell, so any state changes inside (like cd, or variable assignments) don’t leak back out to your interactive session or script once the group finishes. {...} runs in the current shell context, so changes persist. I use (...) deliberately when I want to temporarily change directory or environment for a group of commands without affecting anything afterward — a clean, self-contained way to scope a cd.
Order of Operations Cheat Sheet
Roughly, in the order bash processes a command line: brace expansion → tilde expansion → parameter/variable expansion → command substitution → arithmetic expansion → word splitting → filename (glob) expansion → quote removal. You don’t need to memorize this precisely, but the practical takeaway that matters daily: quoting happens conceptually “around” the other expansions, meaning double quotes let variable/command substitution still occur, while suppressing the word-splitting and glob-expansion steps that come later in the pipeline.
Practical Debugging: Tracing What a Script Actually Does
When a script isn’t behaving as expected, bash -x (or set -x inside the script) prints every command as it’s actually executed, after all expansions — invaluable for spotting exactly where quoting or expansion went wrong:
$ bash -x myscript.sh
I reach for this before anything else when a script’s behavior doesn’t match what I wrote — it removes all the guesswork about what the shell actually did with a variable or glob.
Common Syntax Mistakes I’ve Made (So You Don’t Have To)
- Unquoted variables with spaces or globs — the single most common source of subtle bugs; default to
"$var". sort file.txt > file.txt— redirection truncates the file before the command ever reads it, destroying the input (covered in depth in thesortarticle).- Assuming
;behaves like&&— a command chained with;runs regardless of what happened before it, silently masking failures that&&would have caught. - Forgetting
--before a filename that might start with a dash — a real and recurring source of “command not found” or unexpected option-parsing errors. - Mixing up
2>&1 > fileand> file 2>&1— order matters; redirections are evaluated strictly left to right.
Best Practices
- Default to double-quoting every variable expansion; reach for unquoted or single-quoted only deliberately.
- Prefer
$(command)over backticks for command substitution — cleaner nesting, easier to read. - Use
&&/||explicitly rather than;when one command’s success genuinely depends on the previous one. - Use
--before filenames or arguments that come from variables and might start with a dash. - When debugging, reach for
bash -xbefore adding print statements manually — it shows you the shell’s actual expanded reality, not your assumption of it.
Compatibility Across Shells
Everything covered here — quoting rules, redirection, pipes, &&/||, positional parameters — is POSIX-standard shell syntax and works identically across bash, dash, zsh, and ksh. The exceptions worth flagging: process substitution (<(...)), here-strings (<<<), and [[ ... ]] extended test syntax are bash/zsh/ksh extensions, not available in strict POSIX /bin/sh (which is dash on Debian/Ubuntu). Scripts with a #!/bin/sh shebang should stick to plain POSIX constructs; scripts intended to use bash-specific features should explicitly shebang #!/bin/bash.
Summary
Shell syntax is a small, learnable grammar once you see it laid out as a whole rather than absorbing it fragment by fragment: commands take options (short and long) and arguments, quoting controls what gets expanded before a command sees its input, pipes and redirection control where data flows, and &&/||/; control conditional execution based on exit status. The habits that prevent the most real-world bugs are simple and consistent — quote your variables, use $(...) for substitution, use -- before untrusted filenames, and reach for bash -x the moment a script’s actual behavior diverges from what you expected it to do.
References
- GNU Bash Reference Manual — https://www.gnu.org/software/bash/manual/bash.html
- POSIX Shell Command Language specification — https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
man bash— the comprehensive bash man page, particularly the “QUOTING” and “REDIRECTION” sections