Topic: shell
-
find and xargs exit codes: find's coarse 0/>0 versus xargs's 123-127 ladder
find only promises 0 for full success and any value above 0 for an error, deliberately without finer detail, while xargs defines a specific ladder for how the invoked command failed: 123 for an ordinary non-zero exit, 124 for exit 255, 125 for killed-by-signal, 126 for not-invocable, and 127 for not-found. Piping find into xargs means checking two different exit-code philosophies in one pipeline.
-
zsh as the macOS default shell: what breaks in a script written for bash
macOS has used zsh as the default login and interactive shell since macOS 10.15; a script that assumes bash's word-splitting, zero-based arrays or forgiving globbing can behave differently or fail outright under an agent's interactive zsh session on a Mac, even before /bin/bash's own age is considered.
-
grep, diff, cmp and test/[: exit code 1 means not-found, not failure
grep, diff, cmp and the test/[ builtin all use the same three-way scale: 0 for a positive result, 1 for a negative result that is not an error, and 2 (or >1) for real trouble. Reading 1 as a script failure is the most common misreading an agent makes with these tools.
-
grep and ripgrep for code search: recursion, filters and exit codes
GNU grep searches recursively with -r, narrows with --include and --exclude-dir and exits 0, 1 or 2 for match, no match or error; ripgrep does the same by default while skipping git-ignored, hidden and binary files. Know what each tool skips before trusting an empty result.
-
Locale and date pitfalls in coreutils: LC_ALL, character ranges and GNU versus BSD date
The locale silently changes sort order, what [a-z] matches, decimal separators and the default date format; scripts should set LC_ALL=C (or C.UTF-8) and TZ explicitly, request explicit date formats, and avoid GNU-only date -d or BSD-only date -v unless the platform is known.
-
sort, uniq and comm: set operations on text that depend on sorted input
uniq only collapses adjacent duplicates, comm requires both inputs sorted in the same collation, and sort's order follows LC_COLLATE; run such pipelines under LC_ALL=C, pick the right key options (-n, -h, -V, -k, -t) and use comm -12 and comm -23 for intersections and differences.
-
"exec format error" and "cannot execute binary file": architecture and shebang mismatches
The kernel's ENOEXEC error surfaces as 'exec format error' or 'cannot execute binary file: Exec format error' when the CPU architecture does not match or a script lacks a usable shebang; CRLF line endings in the shebang cause a related 'bad interpreter' or 'required file not found' failure. The article shows how to tell them apart with file(1) and fix each without guessing.
-
find and xargs without surprises: null-separated names, -exec + and dry runs
File names may contain spaces and newlines, so pass them from find to other programs with -print0 and xargs -0 (or find -exec ... {} +), test the selection with -print before adding -delete, and use xargs -r so that an empty list runs nothing.
-
Working with JSON on the command line with jq
jq reads JSON, applies a filter and prints the result: use -r for plain strings, -c for one object per line, --arg and --argjson to pass values in safely, -e to turn null or false into an exit code, and select, map and to_entries to reshape; never assemble filters by string concatenation.
-
Writing shell scripts that fail safely
Use set -euo pipefail, quote every expansion, prefer [[ ]] and arrays, check tools with ShellCheck, and avoid parsing ls; a script that stops on the first error is easier to trust than one that continues.
-
A day-one setup script that verifies itself: bootstrap, doctor, smoke test
One command after cloning either produces a working environment or a precise list of what is missing and how to fix it: a read-only doctor script checks every requirement, an idempotent bootstrap installs only what the checks report missing, and a smoke test decides the exit status; CI runs it from a clean machine so it cannot rot between newcomers.
-
"Argument list too long" (E2BIG) and the ARG_MAX limit
A shell command that expands to too many arguments fails with 'Argument list too long', the E2BIG error from execve(2) hitting the kernel's ARG_MAX ceiling. The article shows how to measure the limit and replace a failing glob with xargs or find's -exec ... + batching instead of trying to quote around it.
-
sed and awk for line-oriented edits: substitution, fields and in-place changes
sed applies editing commands, chiefly s/regexp/replacement/, to each line; awk splits lines into fields and runs pattern-action pairs. Use sed for substitutions and deletions, awk for column work and small aggregations, and handle -i, -n and GNU-versus-BSD differences deliberately.
Machine-readable: JSON