This is a good example of why POSIX recommends using printf
instead of echo
(see here, under "application usage"): you don't know what you get with echo
1.
You could get:
- A shell builtin
echo
that does not interpret backslash escapes by default
- Example: the Bash builtin
echo
has an -e
option to enable backslash escape interpretation and checks the xpg_echo
shell option
- A shell builtin
echo
that interprets backslash escapes by default
- A standalone executable
/bin/echo
: probably depends on which one – GNU Coreutils echo
understands the -e
option, like the Bash builtin
The POSIX spec says this (emphasis mine):
The following operands shall be supported:
string
A string to be written to standard output. If the first operand is -n
, or if any of the operands contain a <backslash>
character, the results are implementation-defined.
So, for a portable solution, we can use printf
:
printf '%s
' 'part1
part2' >> file
where the
in the format string will always be interpreted, and the
in the argument will never be interpreted, resulting in
part1
part2
being appended to file
.
1 For an exhaustive overview of various behaviours for echo
and printf
, see echo(1) and printf(1) on in-ulm.de.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…