When to use Bash, and when to switch to Python

One log summary took 13 lines of Bash and 48 lines of Python here, and the two printed the same eleven lines. Then a line with a dash where its latency belonged went into both: the Bash version counted it as a request of 0 ms and printed a lower mean, while the Python version stopped and named line 25.

Use Bash when a task mostly runs other programs, moves files and checks how each step ended. Switch to Python when the hard part is no longer running programs: nested JSON, decimals, many error cases, state that must last, users on Windows, speed that matters or more than about 100 lines. The sections below show where the line between them falls, from the seven signs to a wrapper that keeps the command people type.

Bash is at its best when it glues programs together

A small site is released in four steps: copy the pages, check that each has a <title>, pack them into an archive and list what went in. Each step is a program that already exists (cp, grep, tar and sort), so the script only runs them in order and stops when one reports a problem. This is release.sh, 15 lines:

#!/usr/bin/env bash
# Packs the pages of a small site into dist/site.tar.gz, after checking that every page has a <title>.
set -euo pipefail

rm -rf build dist
mkdir -p build dist
cp -R pages/. build/
untitled=$(grep -L '<title>' build/*.html || true)
if [[ -n $untitled ]]; then
  printf 'release: no <title> in %s\n' "$untitled" >&2
  exit 1
fi
tar -czf dist/site.tar.gz -C build .
tar -tzf dist/site.tar.gz | sort
echo "release: packed $(find build -name '*.html' | wc -l | tr -d ' ') pages"

The session runs it on two good pages, then adds a page without a title and runs it again:

from session import files, run, write

# A glue script: release.sh copies pages, checks them with grep, packs them with tar and lists the archive. It runs
# once on two good pages, then again after a page without a <title> is added; ls shows what the failed run left.
files("release.sh")
write("pages/index.html", "<html><head><title>Home</title></head><body>Welcome</body></html>\n")
write("pages/about.html", "<html><head><title>About</title></head><body>About us</body></html>\n")
run("""
bash release.sh
printf '%s\\n' '<html><body>Prices</body></html>' > pages/prices.html
!bash release.sh
ls dist
""")

$ bash release.sh
./
./about.html
./index.html
release: packed 2 pages
$ printf '%s\n' '<html><body>Prices</body></html>' > pages/prices.html
$ bash release.sh
release: no <title> in build/prices.html
[exit status 1]
$ ls dist

The first run packed two pages and listed the archive. In the second, grep -L named the page without a title, the script printed it on standard error and ended with exit statusexit status: The number from 0 to 255 every command ends with, kept by the shell in $?. 0 means success; Bash uses 126 for found but not executable and 127 for not found. More in “Your first script: shebang, chmod and running it” 1 before tar ran, so ls dist showed an empty folder. Nothing in the script computes anything: grep decides, tar packs, and Bash checks the result of each step and stops.

That is the work Google’s shell style guide accepts shell for: “small utilities or simple wrapper scripts” that mostly call other programs and change little data. Typical cases are running commands in order and stopping at the first failure, moving and packing files, short pipelines, the steps of a CI job and the entrypoint script of a container.

So the first question about any task is what it mostly does: when it runs programs and moves files, start in Bash.

One log summary written twice, and what each did with a bad line

Some jobs sit on the line between glue and a program. A web server writes one line per request, with the client, the method, the path, the status and the time in milliseconds, such as 203.0.113.7 GET /checkout 200 182. The summary wanted from 24 such lines: the requests by status class, the three busiest paths, the mean latency and the share of 5xx answers. Here it is in Bash, where cut, sort and uniq count and awk does the sums with decimals:

#!/usr/bin/env bash
# Summarises an access log of lines "client method path status ms": requests by status class, the three busiest
# paths, the mean latency and the share of 5xx answers. Text tools do the counting; awk does the decimals.
set -euo pipefail
log=${1:?usage: log-summary.sh FILE}

printf 'requests: %d\n' "$(wc -l < "$log")"
cut -d' ' -f4 "$log" | cut -c1 | sort | uniq -c | while read -r n c; do printf '%sxx: %d\n' "$c" "$n"; done
echo 'busiest paths:'
cut -d' ' -f3 "$log" | sort | uniq -c | sort -k1,1nr -k2,2 | head -n 3 |
  while read -r n path; do printf '  %s %d\n' "$path" "$n"; done
awk '{ ms += $5; if ($4 >= 500) err++ }
  END { printf "mean latency: %.1f ms\n5xx share: %.1f %%\n", ms / NR, 100 * err / NR }' "$log"

And here it is in Python, which reads the file once and checks each line before it counts it:

"""Summarises an access log of lines "client method path status ms": requests by status class, the three busiest
paths, the mean latency and the share of 5xx answers, exactly as log-summary.sh prints them. A line that does not
have five fields with a numeric status and latency stops the program with its line number."""

import sys
from collections import Counter


def main(argv):
    if len(argv) != 2:
        print("usage: log_summary.py FILE", file=sys.stderr)
        return 2
    name = argv[1]
    classes, paths = Counter(), Counter()
    total = latency = errors = 0
    try:
        with open(name, encoding="utf-8") as log:
            for number, line in enumerate(log, start=1):
                fields = line.split()
                if len(fields) != 5 or not fields[3].isdigit() or not fields[4].isdigit():
                    print(f"{name}: line {number}: expected 'client method path status ms': {line.strip()}",
                          file=sys.stderr)
                    return 1
                _client, _method, path, status, ms = fields
                total += 1
                classes[status[0] + "xx"] += 1
                paths[path] += 1
                latency += int(ms)
                errors += status.startswith("5")
    except OSError as error:
        print(f"{name}: {error.strerror}", file=sys.stderr)
        return 1
    if total == 0:
        print(f"{name}: no requests", file=sys.stderr)
        return 1
    print(f"requests: {total}")
    for status_class in sorted(classes):
        print(f"{status_class}: {classes[status_class]}")
    print("busiest paths:")
    for path, n in sorted(paths.items(), key=lambda item: (-item[1], item[0]))[:3]:
        print(f"  {path} {n}")
    print(f"mean latency: {latency / total:.1f} ms")
    print(f"5xx share: {100 * errors / total:.1f} %")
    return 0


if __name__ == "__main__":
    sys.exit(main(sys.argv))

The session runs both on the log and compares their output, then gives both a copy whose last line has - where the latency belongs:

from session import files, run

# The same summary twice, on one log: log-summary.sh (text tools, with awk for the decimals) and log_summary.py. Then
# both read a copy of the log with one bad line at the end, whose latency is "-" instead of a number, and one awk rule
# shows the check the Bash version would need.
files("access.log", "log-summary.sh", "log_summary.py")
run("""
bash log-summary.sh access.log
bash log-summary.sh access.log > from-bash.txt
python3 log_summary.py access.log > from-python.txt
diff from-bash.txt from-python.txt && echo 'same output'
wc -l log-summary.sh log_summary.py
cp access.log bad.log
echo '198.51.100.9 GET /search 200 -' >> bad.log
bash log-summary.sh bad.log
!python3 log_summary.py bad.log
!awk '$5 !~ /^[0-9]+$/ { printf "bad.log: line %d: latency %s is not a number\\n", NR, $5; exit 1 }' bad.log
""")

$ bash log-summary.sh access.log
requests: 24
2xx: 18
3xx: 1
4xx: 2
5xx: 3
busiest paths:
  /search 8
  /checkout 7
  /products 6
mean latency: 254.3 ms
5xx share: 12.5 %
$ bash log-summary.sh access.log > from-bash.txt
$ python3 log_summary.py access.log > from-python.txt
$ diff from-bash.txt from-python.txt && echo 'same output'
same output
$ wc -l log-summary.sh log_summary.py
      13 log-summary.sh
      48 log_summary.py
      61 total
$ cp access.log bad.log
$ echo '198.51.100.9 GET /search 200 -' >> bad.log
$ bash log-summary.sh bad.log
requests: 25
2xx: 19
3xx: 1
4xx: 2
5xx: 3
busiest paths:
  /search 9
  /checkout 7
  /products 6
mean latency: 244.1 ms
5xx share: 12.0 %
$ python3 log_summary.py bad.log
bad.log: line 25: expected 'client method path status ms': 198.51.100.9 GET /search 200 -
[exit status 1]
$ awk '$5 !~ /^[0-9]+$/ { printf "bad.log: line %d: latency %s is not a number\n", NR, $5; exit 1 }' bad.log
bad.log: line 25: latency - is not a number
[exit status 1]

On the good log the two printed the same bytes: diff found no difference, with 24 requests, a mean of 254.3 ms and a 5xx share of 12.5 %. The Bash script is 13 lines and the Python program 48, and four checks take 14 of the Python lines: the number of arguments, the shape of every line (five fields, numbers in the last two), a missing file and an empty log, each with its own message.

The bad log shows what those checks buy. The Bash version printed 25 requests, a mean of 244.1 ms and a 5xx share of 12.0 %, and ended with status 0. POSIX awk turns a string into a number the way C’s atof does, so the - became 0 and a broken line counted as a very fast request. set -euo pipefail did not stop it, because no command failed. The Python version stopped at line 25, printed the line, and ended with status 1.

One awk rule closes this gap inside the script: the last command of the session checks that the fifth field is made of digits and stops with status 1. A script that needs many such checks shows one of the signs of the next section.

Seven signs that a script has outgrown Bash

The summary needed decimals and careful input checks, two of the reasons people move a script to another language. Step through all seven; each step says what the sessions of this lesson showed or what a cited page says:

The next session tries three of them: Bash’s whole-number arithmetic, floating point in awk and Python, Python’s decimal module, two flat questions about an order in JSON answered by jq, and set -e inside a function that runs as the condition of an if:

from session import run, write

# Three of the warning signs, tried: Bash arithmetic has whole numbers only, a flat JSON question is one jq line, and
# set -e stops nothing inside a function that runs as the condition of an if.
write("order.json", '{"order": "A-1042", "items": [{"sku": "pen", "qty": 3, "price": 12.5}, {"sku": "ink", "qty": 1, "price": 40}]}\n')
run("""
# Bash arithmetic works on whole numbers only
echo $(( 7 / 2 ))
!echo $(( 0.1 + 0.2 ))
# awk and Python use binary floating-point numbers; Python's decimal module keeps decimal fractions exact
awk 'BEGIN { print 0.1 + 0.2; printf "%.17f\\n", 0.1 + 0.2 }'
python3 -c 'print(0.1 + 0.2)'
python3 -c 'from decimal import Decimal; print(Decimal("0.1") + Decimal("0.2"))'
# a flat question about JSON stays one jq line
jq -r '.items[].sku' order.json
jq '[.items[] | .qty * .price] | add' order.json
# set -e is switched off inside a function that runs as an if condition
bash -c 'set -e; check() { false; echo "check went on after false"; }; if check; then echo "check passed"; fi'
""")

# Bash arithmetic works on whole numbers only
$ echo $(( 7 / 2 ))
3
$ echo $(( 0.1 + 0.2 ))
bash: 0.1 + 0.2 : arithmetic syntax error: invalid arithmetic operator (error token is ".1 + 0.2 ")
[exit status 1]
# awk and Python use binary floating-point numbers; Python's decimal module keeps decimal fractions exact
$ awk 'BEGIN { print 0.1 + 0.2; printf "%.17f\n", 0.1 + 0.2 }'
0.3
0.30000000000000004
$ python3 -c 'print(0.1 + 0.2)'
0.30000000000000004
$ python3 -c 'from decimal import Decimal; print(Decimal("0.1") + Decimal("0.2"))'
0.3
# a flat question about JSON stays one jq line
$ jq -r '.items[].sku' order.json
pen
ink
$ jq '[.items[] | .qty * .price] | add' order.json
77.5
# set -e is switched off inside a function that runs as an if condition
$ bash -c 'set -e; check() { false; echo "check went on after false"; }; if check; then echo "check passed"; fi'
check went on after false
check passed

$(( 7 / 2 )) printed 3, and $(( 0.1 + 0.2 )) stopped with an arithmetic syntax error, because the Bash manual defines its arithmetic on fixed-width integers. awk printed 0.3, but only because it prints six significant digits by default: printed with 17 decimal places, the same sum is 0.30000000000000004, which Python printed at once. That is floating pointfloating point: A way of storing numbers with fractions in binary. Most decimal fractions, such as 0.1, have no exact binary form and are stored as the nearest value, so a sum such as 0.1 + 0.2 can print as 0.30000000000000004.: 0.1 has no exact binary form. Python’s decimal module printed 0.3, because it keeps decimal fractions exact. You can try both Python lines in the Python online compiler.

jq answered the two flat questions in one line each: the item names, and a total of 77.5. JSON alone is not the sign; questions that need several jq lines, joins between files or deep nesting are. The last line is the error-handling sign: with set -e on, check went on after false, printed its message, and the if took its then branch. The manual lists the places where set -e is ignored, and the errexit lesson tries each one. A script that is right only for a reader who knows them all is hard to change.

The other signs come from the guide and from the platforms. Google’s guide asks for a rewrite in a more structured language once a script passes 100 lines or its control flow stops being straightforward, and it says to use something other than shell when performance matters: every external program a script runs is a new process, a cost the performance lesson measures. A job that keeps state for hours has only files and variables to keep it in. On Windows, Bash comes only with an add-on that brings a Linux or Unix-like environment, such as the Windows Subsystem for Linux, Git for Windows or Cygwin, while Python installs and runs on Windows itself.

Choosing a tool for a task with four questions

Most tasks are decided by four questions: what the task mostly does, whether Bash may be missing, whether it will grow, and whether Windows users run it. Answer them for a task of your own in the table below. Each rule that rules a tool out says why, with the numbers of this lesson’s sessions:

The same questions settle these ten tasks:

A task often mixes kinds of work: the log summary counted with a pipeline and averaged with awk inside one Bash script, which stays fine while each part is small.

After the switch, call tools with an argument list

A Python program still runs other programs: grep for a quick count, tar, git, or a vendor’s command-line tool. Python’s subprocess module can do that in two ways, and they differ in who reads the arguments. The first program below builds one string and passes shell=True; the second passes a list:

"""Counts ERROR lines with grep, with two slips: the command is one string run by /bin/sh (shell=True), built from the
file name, and check=True treats grep's status 1 ("no line matched") as a failure."""

import subprocess
import sys

for name in sys.argv[1:]:
    try:
        result = subprocess.run(f"grep -c ERROR {name}", shell=True, check=True, capture_output=True, text=True)
        print(f"{name}: {result.stdout.strip()}")
    except subprocess.CalledProcessError as error:
        print(f"{name}: failed with status {error.returncode}")

"""Counts ERROR lines with grep, safely: the arguments go to grep as a list, so no shell reads the file name, and the
status is read the way grep defines it: 0 lines matched, 1 no line matched, 2 or more an error."""

import subprocess
import sys


def count_errors(name):
    result = subprocess.run(["grep", "-c", "--", "ERROR", name], capture_output=True, text=True)
    if result.returncode > 1:
        raise RuntimeError(result.stderr.strip())
    return int(result.stdout)


status = 0
for name in sys.argv[1:]:
    try:
        print(f"{name}: {count_errors(name)}")
    except RuntimeError as error:
        print(f"{name}: {error}", file=sys.stderr)
        status = 1
sys.exit(status)

Both count the ERROR lines of app.log. The session also gives them a log with no ERROR line, and a file whose name is notes; echo injected.log, which Linux and macOS accept as a file name:

from session import files, run, write

# Three logs: one with three ERROR lines, one with none, and one whose file name holds a semicolon. weak_count.py runs
# grep through /bin/sh with check=True; count_errors.py passes a list and reads grep's status itself.
files("weak_count.py", "count_errors.py")
write("app.log", "INFO start\nERROR disk full\nERROR disk full\nINFO retry\nERROR timeout\n")
write("clean.log", "INFO start\nINFO done\n")
write("notes; echo injected.log", "ERROR one line\n")
run("""
ls
python3 weak_count.py app.log clean.log 'notes; echo injected.log'
python3 count_errors.py app.log clean.log 'notes; echo injected.log'
!python3 count_errors.py missing.log
""")

$ ls
app.log
clean.log
count_errors.py
notes; echo injected.log
weak_count.py
$ python3 weak_count.py app.log clean.log 'notes; echo injected.log'
app.log: 3
clean.log: failed with status 1
notes; echo injected.log: injected.log
$ python3 count_errors.py app.log clean.log 'notes; echo injected.log'
app.log: 3
clean.log: 0
notes; echo injected.log: 1
$ python3 count_errors.py missing.log
missing.log: grep: missing.log: No such file or directory
[exit status 1]

With shell=True, Python starts /bin/sh with the whole string, as the subprocess documentation says for POSIX systems, and the shell split it at the semicolon. grep looked for a file named notes and failed, and then the shell ran echo injected.log, a command that came from a file name. The script printed injected.log as the count. With a name that a user typed, that is command injectioncommand injection: A bug where user text is read as shell: a value such as x; touch MARKER arrives through eval, sh -c or unquoted expansion and runs its own commands. The fix is to pass the value as one argument, never splice it into a command string. More in “Injection, eval and untrusted input”. The list version gave grep five strings as its argument listargument list: The separate strings a program receives as its arguments. Passing a list to Python's subprocess.run hands each string to the program as one argument, with no shell to split it or read its special characters., with no shell between them, so the semicolon stayed a character of the name and grep counted 1. Step through both calls:

The other slip was check=True. POSIX defines grep’s statuses: 0 when a line was selected, 1 when none was, and more than 1 for an error. So status 1 on clean.log was a correct count of 0, and check=True turned it into failed with status 1. count_errors.py reads the status itself, treats 2 and above as errors and prints grep’s own message, as the run on missing.log shows. The -- before the pattern ends grep’s options, so a file name that starts with a dash is still read as a file.

The Python track’s subprocess lesson goes on to output, timeouts and errors, and the injection lesson shows the same mistake inside Bash, with eval.

zsh, fish and PowerShell are other languages, not other Bashes

Your terminal may not start Bash at all. Apple’s support page says that since macOS 10.15, new user accounts get zshzsh: The Z shell, the default login and interactive shell for new macOS accounts since macOS 10.15. It reads much Bash syntax but differs in places: by default it does not split unquoted variables, and it numbers arrays from 1. as their login and interactive shell, and it calls zsh highly compatible with sh and mostly compatible with Bash. Mostly is the word to remember. The session runs the same lines in Bash 5.3.20 and in zsh 5.9, then sorts three numbers with sort and with PowerShellPowerShell: Microsoft's shell and scripting language for Windows, Linux and macOS. Its commands pass .NET objects along the pipeline instead of lines of text, so it sorts numbers as numbers. 7.6.6:

from session import run

# The same lines in Bash 5.3.20 and in zsh 5.9 (zsh -f reads no startup files), then sorting in Bash's sort and in
# PowerShell 7.6.6, which passes objects rather than text from one command to the next.
run("""
zsh --version
files="a.txt b.txt"; for f in $files; do echo "[$f]"; done
zsh -fc 'files="a.txt b.txt"; for f in $files; do echo "[$f]"; done'
list=(x y z); echo "${list[1]}"
zsh -fc 'list=(x y z); echo $list[1]'
pwsh --version
printf '%s\\n' 3 10 2 | sort
pwsh -NoProfile -NonInteractive -Command "'3', '10', '2' | Sort-Object"
pwsh -NoProfile -NonInteractive -Command "3, 10, 2 | Sort-Object"
""")

$ zsh --version
zsh 5.9 (arm64-apple-darwin25.0)
$ files="a.txt b.txt"; for f in $files; do echo "[$f]"; done
[a.txt]
[b.txt]
$ zsh -fc 'files="a.txt b.txt"; for f in $files; do echo "[$f]"; done'
[a.txt b.txt]
$ list=(x y z); echo "${list[1]}"
y
$ zsh -fc 'list=(x y z); echo $list[1]'
x
$ pwsh --version
PowerShell 7.6.6
$ printf '%s\n' 3 10 2 | sort
10
2
3
$ pwsh -NoProfile -NonInteractive -Command "'3', '10', '2' | Sort-Object"
10
2
3
$ pwsh -NoProfile -NonInteractive -Command "3, 10, 2 | Sort-Object"
2
3
10

zsh did not split $files at the space, so its loop ran once with a.txt b.txt where Bash’s ran twice. The zsh manual explains both differences: splitting unquoted parameters needs its SH_WORD_SPLIT option, and arrays count from 0 only with KSH_ARRAYS, so $list[1] was x in zsh while ${list[1]} was y in Bash. A script that relies on either behaviour gives another answer in the other shell, without any error.

fishfish: The friendly interactive shell, whose scripting language is intentionally not POSIX-compatible: it has no word splitting, no [[ and no ${var:-default}, so Bash and sh scripts do not run in it unchanged. goes further. Its guide for Bash users says it is intentionally not POSIX-compatible: it does no word splitting and has no [[ and no ${var:-default}. PowerShell, Microsoft’s shell for Windows, Linux and macOS, passes .NET objects along its pipeline instead of lines of text. That is why it sorted the numbers 3, 10, 2 as 2, 3, 10, while the strings ‘3’, ‘10’, ‘2’ came out 10, 2, 3, the order Bash’s sort gave, because sort compares text.

The table adds dash, which Ubuntu runs as /usr/bin/sh, and says where you meet each shell:

Use any of them at the prompt. For a script that other people run, the first line decides the shell, not anyone’s login shell: name Bash with #!/usr/bin/env bash, or keep to POSIX sh as the POSIX sh lesson shows.

When in doubt, keep a thin Bash wrapper around a program

Moving the logic into a program does not mean asking everyone to type a new command. A wrapper scriptwrapper script: A short script whose only job is to start another program under a familiar name: it finds the program, checks what it needs and hands over, often with exec and "$@", so the arguments and the exit status pass through unchanged. keeps the old name, finds the program, checks that what it needs is installed and hands over. This one is 7 lines and starts the log summary of the second section:

#!/usr/bin/env bash
# A thin wrapper: it finds the program next to itself, checks that Python is there, and hands over with exec, so the
# arguments arrive unchanged and the program's exit status becomes the wrapper's.
set -euo pipefail
here=$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)
command -v python3 > /dev/null || { echo 'summary: python3 is not installed' >&2; exit 127; }
exec python3 "$here/log_summary.py" "$@"

The session installs it as summary, calls it from another folder with a file name that holds a space, with no file and with a missing file, and then checks that exec keeps one process:

from session import files, run

# The wrapper summary.sh, copied in as summary, runs log_summary.py with exec. It is called from another folder, with
# a file name that holds a space, with no file at all and with a missing file, and once more to show that exec leaves
# one process: the shell's PID becomes Python's.
files("summary.sh=summary", "log_summary.py", "access.log=my logs/access.log")
run("""
chmod +x summary
mkdir elsewhere && cd elsewhere
../summary '../my logs/access.log'
!../summary
!../summary missing.log
cd ..
bash -c 'export WRAPPER_PID=$$; exec python3 -c "import os; print(os.getpid() == int(os.environ[\\"WRAPPER_PID\\"]))"'
""")

$ chmod +x summary
$ mkdir elsewhere && cd elsewhere
$ ../summary '../my logs/access.log'
requests: 24
2xx: 18
3xx: 1
4xx: 2
5xx: 3
busiest paths:
  /search 8
  /checkout 7
  /products 6
mean latency: 254.3 ms
5xx share: 12.5 %
$ ../summary
usage: log_summary.py FILE
[exit status 2]
$ ../summary missing.log
missing.log: No such file or directory
[exit status 1]
$ cd ..
$ bash -c 'export WRAPPER_PID=$$; exec python3 -c "import os; print(os.getpid() == int(os.environ[\"WRAPPER_PID\"]))"'
True

"$@" passed ../my logs/access.log as one argument, space included, and the summary printed the same eleven lines as before. With no file, the usage line and status 2 came from Python, and with a missing file, its message and status 1. Bash added nothing to either because of the last line: the Bash manual says that exec with a command replaces the shell without creating a new process. The last command of the session printed True, because the process ID before exec was the process ID of Python afterwards. Step through one call:

This is the plan that helps most when you are unsure: keep the name people type and a wrapper of a few lines in Bash, and move the logic into a program with tests. The people and the scheduled jobs that call the command see no change, and the program can grow as far as it needs.

Practise: pick the tool, then defend it

Each question names a task or a line from the sessions above. Choose the tool or the result, then read why each answer is right or what it misses:

Interview questions

Warm-up (fresher to 2–5 years): when is a shell script the right tool, and what are the signs that it should become a program?

A shell script is the right tool when the work is mostly running other programs: commands in order with a stop at the first failure, moving and packing files, short pipelines, CI steps and small wrappers. The signs that it should become a program are nested data beyond one jq line, decimals (Bash arithmetic has whole numbers only), error handling with many cases, state that lasts for hours, users on Windows, speed that matters, and more than about 100 lines, the limit Google’s shell style guide sets. One sign can often stay in the script, as awk can take a mean; when two or more hold, move the logic into Python and keep a thin Bash wrapper.

Warm-up (2–5 years): why does subprocess.run take a list of arguments, and when is shell=True a problem?

A list goes straight to the program: each string becomes one argument and no shell reads it, so spaces, semicolons and $( ) stay plain characters. With shell=True, Python starts /bin/sh with one string and the shell decides where words and commands end; in the recorded run a file named notes; echo injected.log made it run echo as a second command. Built from user input, such a string is command injection. Pass a list, put -- before values that might start with a dash, and read each tool’s statuses yourself: grep’s 1 means no match, which check=True treats as a failure.

Two harder questions go past this page: planning the move of a long release script into Python so that no release breaks, and porting a compressed-log pipeline into a Python service. Settle your first step before you open each one:

Key takeaways

• Bash is at its best gluing programs together: release.sh ran cp, grep and tar in order and stopped with status 1 at the first page without a title.
• The same log summary took 13 lines of Bash and 48 of Python, 14 of them checks, and only Python stopped at the bad line instead of averaging in a 0.
• Seven signs say a script has outgrown Bash: nested data, decimals, many error cases, lasting state, Windows users, more than about 100 lines, and speed; one can be handled in place, two or more call for a program.
• Four questions decide most tasks: what it mostly does, whether Bash may be missing, whether it will grow and whether Windows users run it.
• From Python, pass subprocess.run a list and read each tool’s statuses yourself; one string with shell=True let a file name run a command.
• zsh, fish and PowerShell are other languages, so scripts for others are Bash or POSIX sh, and a thin wrapper ending in exec keeps the command when the logic moves into a program.