Exercise 2: Walking Through the BSD `sed -i` Gotcha — Possible Solution
====================================================================

WHAT HAPPENS STEP BY STEP
------------------------------
Running `sed -i 's/foo/bar/' file.txt` on macOS's BSD sed fails because BSD's `-i` flag REQUIRES an explicit suffix argument for a backup file - it is not optional the way it is in GNU sed. Since no suffix was actually supplied, BSD sed instead consumes the very next argument, `'s/foo/bar/'` (the intended sed script), as that required backup suffix. That leaves `file.txt` as the next argument, which BSD sed then tries to interpret as the actual sed script/command - and since "file.txt" isn't valid sed syntax, this produces an error (or, in some cases, unexpected/incorrect behavior) rather than performing the intended find-and-replace.

WHICH ARGUMENT GETS MISINTERPRETED AS WHAT
------------------------------
`'s/foo/bar/'` (meant to be the sed script) gets misinterpreted as the backup-file suffix, and `file.txt` (meant to be the target file) gets misinterpreted as the sed script itself.

THE FIX
------------------------------
Supply an explicit empty-string suffix argument to mean "no backup": `sed -i '' 's/foo/bar/' file.txt`. The empty `''` satisfies BSD sed's requirement for a suffix argument (telling it not to create a backup file), leaving the sed script and target file correctly positioned as the next two arguments.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly traces which argument gets consumed as the (missing) backup suffix and which gets misread as the sed script as a direct result, and gives the correct fix (an explicit empty-string suffix) rather than just stating that the command "doesn't work" on macOS.