On Tue, 2021-10-19 at 01:06 -0600, Bob Proulx wrote:
> Florent Flament wrote:
> > Out of curiosity, would it possible to have the `echo` command
> > output the string "-n" ?
> >
> > ```
> > $ POSIXLY_CORRECT=1 /bin/echo -n
> > ```
>
> But the standards do actually mention -n. The behavior you see with
> POSIXLY_CORRECT=1 is conforming behavior.
>
>
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html#tag_20_37
>
> If the first operand is -n, or if any of the operands contain a
> <backslash> character, the results are implementation-defined.
I agree that the GNU echo command complies with the sentence mentioned
above, when using the POSIXLY_CORRECT flag.
However, I believe that the use of "shall not" makes the POSIX echo
definition ambiguous:
The echo utility shall not recognize the "--" argument in the
manner specified by Guideline 10 of XBD Utility Syntax Guidelines;
"--" shall be recognized as a string operand.
Implementations shall not support any options.
In the case of '--', "shall not" seems to mean "is forbidden to",
because '--' "must" be recognized as a string operand. In the case of
options, "shall not" seems to mean "don't have to", because it is then
mentioned that the behavior is implementation dependent when using the
'-n' flag.
That said, I believe that the POSIX echo definition is broken, because
it tried to reconcile incompatible existing implementations.
The two different historical versions of echo vary in fatally
incompatible ways.
> Unix v7 echo accepted -n as an option and did not print it. Same
> with BSD. It is too late to mess with it now.
Then these implementations are broken as well. Also, I can understand
that one may not want to change the behavior of a command that has
been used for 30 years.
> On a practical level why is it an issue at all? If there is any
> concern about printing -n then use 'printf' as that is a much better
> solution for arbitrary strings.
On a practical level, I have seen the 'echo' command being used in
many shell scripts to process arbitrary strings. Which means that in
some cases (when processing the strings "-n", "-e" or "-E") these
scripts won't behave as expected by the programmer. I agree that
'printf' should have been used instead, but it seems that programmers
have been taught to use 'echo' to print strings in shell scripts for
many years (that's my case as well).
> Also note that most shells include 'echo' as a builtin command which
> will be different from the coreutils standalone executable. Most
> users should look to their shell for their echo implementation
> instead.
That is also true, though chances are that the shell builtin
implementations of 'echo' be probably inspired (if not copied) from
the GNU echo implementation.
What I would expect from a good implementation of the 'echo' command
is to interpret the '--' argument to signify the end of the options,
therefore removing any ambiguity in the interpretation of the strings
to display. That would be the (non-posix) default behavior. Then the
command would have a POSIX compliant behavior with the POSIXLY_CORRECT
flag, which wouldn't interpret any option at all.
Besides, I understand that the current implementation of the GNU
'echo'
command has been used for several decades now, and that it may
be
difficult to change its behavior. In which case, thoroughly
documenting
the edge cases of the 'echo' command and inviting
programmers to use
'printf' instead on its manpage (I know 'printf' is
mentioned on the
coreutils info page, but it's one additional level of
indirection) would
probably be helpful for the community. I'd gladly
try to update the
manpage if that be the way to go.
Regards,
Florent Flament
