Frank Seifferth <seiffe...@cl.uni-heidelberg.de> writes: > On Thu, 21 Oct 2021 08:46:17 -0600 Glenn Golden <g...@zplane.com> wrote: >> ----------------------------------------------------------------------------- >> 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). >> ----------------------------------------------------------------------------- >> >> Something like this seems to get the job done: Briefly states the issue, >> why it exists, provides a workaround, and cheerleads for modernization. > > This note does seem to be in order and it will certainly benefit everyone > who may read the manpage.
I completely agree. > It is not entirely accurate, however. `echo`, when run with the `-e` > option, does allow backslash escapes for arbitrary octal and > hexadecimal representations of character codes. Hence both of the > following commands will produce the string `-n` as output: > > echo -e '\0055n' > echo -e '\x2dn' Haha, nice catch. > For the sake of correctness, one might want to reword the note somewhat > like this: > > 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). Indeed, this is beautiful. Regards, Florent
