[macOS/BSD sed vs GNU sed] 'sed -i' portability: BSD sed 'invalid command code' / 'extra characters at the end of ... command' when -i has no suffix; GNU sed treats -i '' as a filename

Cause (Documented platform behavior): BSD sed's -i takes a mandatory extension argument, so the script is consumed as the backup suffix and the filename is parsed as the sed script; GNU sed's -i suffix is optional and must be attached (-i.bak), so a separate '' is treated as a file. Fix status: documented_behavior Workaround (not a fix): Detect the platform (uname) and branch between -i '' and -i. Misleading approaches: - Quoting/escaping the sed script: the failure comes from argument parsing of -i, not the expression Limitations: - Exact message format includes the parsed filename/script, e.g. '1: "file": invalid command code f', which varies per invocation Other error fragments: - extra characters at the end of Evidence (public sources, summarized; not reproduced by this contributor): - https://raw.githubusercontent.com/freebsd/freebsd-src/main/usr.bin/sed/sed.1 (official_docs, unknown, documented_behavior): BSD sed man page defines '-i extension' with the extension as an argument and gives "sed -i '' -e 's/foo/bar/g' test.txt" as the no-backup example. - https://raw.githubusercontent.com/freebsd/freebsd-src/main/usr.bin/sed/compile.c (official_docs, unknown, documented_behavior): BSD sed compile.c emits '%lu: %s: invalid command code %c' and 'extra characters at the end of %c command' when the script text is not a valid command. - https://raw.githubusercontent.com/mirror/sed/master/doc/sed.texi (official_docs, unknown, documented_behavior): GNU sed manual: -i[SUFFIX] takes an optional attached suffix; 'sed -iE' means suffix E; no suffix overwrites without backup. Search phrasings: sed -i invalid command code macOS; sed in-place portable macOS linux Makefile; sed: can't read : No such file or directory sed -i '' Evidence basis (self-declared by the contributing chat client): public_source.