Ruby.CodeCompared.To/Zsh

Variable names are case-sensitive. Unlike Ruby, Zsh has no separate integer or string types at the variable level — everything is a string unless you use typeset -i, which is why greeting="Hello" and number=42 are the same kind of statement here and two different kinds in Ruby.

They are optional for simple access and required whenever the name is immediately followed by letters, digits or underscores that are not part of it: $languageist would send the shell looking for a variable called languageist. Ruby never has that ambiguity, because its delimiters are mandatory.

Double quotes also suppress word splitting and glob expansion, which matters far more in a shell than the interpolation question does — an unquoted value containing a space becomes two words. Ruby's single-quoted strings suppress interpolation similarly but still honor \\ and \' escapes; Zsh's honor nothing whatsoever, so a single quote cannot appear inside single quotes at all.

That last point is the difference from Ruby's ||=, which writes the fallback back into the variable; the expansion below only supplies it for this one use. The colon is doing real work: :- treats both an unset variable and an empty string as missing, while a bare - triggers only when the variable was never set at all.

This is the expansion that matches Ruby's ||= exactly, because the assignment persists: the (( count += 1 )) on the next line is operating on a variable that now really holds 0. Without the := it would be incrementing nothing.

The everyday use is exactly the one below — dropping a prefix, a flag or a separator into a command line only when there is something to justify it, with no if around it. Note that the alternate text is inside the braces, trailing space and all, so the space disappears along with the prefix.

Zsh is stricter than Ruby here: reassigning a read-only variable is a hard runtime error, where a Ruby constant merely warns and then goes ahead and changes. declare works as an alias for typeset, but typeset is the idiomatic Zsh spelling.

That is why count+="hello" below is not an error. A string that will not parse as a number is simply worth zero, so the variable silently keeps its old value — the exact opposite of Ruby, which raises a TypeError rather than guess. An integer variable is convenient and quiet, and quiet is the part to watch.

The transformation happens at assignment time, not at read time, so the original text is gone — there is no way to get HELLO WORLD back out of lowered. Ruby's .downcase is the opposite arrangement: the string is untouched and each read decides for itself.

Ruby has to go through the ENV hash precisely because its own variables are somewhere else. The uppercase names are convention, not rule — Zsh enforces no distinction between an environment variable and one a script invented — which is why lowercase names for script-local variables is a habit worth keeping.

The same syntax works on an array, where it counts elements rather than characters — so ${#thing} answers "how big" without your having to say what kind of thing it is. Ruby splits that across .length and .size, which are the same method twice.

Ruby's [start, length] maps onto this directly, right down to the zero-based offset — which is worth noticing, because Zsh arrays start at 1. Strings are the exception. A negative offset counts back from the end, but it needs a space in front of the minus (${text: -3}), since :- already means something else entirely.

Watch the third line: (C) capitalizes every word, where Ruby's .capitalize raises only the first letter of the whole string and lowercases the rest. Bash spells the first two ${var^^} and ${var,,} and has nothing for the third. The flag slot is the same one used for joining, splitting, sorting and padding, so learning where it goes pays for itself many times over.

Ruby's String#sub does the same job but takes a Regexp, so patterns do not carry over between the two: . is a literal dot here, and * means what .* means there. The variable is not modified; the expansion produces a new value.

Ruby marks the same distinction by changing the method name from sub to gsub, which is harder to overlook in review than one extra slash. The pattern is still a glob rather than a regexp.

Since the pattern is a glob, ##*/ means "everything up to and including the last slash", which is how a shell script gets a basename without calling one. Ruby reaches for delete_prefix when the prefix is literal and a regexp when it is not; Zsh uses one mechanism for both.

The pairing is worth memorizing as a picture: on a US keyboard # sits to the left of %, and it strips from the left. Those four expansions between them cover nearly all path and filename work with no external tool involved, which is why shell scripts so rarely need basename and dirname.

Note where the quotes fall below: "quick" is quoted so its own characters stay literal, while the two * outside the quotes remain live pattern. Quoting the entire right-hand side turns the whole thing back into a literal comparison and the test silently stops finding anything — the shell equivalent of == where include? was meant.

A + between two strings does not concatenate them — it is arithmetic, and on words it produces zero or an error rather than the joined text. The upside of having no operator is that the quoted form reads like the output it produces, which is why the shell needs nothing resembling Ruby's #{}.

This is Ruby's Array#join with no method call and no external tool. Bash has no equivalent at all: it has to set IFS, expand "${array[*]}", and set IFS back, and even then the separator can only be one character long.

The index is the thing to watch when coming from Ruby: Zsh arrays start at 1, so ${parts[2]} below is bob, the same element Ruby calls parts[1]. An off-by-one in a ported loop is the most common way this bites.

Taking the leading case apart: ${text%%[! ]*} removes the longest run starting at the first non-space, which leaves just the leading spaces; feeding that to ${text#…} then removes them. It works, it is genuinely the idiomatic answer, and it is still four punctuation marks doing the work of .strip. Where a pipeline is available, tr -d and friends are usually the more readable choice.

Do not confuse $(( )) with $( ), which runs a command and captures its output; the doubled parentheses are the only thing telling them apart. The arithmetic is integer-only, so $(( 10 / 3 )) is 3 in both columns — Ruby happens to agree here because Integer#/ truncates too, but $(( 1 / 3 )) is 0 where Ruby's 1.0 / 3 is not. Floating point needs zmodload zsh/mathfunc.

As a command it also has an exit code, and the rule is upside down from what a C programmer expects: a non-zero result means success (exit code 0), and a result of zero means failure. That is what lets (( count )) read as "if count is non-zero" in an if or while. Every C-style compound operator works — +=, -=, *=, /=, %=, **=.

The two positions differ in what the expression evaluates to — counter++ yields the old value and ++counter the new one — which matters when the result is being used for something rather than thrown away as it is below. Ruby has neither, on the grounds that += 1 says the same thing without the puzzle.

The alternative is the legacy [ "$score" -ge 90 ] spelling with its -eq/-lt/-gt flags, which exists because < and > meant redirection long before (( )) was invented. Prefer (( )): the symbols mean what they look like, and no quoting is needed around the variables.

The second form has a trap Ruby's ternary does not: it is two ordinary commands, so if the && branch itself fails, the || branch runs as well and you get both outputs. It is safe below because echo cannot fail, and it is worth spelling out as a real if the moment the branch does anything more interesting.

Ruby's .round(2) returns a new number you can go on calculating with; printf hands back text and nothing else. That distinction stops mattering the moment the value is on its way to a screen, which is most of the time in a shell script. Real floating-point arithmetic needs zmodload zsh/mathfunc, after which $(( sqrt(2) )) works.

Everything below could be written (( product = 6 * 7 )), which is the contemporary idiom and needs no quotes. let is worth recognizing rather than writing: it turns up constantly in scripts old enough to predate (( )), and it works identically in Bash.

Ruby and Bash both start at 0, so a loop translated straight across is off by one and quietly reads one element short. Negative indices work the same as Ruby's, counting back from the end. setopt KSH_ARRAYS switches the whole shell to 0-based if a script really needs it, at the cost of every other Zsh array idiom on this page.

Bash requires ${#fruits[@]} here, and that longer form works in Zsh too, so it is the one to write in a script meant for both. Watch out for the difference in what the two count when the name holds a scalar: on a string, ${#name} is a character count in either shell.

Its near-twin "${fruits[*]}" looks the same and is not: it glues every element into ONE word, joined by the first character of IFS. The difference is invisible until an element contains a space, at which point [@] keeps it whole and [*] has already thrown the boundary away. Prefer [@] unless the joining is the point.

The parentheses are what make it an append rather than a string concatenation: fruits+="cherry" without them glues the text onto the LAST element instead of adding a new one, silently. Ruby's << and push cannot be confused that way. Assigning past the end (fruits[6]="fig") also works and leaves a gap.

Both lines below select the same two elements, which is the clearest way to see the trap: in a shell where arrays start at 1, one of these slices does not. Ruby's fruits[1, 2] matches the first spelling exactly, offset and length alike.

The quotes are the whole safety story. Left off, an element containing a space arrives as two separate iterations, which is the classic shell bug that only shows up once someone has a file called My Documents. Ruby's .each has no equivalent failure mode, because there is nothing being re-parsed.

The numbers printed are 1, 2, 3 where Ruby's each_with_index gives 0, 1, 2 — the 1-based rule again, and worth remembering before using such an index in arithmetic. Bash spells the same thing ${!fruits[@]}, which also works in Zsh and also yields Zsh's 1-based numbering.

Ruby's delete_at does both halves at once, which is why the second line below has no counterpart in the left column. Quote the subscript — unset "fruits[2]" — or the brackets are read as a glob pattern and the shell goes looking for a matching filename.

🚨 It happens at parse time, before any variable has a value, so {1..$count} does not produce a range — it produces the literal string {1..$count}, and the loop runs once over that. A variable bound needs the C-style for (( index = 1; index <= count; index++ )) instead. Ruby's Range has no such restriction, since it is an ordinary object built at run time.

Skipping the declaration does not raise anything — the name stays an ordinary scalar and the string subscripts are quietly ignored, which is the usual way this goes wrong. Two further limits worth knowing up front: keys and values are strings and only strings, and iteration order is undefined, where a Ruby hash has preserved insertion order since 1.9. Bash spells the declaration declare -A, which Zsh also accepts.

The brackets around each key are mandatory: without them the parentheses are just an ordinary array literal, and the pairs become elements alternating key, value, key, value. This is as close as the shell gets to Ruby's hash literal, and it is the form to reach for whenever the contents are known in advance.

🚨 The order is not defined and is not insertion order — the two lines below can even disagree with each other about which entry comes first, so never pair them up positionally. When order matters, add o to sort: ${(ko)scores}. Ruby needs no such precaution, because its hashes have preserved insertion order since 1.9.

🚨 The obvious-looking [[ -n ${colors[purple]} ]] is not the same test: it asks whether the value is non-empty, so a key deliberately set to the empty string reports as missing. Ruby keeps the two questions apart as key? and [], and so should you. [[ -v colors[red] ]] is the Bash-compatible spelling of the same existence test.

Ruby's block takes both at once and needs no lookup, which is the more pleasant arrangement and also the reason Ruby can guarantee an order. Here the order is undefined; adding o to the flags, as "${(@ko)inventory}", sorts the keys and makes the output reproducible. "${!inventory[@]}" is the Bash-compatible spelling.

Unlike the indexed-array case, nothing needs compacting afterwards — a map has no positions to leave a hole in, so the key is simply gone from ${(k)settings} and from the ${+…} existence test. The quotes around "settings[verbose]" are still required, or the brackets are read as a glob and the shell tries to match a filename.

That makes three things the same prefix counts — characters in a string, elements in an array, keys in a map — decided entirely by what the variable happens to hold. Ruby uses .size for all three as well, so the habit carries over intact.

The semicolon before then is not optional. if takes a command, and the shell needs to be told where that command ends; a newline does the job just as well. Ruby's elsif and Zsh's elif differ by one letter, which is the kind of thing that costs ten minutes exactly once.

Each line below is a test followed by &&, so it reads as "if that held, do this" — the compact form a shell prompt encourages. Always prefer [[ ]] to the older single-bracket [ ], which is an ordinary command: an unquoted empty variable disappears from its argument list entirely and it fails with a syntax error rather than answering the question.

The word-flags exist because < and > already meant redirection when the test command was designed, so they could not be spent on comparison. Inside (( )) that conflict is gone. Write the arithmetic form in new code, and expect to read the other one everywhere.

This is why the shell has no single all-purpose condition syntax and does not need one: each bracket does the kind of comparison it is good at, and && glues the results together. The -a and -o flags inside the old [ ] are the previous generation's answer and are best avoided — they are ambiguous with operands that look like operators.

The patterns are globs, not regexes, so the bare words below match literally and * is the catch-all that stands in for Ruby's else. Leaving the final *) off is legal and means "if nothing matched, do nothing" — silently, which is worth a deliberate decision rather than an omission.

The Ruby column has to reach for regexps and anchor each one with $; the glob needs no anchor because it must match the whole word by definition. Regexps are the more powerful tool, but for the job below — dispatch on an extension — the glob says exactly as much and reads like the filenames it matches.

The reason for the inversion is that there is only one way to succeed and many ways to fail, so the failures get the numbers. Chaining the two as test && on-success || on-failure looks like a ternary and is not one: if the success branch itself fails, the failure branch runs too and both outputs appear. Ruby's trailing if in the left column has no such edge.

That list is still ordinary shell text, so it goes through glob expansion on the way in: a word containing * turns into matching filenames rather than staying a literal. This is a feature when looping over *.txt and a surprise otherwise. When the list comes from an array, quote it — for item in "${array[@]}" — as the Arrays section spells out.

This is the form to use whenever the bound is a variable, because brace expansion cannot be. The loop variable survives the loop and holds the value that ended it, which is occasionally useful and occasionally the source of a stale value two screens further down. Ruby's .times block scopes its index and has neither property.

Because it is a command, anything at all can serve as a condition — while read -r line loops until the read fails at end of input, which no expression-based while can express as briefly. The ; before do is the same requirement as before then: the shell has to be told where the condition command ends.

Ruby has the same pair with the same inversion, and the advice is the same in both: it earns its place when the natural way to say the condition is positive — "until the file appears", "until the count reaches five" — and costs the reader a mental negation the rest of the time.

Both take an optional count, so break 2 leaves the two innermost loops at once. Ruby has no equivalent and needs a flag variable or a catch/throw to get out of nested loops, which makes this one of the few places the shell is the more expressive of the two.

Ruby needs two different constructs for the two loops below — a Range of strings for the letters and .step for the numbers — where the shell spells both the same way. The catch is the one from the Arrays section: the range is written out before any variable has a value, so a computed bound needs a C-style loop instead.

Both halves of while IFS= read -r line are protective and both are worth typing every time. Setting IFS to nothing for this one command stops leading and trailing whitespace being trimmed off each line; -r stops a backslash in the data from being treated as an escape. Without them, this loop quietly mangles exactly the input you would most want it not to.

The upside of a function being just another command is that it can be used anywhere a command can: in a pipeline, as a condition, in place of a program that is not installed. The downside is the one visible below — the signature says nothing about what the function expects, so the first line of the body is often local name="$1" purely to give the argument a readable name. function greet { … } is an accepted alternative spelling.

Quote it as "$@" whenever the arguments are being passed on to something else — that is the spelling that keeps each argument intact, spaces and all, and it is the reason "$@" appears so often in wrapper functions. Its unquoted twin $* welds everything into one string. Ruby's *args is a real array and needs no such care.

This is the reverse of every default Ruby has, and it fails quietly: without the local below, increment would set the outer counter to 1 and the last line would print Outside: 1. Nothing warns. The habit worth forming is to declare every working variable in a function local on first use, whether or not anything outside currently shares the name.

That is why the function below is a single arithmetic test with nothing around it: (( )) already produces the right exit code, so the function is a predicate without ever saying so. Note the double inversion at work — the arithmetic is true when non-zero, and the exit code is true when zero — which cancels out and reads correctly, but is worth tracing once. return can only carry a number; a string needs the next row.

So a shell function's "return value" is its standard output, and the two are impossible to tell apart: a stray echo left in for debugging becomes part of the value and corrupts it silently. That is the cost of the arrangement, and the benefit is that any command at all can be used this way, not only functions. The older workaround — assigning to an agreed global and reading it after the call — avoids the extra process and is still common in performance-sensitive scripts.

The local matters as much as the default does: it both names the argument and keeps it from escaping. Ruby's def greet(name = "World") says the same thing in the signature, where a reader looking for the function's interface will actually find it. This is the shell's biggest readability gap, and the reason a shell function's first few lines are so often nothing but unpacking.

It reads almost like the Ruby, which is a recent luxury: before command substitution could be captured, the result had to be passed back through an agreed global variable and the whole shape of the function changed. The cost is that every level of recursion is a whole extra process, so this is fine for a demonstration and the wrong tool for real recursive work — a hundred levels deep means a hundred processes.

Zsh has no typeset -n nameref — that is a Bash and ksh feature, and Zsh 5.9 rejects it outright with bad option: -n. Writing through a name therefore means eval, with all the quoting care that implies; reading through one is safer and needs no eval, via the ${(P)name} flag. Ruby needs none of this, because items is already a reference to the same array the caller holds.

That is the whole difference from the Ruby column, and it cuts both ways. Ruby passes an Array from method to method, so the elements are never re-examined; the shell passes bytes, so every stage parses the text again and a value containing a newline arrives as two items. In exchange, any stage can be replaced by any program in the world that reads standard input, which is why a shell pipeline can do things no single language's standard library covers.

Ruby's Enumerable#grep is named after this command and does the same job on objects. The pattern here is a POSIX regular expression rather than a Ruby one, so the shorthand classes are spelled out — [0-9], not \d. Useful flags: -v inverts the test, -c counts instead of printing, and -q prints nothing and answers through the exit code.

It is the narrowest tool in this section — it knows nothing about lines, words or patterns, only characters — which is exactly why it is the fastest way to change case or to delete a character class outright with tr -d. Zsh can do this particular job without a pipeline at all, using the ${(U)word} flag from the String Operations section; reach for tr when the text is already flowing past.

The -u is not merely shorter than a separate | uniq — it is necessary, because uniq only removes adjacent duplicates and is therefore useless on unsorted input. Ruby's .uniq has no such precondition. Two flags worth remembering: -n sorts numerically, without which 10 sorts before 9, and -r reverses.

Stopping is the interesting part: head closes the pipe once it has what it needs, and the stage feeding it is killed rather than left to finish. That is what makes | head safe in front of a command that would otherwise produce millions of lines — it is lazy in the same way Ruby's .lazy.first(3) is, without having to ask. tail -n 3 is the other end, and it cannot be lazy, because the last three lines are not knowable until the input ends.

The double quotes look wrong next to the warning that flags do nothing inside quotes, and they are right here for a different reason: they stop ordinary word splitting from cutting the text at every space, leaving (f) as the only thing doing any splitting. Drop them and a line containing a space becomes two elements. This is the bridge between the two halves of the shell — a pipeline on one side, a real array with a length and an index on the other.

🚨 That rule is Zsh's, not the shell's in general. Bash runs every stage in a subshell, so the identical script there prints total: 0 — the loop counts correctly and then the process holding the answer exits. It is the single most common way a working Zsh script breaks when it is run under Bash. The portable spelling feeds the loop from a redirect instead of a pipe: done < <(seq 1 10).

Nothing marks shout as a filter; it simply reads until the input runs out, and that is the entire contract every stage in this section obeys. The Ruby method has to be handed its collection and hands one back, which makes it composable with other Ruby and with nothing else. This one composes with every program on the machine — and, on this page, with fifteen real coreutils compiled into the browser runtime.

Ruby needs a differently named method for each end of the string; the shell needs only a differently placed *. Both tests below are cheap enough to use freely — no regular-expression engine is involved. As always inside [[ ]], quoting the right-hand side turns the pattern back into a literal and the test stops matching.

🚨 There is no \d, \w or \s in POSIX ERE; write [0-9], [A-Za-z0-9_] and [[:space:]]. A pattern lifted from Ruby that leans on those will not error — it will match the literal letters d, w and s, and simply fail to match anything real. Leave the pattern unquoted, or it becomes a literal string comparison.

The whole matched text is in $MATCH separately, which is the slot Ruby fills with match[0]. Both are overwritten by the next =~ and are only meaningful while the if that tested them is still in scope, so copy anything needed later. Bash calls its version BASH_REMATCH and numbers it from 0 — a script ported between the two needs both changes.

The option is off by default and is per-script, so it belongs at the top of any file that relies on it — a pattern using ( | ) without it is read as a literal and quietly matches nothing. The same switch also brings ^pattern for negation and #/## as repetition operators, which between them cover most of what a regular expression would be doing on a filename.

It looks laborious next to Ruby's /^y(es)?$/i, and it is — but it is also the standard shell idiom for a yes/no prompt, so it reads as boilerplate rather than as cleverness. When a pattern grows past this, that is the signal to switch to [[ $input =~ … ]] and a real regular expression.

Read $? immediately or not at all: it belongs to the command that just finished, so the echo printing it has already replaced it by the time the next line runs. true and false are real builtins that exist for no other purpose than to produce 0 and 1. Ruby's exceptions carry a class, a message and a backtrace; a shell script has one number and whatever the command printed on its way out.

This is the shell opting into the behavior Ruby has by default: an unhandled failure ends the program instead of being ignored. It has famous exceptions of its own — a command whose failure is already being handled by if, && or || does not trigger it — so it is a safety net rather than a guarantee. The usual production incantation is set -euo pipefail, adding the unset-variable check from the next row.

The damage this prevents is not subtle: rm -rf "$prefix/" with a typo in prefix becomes rm -rf "/". Ruby raises NameError for the same mistake without being asked. Where a variable is legitimately optional, ${name:-} supplies a default and keeps set -u happy.

The braces are what let more than one command hang off the ||, and they need the semicolon before the closing brace — { echo one; echo two; } — because a brace group is a list of commands rather than an expression. For a single fallback command the braces can go entirely. The equivalent if ! connect "remotehost"; then … fi says the same thing and takes three lines.

That "however it ends" is what makes it the right place for removing a temporary directory or releasing a lock; Ruby's at_exit and ensure exist for the same reason. The other events worth knowing are INT for Ctrl-C and ZERR, which fires whenever any command fails — Zsh's spelling of what Bash calls ERR.

Prefer printf in scripts. echo's handling of leading dashes and backslash escapes differs between shells and even between builds of the same shell, so a string that begins with -n or contains \t is not portable; printf '%s\n' has no such ambiguity. Zsh's own print builtin is a third option with useful extras, notably print -l for one argument per line.

The only real difference below is punctuation — Ruby separates its arguments with commas, the shell with spaces. One shell-specific bonus: if more arguments are supplied than the format uses, printf starts the format over and consumes them all, which is how printf "%s\n" "${array[@]}" prints an entire array one element per line.

Because it is only text, the two columns are the same sequences in both languages, and the same ones any other language would emit. Always emit the reset at the end — a script that exits without it leaves the user's prompt colored. Zsh has a friendlier %F{green}…%f spelling, but only inside prompts and print -P.

Left-align with a minus (%-12s) and right-align without one (%8s) — names read better on the left, numbers on the right. Quote the variable as "$header"; unquoted, the format string is split on its spaces and only the first piece is used as a format. This is the whole of table formatting in a shell, with no column or awk involved.

Two more are worth knowing because they have no Ruby counterpart at all: $RANDOM hands back a fresh random integer every time it is read, and $SECONDS counts up from the moment the shell started, which makes timing a script a subtraction. $ZSH_VERSION is also the cleanest way to tell which shell a script has ended up in — Bash sets $BASH_VERSION instead, and neither sets the other's.

The difference from Ruby's heredoc is where the text goes: Ruby's is a string and can be assigned, while the shell's is plumbing — it is standard input for the command on the first line, which is why cat is there at all. Quoting the delimiter as <<'EOF' turns expansion off, matching Ruby's <<~'HEREDOC', and <<-EOF strips leading tabs so the block can be indented with the code around it.