Bash.CodeCompared.To/Zsh

A Bash script that relies on unquoted splitting will quietly stop working under Zsh, producing one iteration instead of many. Nothing warns you. The upside is that the whole class of bugs caused by forgetting to quote a variable containing spaces simply does not exist in Zsh.

The Zsh form says what it does at the point where it does it, and the separator is local to that one expansion. The Bash form depends on the ambient value of IFS, which any earlier line in the script may have changed.

Where they differ is in how you opt out. Bash needs the expansion quoted to preserve an empty argument; Zsh offers the (@) flag, which keeps empty elements even in a nested expansion where quoting is awkward.

Setting it globally is a blunt instrument that gives up the safety Zsh was offering. It is better used scoped to a single function, where a Bash-derived block can keep its original behavior without changing the rest of the script.

In Bash the equivalent guarantee requires printf with an explicit format string, because echo will happily interpret a leading -n or -e as its own option. Most Zsh style guides use print -r -- wherever the value is not a known literal.

This is the second-most common porting bug after word splitting, and unlike word splitting it usually shows up immediately as an off-by-one. A Bash loop written as a C-style index walk from 0 will silently skip the first element and read one past the end.

The Bash form is a long-standing wart that catches people out in the other direction too. Writing ${fruits[@]} and ${#fruits[@]} explicitly works identically in both shells, which makes it the right habit if a script has to run under either.

The Zsh form reads more naturally for the common "from here to the end" case, where -1 means the last element rather than requiring the length to be omitted.

This is one of the few array operations that ports between the shells unchanged, which makes it a safer idiom than computing the index arithmetically from the length.

Because a bare $more already means every element in Zsh, the quoting ceremony Bash needs to avoid re-splitting is unnecessary. This is the no-word-splitting rule paying off rather than costing.

The (@) flag is Zsh's way of saying "treat this as an array even inside double quotes", which preserves empty elements. Bash has no equivalent for a nested expansion, so an array with holes in it needs an explicit index loop to copy faithfully.

The two differ on what "capitalize" means: Bash's ${name^} raises only the first character of the whole string, while Zsh's (C) capitalizes every word. Bash cannot do the latter without a loop.

The Bash version has to save, mutate and restore a global, and only works with [*] inside double quotes. It is also limited to a single-character separator, because [*] joins on the FIRST character of IFS and ignores the rest — so a multi-character join needs a loop. The (j) flag takes a separator of any length.

This is the operation most often reached for in shell scripts and the one Bash makes most awkward. The other common Bash spelling, IFS=, read -ra parts <<< "$csv", scopes IFS to the one command and is the better habit — but it still leaves you with an array where Zsh gives you a value you can keep piping.

A Bash script would normally shell out to sort -u here, which costs two processes and, worse, throws away the original ordering. The hand-written loop above is what it takes to keep that ordering without one, and it is quadratic.

🚨 A sort flag does nothing inside double quotes. Writing "${(on)numbers}" joins the array to a single scalar first, so the sort has one element to order and returns it untouched — with no error. Leave it bare or write ${(on)numbers[@]}.

🚨 These flags take a parameter NAME, not a value. Writing ${(l:6::0:)42} pads the positional parameter $42, which is empty, and silently yields six zeros. The number has to be in a variable first.

Bash additionally offers declare -n to create a true alias that can be assigned through, which Zsh does not have in the same form. For read-only dereferencing the two are equivalent.

🚨 The whole chain must be UNQUOTED. Wrapping it in double quotes joins each inner result to a scalar before the next flag sees it, so unique and sort both silently no-op and the original order comes back unchanged — exactly the trap from the Sorting row, compounded three times. Note also that the Bash column does not sort at all; adding that would mean pasting the insertion sort in as well.

The Zsh form is terser but offers no protection against an odd number of words, where the final key silently gets an empty value. The Bash form makes each pairing explicit at the cost of more punctuation.

Neither shell guarantees any particular ordering for the keys of an associative array, so a script that needs stable output has to sort them — which is where ${(ok)colors[@]} earns its keep.

The Bash version needs a second subscript operation inside the loop body to recover each value. That is one more place for a quoting mistake, and it does redundant lookup work on every iteration.

Checking existence rather than truthiness matters whenever an empty string is a legitimate value. Both forms above get that right, whereas the common shortcut of testing ${colors[key]} for emptiness does not.

This is one of the rare operations that is spelled identically in both shells, including the quoting requirement that surprises people the first time they hit it.

The modifier form is worth recognizing because it chains with other modifiers such as :t for tail and :h for head, which is how Zsh users manipulate paths without calling basename or dirname.

The subscript form avoids the awkward Bash requirement of a leading space before a negative offset, which exists only to stop the colon-minus being parsed as the default-value operator.

The modifiers say what they mean, whereas the ${filename##*.} form requires the reader to work out which end is being trimmed and how greedily. On a path the difference in legibility is larger still.

Omitting the colon in either form narrows the test from "unset or empty" to "unset only", which is the distinction that matters when an empty string is a meaningful value rather than an accident.

This is the same bare-name ambiguity as ${array} itself, and it has the same fix — write ${#array[@]}, which means the element count in both shells and is the form to use in anything portable.

This is a small thing, but drawing a separator line is common enough in scripts that the Bash loop shows up constantly. The alternative Bash idiom, printf with a %*s format and a tr to replace the spaces, needs an external tool.

The Zsh split is the more useful arrangement, because the capture group numbers in the array match the numbers in the pattern rather than being offset by one. Note that Zsh wants the pattern quoted, where Bash requires it unquoted.

Quoting the right-hand side turns the pattern back into a literal in both shells, which is the usual cause of a test that mysteriously stops matching after someone adds defensive quotes.

Bash needs the @ prefix because bare parentheses already mean a subshell in most contexts. Zsh gets away with the plainer spelling inside a pattern, which is one fewer character to remember and closer to ordinary regex.

The Zsh caret composes more freely — it can appear partway through a larger pattern, so *.^(o|a) means "any extension except o or a". Bash's !(...) has to wrap a whole component.

Zsh accepts the Bash ;& and ;| terminators for falling through to the next arm or continuing to test subsequent patterns, so even the non-POSIX extensions port cleanly here.

Both columns build their own tree first, since a glob has nothing to say about a directory that does not exist. The one line that differs is shopt -s globstar: without it Bash treats ** as an ordinary * that stops at the first slash, so the loop silently finds only the files at the top and never descends. Zsh needs no option and has none to forget.

Both columns print the same thing, which is the point — the difference is the mechanism, not the answer. The qualifier vocabulary goes far past (.): (/) is directories, (.x) executable regular files, (.Lm+1) larger than a megabyte, (.mh-24) modified in the last day, and (.om[1]) the newest one. Each of those is a find invocation in Bash.

Watch the first line of each column: Bash prints the pattern itself as though it were a file, while Zsh prints nothing. Zsh treats no-match as an error by default, and the (N) qualifier is how you say an empty result is expected — a per-glob decision rather than the global shopt -s nullglob mode, which changes every glob in the script at once.

Sorting inside the glob means the order survives into the loop with no temporary array and no external sort. Adding a subscript selects a slice, so *(om[1]) is the newest file and *(om[1,3]) the three newest — the idiom that has no concise Bash equivalent at all.

Bash prints the loop saw 0 lines — the loop counted to three inside a subshell that then vanished. Zsh prints the loop saw 3 lines. Bash can opt in with shopt -s lastpipe, which only takes effect when job control is off (true in a script, false at an interactive prompt), and the portable fix is to feed the loop from a redirect instead of a pipe: done < <(printf …). The damage runs the other way too — a Zsh script that totals numbers in a | while read loop silently starts reporting zero the day it is run under Bash.

The double quotes around "${(f)…}" are required and do the opposite of what the Sorting row warns about: here they stop ordinary word splitting from cutting the text at every space, while (f) does the only splitting wanted. Without them a filename with a space in it would arrive as two elements. The index difference — [0] against [1] — is the same 1-based rule as everywhere else in Zsh.

Bash prints saved twice once, because alpha is left empty; Zsh prints it twice. The same rule works in reverse on input, where cat < alpha < beta concatenates the two files in Zsh and reads only beta in Bash, and it composes with pipes: echo hi > log.txt | tr a-z A-Z writes the file AND feeds the pipeline, a tee for free. This is the one Zsh default that can quietly damage a ported Bash script rather than merely change its output, which is why unsetopt MULTIOS is worth knowing about.

Both columns print every stage: 0 1 0 and the grep: 1. Copying the array on the very next line is not tidiness: both shells overwrite it after every command, so the echo that was going to print it would have replaced it first. To make the pipeline itself report the failure instead of inspecting it afterwards, Zsh accepts both setopt PIPE_FAIL and Bash's own set -o pipefail.

Both columns print the same diff, because diff reads each input once from beginning to end, which is all a pipe allows. The difference appears with a command that seeks backwards, reopens the path, or refuses anything that is not a regular file — an archiver, an editor, or anything that memory-maps its input. Those choke on the /dev/fd/63 that a named pipe gives them and are perfectly happy with the /tmp/zsh… that =( ) gives them.

This is identical in both shells and is worth preferring over the [ -gt ] test form, which is a POSIX relic that treats its operands as strings and needs every one of them quoted.

Both shells implement [[ ]] compatibly for the common tests. The single-bracket [ ] form is a real command in both and does require quoting, which is why it is worth abandoning entirely once a script is shell-specific.

The && / || statement form is a common idiom but a trap: if the command after && fails, the || branch also runs. It is only safe when the first branch cannot fail, as with a bare print.

Without the -i attribute, += concatenates strings in both shells, so counter+=5 on an undeclared variable holding 0 produces the string 05 rather than the number 5.

The Bash quoting here is mandatory, not stylistic: without it, any element containing a space becomes two iterations. That whole hazard is absent from the Zsh form.

This is what makes iterating an associative array by (kv) practical, and it removes the index arithmetic that the Bash version needs — along with the off-by-one risk that comes with it.

Both shells support brace ranges, and both support the C-style three-clause for. The repeat form simply removes the unused index variable, which is one less name to invent and one less thing to get wrong.

These are identical in both shells. The difference only appears when the loop body reads from a pipeline, which in Bash famously runs the body in a subshell so its variable assignments are lost — and in Zsh does not. That is the last row of the Pipelines section.

This is where the indexing difference is most likely to bite during a port, because a loop transcribed literally from Bash will read $fruits[0] — which in Zsh is an error rather than the first element.

Zsh additionally allows the two spellings to be combined as function name() { }, which Bash accepts as well. There is no behavioral difference between them in either shell.

In Zsh, local is a synonym for typeset, so every typeset attribute is available on a local variable — typeset -i for integers or typeset -A for a local map. Bash needs local -i and local -A as separate spellings.

Zsh scripts conventionally use the name reply for a scalar result and REPLY for an array, following the convention its own builtins use. Assigning to a global from inside a function is the only way to return a value without a subshell, which is why the convention survives in scripts where the cost of $( ) in a loop actually shows up.

The practical use is carving out a scope for local variables in the middle of a script, or for temporarily setting an option with setopt LOCAL_OPTIONS inside the body so it reverts on exit.

The quoting around "$@" is load-bearing in Bash — without it, the argument containing a space becomes two iterations. In Zsh the bare form is already correct, which is the same no-splitting rule showing up one more time.

Zsh option names ignore case and underscores, so EXTENDED_GLOB, extendedglob and Extended_Glob are all the same option. The convention is capitals with underscores in scripts and lowercase interactively.

This is the difference between a library function that is safe to call and one that quietly reconfigures the caller's shell. The Bash version above still leaks if the function returns early or the shell is interrupted between the set and the restore.

This is the pragmatic way to run a Bash-derived function unchanged inside a Zsh script: wrap it, put emulate -L sh at the top, and let the rest of the script keep Zsh semantics. Note the loop above splits, because sh emulation restores that behavior.

Zsh adds attributes Bash lacks, notably -F and -E for floating point and -T for a variable tied to an array, which is how PATH and path stay in sync. Bash has no floating-point support at all.

The value of $? is replaced by the next command that runs, including the one inside a test, so it has to be captured immediately if it is needed more than once.

The Bash equivalent is an EXIT trap, which is global — installing a second one replaces the first, so two nested operations that both want cleanup have to cooperate manually. An always block is lexically scoped and nests freely.

Zsh names the same options in words rather than letters. Both shells share the well-documented caveat that ERR_EXIT does not fire for a command whose status is consumed by a test, a && chain, or an if condition.

Zsh adds a second form where defining a function named TRAP followed by the signal name installs the handler, which gives the handler its own local scope. A trap string, by contrast, runs in the scope of wherever the signal happened to fire. Passing $LINENO instead of $? is the other common idiom, but the browser runtime prepends a preamble to every snippet, so the line number it reports would not match the code you can see.

The escapes do not correspond one to one. Zsh's %~ abbreviates the home directory to a tilde where Bash's \w does the same, but Zsh adds conditional forms such as %(?..%F{red}) that change the prompt based on the last exit status.

Forgetting the \[ \] wrapping in Bash produces the classic symptom of a shell that overwrites its own prompt when you edit a long command line. That failure mode does not exist in Zsh.

This is a genuinely Zsh-only feature, and it is where most themes put timestamps, git status and exit codes so the left prompt stays short. Bash has nothing comparable that survives line editing.

Zsh reads its files in a fixed order and each has one job, so PATH goes in ~/.zshenv, login-only setup in ~/.zprofile, and interactive settings in ~/.zshrc. Bash picks exactly one of three candidate login files, which is why the source-.bashrc-from-.bash_profile dance is nearly universal.

This is the feature most often cited as the reason to switch, and it is why frameworks such as oh-my-zsh exist — they are mostly configuration on top of a completion system that is already there. Bash completion is a third-party package with a much smaller vocabulary of completers.

SHARE_HISTORY is the notable win: concurrent Zsh sessions see each other's commands immediately, whereas the Bash equivalent requires a hand-written PROMPT_COMMAND that appends and re-reads the file on every prompt. EXTENDED_HISTORY additionally records a timestamp and duration per entry.