Bash.CodeCompared.To/Python

Worth noticing before anything else diverges: print takes arguments rather than a line of text, so print("a", "b") puts a space between them the way echo a b does. The difference that will matter later is that echo hands the shell a string and Python hands print objects — a list prints as [1, 2, 3] rather than as three words, because it is still a list right up until it is displayed.

The line to look at is set -euo pipefail, and its absence on the right. Those three options are the shell's attempt to behave the way Python already does: stop on an error, treat an unset variable as an error, and let a failure in the middle of a pipeline count. Python needs no equivalent because an unset name raises NameError, an error raises rather than continuing, and there is no pipeline to swallow anything.

Shell programmers are usually the ones who take to this fastest, because a deeply nested script is exactly where fi/done/esac stop helping. The compensating rule is that indentation must be consistent: four spaces is the convention, tabs and spaces cannot be mixed, and a misaligned line is a syntax error rather than a line that quietly joins the wrong block.

The deeper change is that count = 3 in Python is the number three, and count=3 in Bash is the one-character string "3". Everything in a shell is text; the shell converts to a number only inside $(( )) or [[ -eq ]], and converts back immediately. That is why shell arithmetic is a separate sub-language and why Python does not need one.

Word splitting is not a bug in Bash, it is the design: an unquoted expansion is re-split on whitespace and then glob-expanded, because that is what made the shell convenient for interactive use in 1978. Every "$variable" you have ever typed is you switching it off. In Python a string is a value like any other — passing it around, storing it in a list, handing it to a function and printing it never splits it, so an entire category of bug that shell programmers spend years learning to avoid does not exist to be avoided.

The shell's parameter expansions are genuinely compact and there is no shame in missing them; ${VAR:?message} in particular, which errors out with your message when unset, is nicer than anything Python offers in one expression. What you gain is that the fallback is ordinary code — os.environ.get(name) or compute_it() can call a function, catch an exception or read a file, where the shell form is limited to a word.

This is the second-most common reason a script has to leave the shell. $(( )) is integer-only, bc means shelling out and parsing text back, and every intermediate result is a string that could be empty. Python has integers of unlimited size, floats, decimal for money and fractions for exact ratios, none of which needs a subprocess. Note the two division operators: // matches what $(( )) does, / always gives you a float.

printf maps almost directly onto the format specification after the colon — %-10s is {:<10}, %5d is {:>5}, %.2f is {:.2f}. What f-strings add is that the thing being formatted is an expression rather than a positional argument, so f"{count * 2}" and f"{name.upper()}" both work and there is no chance of the arguments getting out of step with the placeholders.

🚨 The slice is the one to be careful with when porting: ${path:5:3} is offset and length, while path[5:8] is start and end. They agree here only because 5 + 3 is 8. Also note removesuffix rather than rstrip — rstrip(".log") strips any of those four characters repeatedly from the end, which is a real and common bug. For paths specifically, use pathlib rather than either, as the Files section shows.

The trap worth naming: inside [[ ]] the right-hand side of == is a glob, not a regular expression, and quoting it turns the glob off — so [[ "$value" == "Widget-*" ]] silently tests for a literal asterisk. Python has no such mode switch. It also has no equivalent of BASH_REMATCH as a magic global: the match object is returned, so it cannot be clobbered by an unrelated comparison two lines later.

Bash arrays work, and they are the point at which most scripts should have stopped. They cannot be nested, cannot be passed to a function or returned from one, cannot be stored in another array, and every reference to one needs bracket-and-quote syntax that nobody remembers without looking it up. A Python list has none of those limits: it holds anything, including other lists, and is passed around like any other value.

Note ${!counts[@]} for the keys against ${counts[@]} for the values — the exclamation mark is the difference, which is the kind of thing that makes shell scripts hard for the next reader. Python's .items() hands you both at once. Two limits that do not carry over: Bash associative arrays need version 4 or later, which rules out macOS's system /bin/bash, and their values can only be strings, so a dictionary of lists has no shell equivalent at all.

This is usually the row that settles the argument. Once a script has more than one thing to say about each item, the shell forces you to invent an encoding, and every encoding has a character it cannot survive. Note also that the port on the right is a real integer that can be compared and added to, while everything in the left column is a string that has to be converted at each use.

The comparison operators swap too, and they swap confusingly: in [[ ]], -eq compares numbers and == compares strings, so [[ "08" == "8" ]] is false while [[ "08" -eq "8" ]] is true. Python has one ==, and "08" == 8 is simply false because a string is not a number — no silent conversion in either direction.

The similarity stops at what may be matched. A case pattern is a glob against a string; a match case can destructure a list or a dictionary, bind parts of it to names, and add an if guard — case {"role": role, "port": port} if port > 1024: is one statement. That is the direction the whole page runs in: the shell matches text, Python matches structure.

{1..3} is brace expansion, which happens before anything else runs — which is why {1..$count} does not work in Bash and quietly produces the literal text instead. range is an ordinary object taking ordinary arguments, so range(1, count + 1) is unremarkable. The C-style loop exists in both; in Python you almost never write it, because iterating the collection directly is available and clearer.

🚨 local is the most important word in the left column, and leaving it out is a silent bug: without it, name is global and a function three levels up finds its variable overwritten. Python has the opposite default — a name assigned in a function is local unless you say global — which is the safer way round. Keyword arguments have no shell equivalent at all, and they are what makes a five-parameter Python function readable at the call site.

Three consequences disappear at once on the right. A function may return a list, a dictionary or an object rather than text. It costs nothing to call, so a script can be decomposed into small functions without paying a fork each time. And return means what it says: no more return 0 for true and return 1 for false, which reads backwards to everyone and is the source of endless confusion when a shell function is used both ways.

Python's *arguments collects the extras into an ordinary tuple, so it can be measured, sliced, passed onward and stored. There is also **keyword_arguments for named ones, which the shell has no concept of. The pattern function(*some_list) spreads a list back out into separate arguments — the reverse operation, and the equivalent of writing "${array[@]}" at a call site.

Be honest about what is lost: the pipeline streams, so it counts a file larger than memory, and it is four words long. What is gained is that the counts are numbers rather than a column of text that has to be re-parsed by whatever comes next, and that adding a second condition does not mean adding a fifth stage. The rule of thumb that holds up: a pipeline that ends by printing is fine where it is, and a pipeline whose output another stage has to parse is asking to be rewritten.

🚨 There is a second, worse trap in the left column that this example sidesteps: a while read loop on the right-hand side of a pipe runs in a subshell, so any variable it sets is gone when the loop ends. Countless scripts count something in a loop and then print zero. Python has no subshell and no such rule — a name assigned in a loop is still there afterwards.

A comprehension composes where a pipeline chains, and the two hit different walls. Chaining three awk stages is easy and reading them a year later is not; nesting three comprehensions is possible and immediately unreadable, at which point you write a loop. The genuinely useful thing Python adds is that the intermediate list is a value: it can be measured, reused, sorted differently twice, or passed to two functions, none of which a pipeline can do without running the work again.

This is worth knowing before anyone tells you Python cannot handle a large file. for line in open(path) reads one line at a time, generators chain the way pipeline stages do, and the itertools module supplies the equivalents of head, uniq and paste. What the shell still wins on is that its stages run as separate processes on separate cores; a generator chain is one thread doing one thing at a time.

Three differences that bite when porting. Python's backreferences are \1 in a raw string rather than \1 after shell quoting has had a go at it, which removes a whole layer of escaping. The delimiter is not part of the syntax, so a pattern containing a slash needs no s|…|…| trick. And re uses Perl-style syntax throughout, so \d and + work without -E and without wondering which of the four regular-expression dialects on the machine you are talking to.

awk is genuinely excellent at this and there is no need to be sniffy about it — a one-line field extraction should stay a one-line field extraction. The case for moving is names: $2 is a mystery on line 40 of a script and role is not, and if a column is inserted upstream the Python version breaks loudly at the unpacking rather than quietly printing the wrong field. Use line.split(",") for a fixed delimiter, and the csv module the moment quoting is involved.

This is where the balance genuinely tips. One grep is better as a grep. By the third stage you are maintaining a small program written in three languages with two quoting regimes, and every value in it is text. The Python version keeps one language and one set of rules, and the moment you need to count the errors as well as list them, it is a two-line change rather than a redesign.

The with block is the equivalent of the shell closing the file when the redirection ends: the handle is closed at the end of the block, including when an exception is raised inside it. For anything small, read_text and write_text skip the block entirely. Both columns here are writing to a temporary filesystem that starts empty on every run — the browser gives each of these runtimes its own, which is why every example on this page creates what it reads.

A Path also answers questions the shell answers with test operators: path.exists(), path.is_dir(), path.stat().st_size. And it carries the whole path around as one value, so a filename containing a space, a newline or a leading dash is simply a filename — where in the shell each of those is a documented hazard with its own workaround. Prefer pathlib over the older os.path functions in new code.

That difference has ended more scripts than it should have — a backup loop that matches nothing goes on to process a file literally named *.txt, and shopt -s nullglob is the fix nobody remembers to set. Two more: glob returns paths in filesystem order, so sorted is worth writing when the order matters, and rglob("*.txt") or glob("**/*.txt") recurses without needing find.

This is the row where the shell keeps its advantage and it is worth saying plainly: running a program is what a shell is for, and six lines against one is a real cost. The compensation is that result holds the output, the error output and the status as three separate values you can examine, rather than one string plus a magic variable that the next command overwrites. check=True raises on a non-zero status, which is set -e for one command.

When a script is mostly this, leave it in the shell. When a script has one pipeline and four hundred lines of logic around it, move the logic and either keep the pipeline as a single subprocess.run with shell=True on a string you wrote yourself, or replace it with the twenty characters of Python that do the same thing — sorted(set(values)) covers this particular example. Wiring real pipes between processes is possible with Popen and stdout handoff, and it is more code than it is usually worth.

The shell distinction between a shell variable and an exported one has no Python equivalent — every entry in os.environ is exported by definition, and an ordinary Python variable is not in the environment at all. Changing os.environ affects processes this program starts afterwards and nothing else, which is exactly the shell's rule too: neither can alter the environment of the process that started it.

set -euo pipefail is the right first line of any shell script and it is still not enough: -e is famously full of exceptions, ignoring failures inside if conditions, in any command followed by &&, and in most of a function called in a condition. Nobody can hold the full rule in their head. Python's version is one sentence: an exception propagates until something catches it.

The important difference is how much the failure can carry. An exit status is a number from 0 to 255, so everything the caller learns is one of 256 values, and the message is unstructured text on another stream. An exception carries a type, a message, any attributes you put on it, and the stack it came from — so the caller can respond differently to different failures without parsing anything. sys.exit(2) still exists for when the program genuinely has to hand a status back to a shell.

The idiomatic Python is shorter still — with tempfile.NamedTemporaryFile() as handle: deletes the file at the end of the block with no finally written at all, because the cleanup belongs to the object rather than to the call site. That is the pattern to look for whenever you would have reached for trap: an object that tidies up after itself is available for files, locks, sockets, database connections and directories.

It being a list rather than a set of numbered variables is the practical difference: it can be sliced (sys.argv[1:] is "$@"), passed to a function, and iterated without the quoting rules that make "$@" and $* behave differently. But for anything with options, do not parse this by hand — the next row is what you want.

This is the row that quietly justifies the whole move for anything another person will run. getopts handles single-letter options and nothing else, so every script that accepts --dry-run contains a hand-written loop with its own bugs, and the usage message is a string that drifts out of date the first time an option is added. argparse also gives you type=int, choices=[...], required=True, subcommands and mutually exclusive groups, none of which you write yourself.

json.loads returns real Python objects: data["ports"] is a list of integers that can be summed, sorted or appended to, and data["ports"][1] + 1 is 444 rather than a string concatenation. The reverse direction is json.dumps, which is where the shell struggles most — building JSON by string concatenation is how invalid output gets shipped, and jq -n with arguments is the shell-side fix.

The rule in the shell is that JSON must be built by jq -n with --arg for every value, never by interpolation — and it is a rule that is skipped under deadline pressure precisely because the naive version works on the test data. json.dumps has no unsafe mode to fall into: it takes objects rather than text, so quoting is not a decision the caller makes. The same argument applies to building SQL, HTML, shell commands and URLs.

csv.DictReader handles quoting, embedded commas, embedded newlines and the header row, and hands back each record as a dictionary keyed by column name. That last part matters as much as the parsing: row["note"] keeps working when a column is inserted upstream, where -f2 silently starts reading a different column. There is a matching csv.DictWriter for the other direction.

Everything else about large-program structure follows from this. A Python module is loaded once no matter how many files import it, so there is no include-guard problem; a name collision is impossible to have by accident; and the import list at the top of a file is an honest inventory of its dependencies, which a pile of source lines is not. A shell script that has reached three files is telling you something.

Testability is the quiet reason scripts get rewritten. A shell function can only be tested through its output text, so a test asserts on formatting as well as behavior and breaks when a message is reworded. A Python function returns a value, so the test can check the value and ignore the presentation. The wider ecosystem is the other half: pytest, coverage measurement, type checking with mypy and formatting with ruff all expect ordinary functions in importable modules.

The honest test is not length. It is whether the script has logic — a data structure with more than one level, arithmetic that is not integer counting, more than about three options, error handling that has to distinguish between failures, or anything another person will have to modify under time pressure. Orchestration, glue and one-shot pipelines belong in the shell, where they are shorter and clearer than anything Python will give you.