A shell script prints messages with `echo "$msg"`. Why do portability-conscious authors replace that with `printf '%s\n' "$msg"`, and what actually breaks when the same script runs under a different shell?

## echo is under-specified on purpose The POSIX specification for `echo` is unusually weak: it says that the handling of a `-n` first operand and of backslash escape sequences is implementation-defined, and an XSI-conformant `echo` is required to *expand* escapes such as `\n`, `\t` and `\c` while treating `-n` as ordinary text. Two conforming shells can therefore produce different output for the same command, and both are right. That is the whole problem: `echo` is not a portable interface, it is a family of similar commands sharing a name. ## What the implementations actually do - **bash's builtin**: prints its arguments literally. `-n` suppresses the trailing newline, `-e` turns escape interpretation on, `-E` turns it off. `shopt -s xpg_echo` flips the default so escapes are expanded without `-e`. - **dash's builtin** (dash is `/bin/sh` on Debian and Ubuntu): always expands backslash escapes, and has no `-e` — passing `-e` prints the literal string `-e`. - **BSD `/bin/echo`** (macOS): supports `-n`, has no `-e`, and does not expand escapes. - **GNU coreutils `/bin/echo`**: escapes only with `-e`. So this script prints two different things depending on the interpreter: ```bash msg='C:\temp\new' echo "$msg" # bash: C:\temp\new dash: C:<tab>emp<newline>ew ``` That is not a cosmetic difference. Windows paths, regular expressions, TeX fragments and JSON snippets all contain backslashes, and a script that mangles them under one `/bin/sh` and not another is a genuinely painful bug to chase. ## The leading-dash trap Even within one shell, `echo` cannot faithfully print arbitrary data: ```bash flag='-n' echo "$flag" # bash prints nothing at all printf '%s\n' "$flag" # prints -n ``` Quoting does not help, because the shell has already finished quote removal by the time `echo` inspects its first argument. There is no portable way to make `echo` print a value that might begin with a dash — the interface simply lacks the escape hatch. ## What printf gives you instead `printf` is specified in detail. It takes a format string and arguments; escape sequences are interpreted **only** in the format, and the format is reused until the arguments are exhausted: ```bash printf '%s\n' one two three # prints three lines printf 'name=%s age=%d\n' bob 42 ``` That reuse property is genuinely useful: `printf '%s\n' "${arr[@]}"` emits one array element per line with no loop. And because the data goes through `%s`, its content is never reinterpreted — dashes, backslashes and newlines all come out exactly as they went in, in every shell. ## The one printf trap `printf` is safe only if the format is a literal you wrote: ```bash user_input='100% done' printf "$user_input\n" # broken: % begins a conversion specifier printf '%s\n' "$user_input" # correct ``` Passing data as the format is the shell's version of a format-string bug. It produces garbage output at best, and if the value comes from outside the script it is a data-driven defect a reviewer should flag on sight. The habit that makes this impossible is: the format string is always a single-quoted literal, and every dynamic value is an argument. ## Being honest about when echo is fine Don't over-claim in an interview. `echo` with a fixed literal that contains no backslashes and no leading dash, in a script you know runs under bash, is fine and universally readable. The rule earns its keep for *variables*, for anything a user or another program supplied, and for `#!/bin/sh` scripts where you do not control which shell interprets them. Writing to standard error follows the same shape: `printf '%s\n' "error: $reason" >&2`.