sed Best Practices

sed is deceptively terse: a working one-liner can look like line noise, and a subtle mistake can silently corrupt every file it touches. Best practices are about making sed commands predictable, reviewable, and reversible. The core disciplines are testing before writing, being explicit about delimiters and anchors, and never assuming your GNU sed flags will exist on someone else's machine.

The most damaging sed mistake is running the -i (in-place) flag on a bad command. The safe workflow is to run without -i first, review the output, then add -i once you trust it. When you do edit in place, use a backup suffix: GNU sed accepts -i.bak, which writes the original to file.bak. BSD/macOS sed requires an explicit argument, even an empty one, so -i '' is mandatory there — this single difference breaks more portable scripts than any other.

The substitute command s/// lets you pick any delimiter, so when your pattern contains slashes — like file paths or URLs — switch to s|old|new| or s#old#new# to avoid a thicket of backslash escapes. Equally, anchor your patterns: ^ and $ prevent a rule meant for a whole line from matching a fragment, and word boundaries keep 'cat' from matching inside 'category'. Being explicit here is the difference between a rule that does exactly one thing and one that quietly mangles unrelated text.