Bob Proulx <b...@proulx.com> writes:
> To be totally honest I thought echo was already very well documented.
> And I thought we already were strongly recommending people to use
> printf for arbitrary data. Therefore honestly I thought by agreeing I
> thought we were done.
I do not agree. The only recommendation to use printf that I found is in
the "echo invocation" page of the coreutil info documentation. And this
is what it says:
POSIX does not require support for any options, and says that the
behavior of ‘echo’ is implementation-defined if any STRING contains a
backslash or if the first argument is ‘-n’. Portable programs can use
the ‘printf’ command if they need to omit trailing newlines or output
control characters or backslashes. *Note printf invocation::.
And I believe that this paragraph misses the point. It suggests that the
only issue with "echo" is a portability issue, and that only portable
programs should use "printf". My point is that even without considering
portability, users shouldn't use the echo command to process arbitrary
strings.
IMHO, the two notes sent by Glenn Golden and Frank Seifferth are much
more accurate to describe the issue, and provide a real reason (besides
portability) for programmers to use printf rather than echo.
Also, as far as I could see, users tend to read only the "echo --help"
message to grasp the usage of a command. Some of them may look at the
man page to get more details. Only few read the info
documentation. Therefore, to help the community to write robust
programs, I believe that an accurate explanation of the echo command
caveats should be displayed in the man page, if not in the --help
message. I believe that good software deserves accurate documentation.
These are the 2 great notes that describe the issue with the echo
command.
note by Glenn Golden:
-----------------------------------------------------------------------------
NOTE
For historical and back-compatibility reasons, certain bare option-like
strings cannot be emitted without setting POSIXLY_CORRECT, and the bare
string '-n' cannot be emitted at all. Prefixing or suffixing such strings
with quoted whitespace (e.g. ' -n') can be used as a workaround for this
peculiarity. More generally, printf(1) is recommended as a more modern
and flexible replacement for tasks historically performed by echo(1).
-----------------------------------------------------------------------------
note by Frank Seifferth:
For historical and back-compatibility reasons, certain bare option-like
strings cannot be passed to echo as non-option arguments. The only way
to echo the string '-n', for instance, is to specify the dash in either
octal or hexadecimal representation (e.g. 'echo -e "\x2dn"'). It is
therefore not advisable to use echo(1) for printing unknown or variable
arguments. More generally, printf(1) is recommended as a more modern
and flexible replacement for tasks historically performed by echo(1).
Regards,
Florent
