Ruby.CodeCompared.To/Bash

Variable names are case-sensitive. Unlike Ruby, Bash has no separate integer or string types at the variable level — everything is a string unless declare -i says otherwise, 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; Bash'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.

Bash 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. readonly PI=3.14159 is an equivalent spelling, and in Zsh the same declaration is written typeset -r.

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 — Bash 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 ${#fruits[@]} counts elements rather than characters — so ${#…} 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. A negative offset counts back from the end, but it needs a space in front of the minus (${text: -3}), since :- already means "or this default" and the shell would otherwise read it that way.

The mnemonic is that ^ points up and , hangs down. All four arrived in Bash 4, so a script that must run on macOS's system /bin/bash — still 3.2, for licensing reasons — cannot use them. Ruby's .upcase, .downcase and .capitalize are the equivalents, and Zsh spells the same operations ${(U)var} and ${(L)var} instead.

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; Bash 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 writing == 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 #{}.

Ruby's "-" * 20 is one expression against four lines, and this is the row where the shell simply loses. There is a shorter trick — printf '%.0s-' {1..20} abuses a zero-width format to print the literal twenty times — but it is more obscure than the loop and no faster, so the loop is what real scripts contain.

Writing IFS="," in front of the command rather than on its own line scopes the change to that one command, which is the habit that avoids a mysterious bug three functions later. The two flags earn their place too: -r stops backslashes being treated as escapes, and -a reads into an array instead of separate variables. Ruby's String#split takes one argument and has none of this reach.

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.

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. Real floating point means shelling out to bc or awk.

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. Anything more — actual float arithmetic — means shelling out to bc or awk: a whole second program, and a process to go with it, to multiply two numbers.

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 (( )).

🚨 The braces are not optional here. Writing $fruits without them does not expand to the array — it silently gives you element 0 alone, which looks like working code right up until the array has more than one thing in it. (Zsh differs on both counts: its arrays start at 1, and a bare $array there means every element.) Negative indices count from the end as in Ruby, and arrived in Bash 4.1.

Leave the subscript off and ${#fruits} counts the CHARACTERS in element 0, which on this array is 5 and looks plausible enough to ship. [*] counts the same as [@] here; the two only diverge inside double quotes, which the next row covers.

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 element 0 instead of adding a new one, silently. Ruby's << and push cannot be confused that way. Assigning past the end (fruits[9]="fig") also works and leaves a gap, because Bash arrays are sparse.

It reads exactly like Ruby's fruits[1, 2], offset and length alike, and it is the same punctuation as the substring expansion earlier — the only difference is the [@] saying which of the two is meant. That consistency is not free everywhere: in Zsh, where arrays start at 1, this particular expansion still counts from 0.

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.

Asking the array for its indices rather than counting to ${#fruits[@]} is not pedantry: Bash arrays are sparse, so after any unset the indices are no longer 0 1 2 and a counted loop reads a hole. The same syntax returns the string keys of an associative array, which is why it is the one form worth learning.

Watch the third line below: the values look right — apple cherry — while the indices are 0 2. Every counted loop over this array now reads a missing element at 1. Ruby's delete_at shifts everything down and leaves no hole. Quote the subscript — unset "fruits[1]" — 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 indexed array, and every string key is coerced to the subscript 0, so each assignment overwrites the last and the map appears to hold only its final entry. 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.

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 expansions below can even disagree with each other about which entry comes first, so never pair them up positionally. When order matters, the keys have to be sorted, which in a real shell means piping them through sort. 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 with a subscript arrived in Bash 4.2.

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; making it reproducible means piping the keys through sort — another program, and another process, for what Ruby gets from the hash itself.

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 ${!settings[@]} and from the -v 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 Bash'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. Feeding the same loop from a pipe instead is equally idiomatic on a real machine, but needs a second process, so only the redirect form runs here.

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 Bash 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. There are two older ways round that, both still common. One is to assign to a name the caller agrees to read, which costs no process at all and so still turns up in loops where the cost of $( ) shows up. Bash 4.3 offers a third way: pass the caller's variable name and use declare -n, as the Nameref row shows.

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.

On a real machine the natural spelling is echo the result and capture it with $(factorial 4), which reads almost exactly like the Ruby — the global-variable form below is what remains when a second process is out of reach. Either way, recursion in a shell is a demonstration rather than a technique: every level costs a function frame, and on the command-substitution version, a whole process.

This is Bash's answer to Ruby passing objects by reference, and it arrived only in Bash 4.3 — which is why older scripts do the same job with eval and careful quoting, and why Zsh, which has no typeset -n at all, still must. Name the nameref something that cannot collide with what the caller passed: if both are called collection, the reference points at itself and Bash reports a circular reference.

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.

It is global and read-only, and the next =~ anywhere in the script overwrites it — including one inside a function called in between — so copy anything needed later rather than reaching back for it. Ruby hands you a MatchData object that belongs to that one match and cannot be clobbered. Zsh calls its version match and numbers it from 1, so a script ported between the two shells needs both changes.

The other four read the same way — *(…) zero or more, +(…) one or more, ?(…) zero or one, and !(…) anything but. Between them they cover most of what a regular expression would be doing on a filename. The option is off by default and per-script, so it belongs at the top of any file that relies on it; without it the pattern is read literally and quietly matches nothing. Zsh spells the same idea (txt|md), with no leading @.

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 and making a failure anywhere in a pipeline count.

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 ERR, which fires whenever any command fails and pairs naturally with set -e.

Prefer printf in scripts. echo's handling of leading dashes and backslash escapes differs between shells and even between builds of the same shell — echo -e is not POSIX and macOS's /bin/echo disagrees with Bash's builtin — so a string that begins with -n or contains \t is not portable. printf '%s\n' has no such ambiguity.

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. Use printf rather than echo -e, which is not POSIX and is exactly the portability trap the previous row describes.

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. $BASH_VERSION is also the cleanest way to tell which shell a script has ended up in — Zsh sets $ZSH_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 — standard input for the command on the first line. That command is usually cat, which is external and therefore absent here, so this example feeds the read builtin instead. 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.