Re: feature request: echo --

[Bob Proulx]

Florent Flament wrote:
> Bob Proulx wrote:
> 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.

That seems fairly unambiguous to me.

> 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.

The "-n" in the "string" position is listed specifically as an
exception to the general rule previously stated.  Basically an
interpretation might be don't implement getopt option processing in
general but look specifically at the first argument for this specific
case, it being implementation defined.

> That said, I believe that the POSIX echo definition is broken, because
> it tried to reconcile incompatible existing implementations.

Originally POSIX was not the design document it has become in later
years.  Originally POSIX was an operating system feature
non-proliferation treaty trying to keep the differences among systems
from becoming even more different.  At the time it was created there
were already two major flavors of echo on different systems.  And it
was already a portability problem.  Therefore the standard tried to
freeze the common feature set and allow the existing differences.

> > 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.

That point is similar to saying that one should choose their parents
better.  It may be true!  But it is pointless because one does not
have the possibility of choosing their parents.

And similarly when echo was originally created it was done without the
benefit of 50 years of hindsight looking back at the problems the
choices made then have caused over the years and still continue to
cause now.

> Also, I can understand that one may not want to change the behavior
> of a command that has been used for 30 years.

That's the main point of the discussion.  It's been 50 years and some
expectation of stability should be maintained.

On the other hand if people want to fix everything then I think they
should be free to create their own new operating system and do so
there.  That's fine.  New systems don't have legacy and don't need to
be backward compatible.  So break whatever you want there.  But don't
break the existing system for others along the way.

> > 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.

Then those are the bugs to have fixed.

> 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).

I still use echo to this very day.

    echo "Hello world!"

But that does not include any options and does not include any
backslash escape sequences.  If it did or if there was any possibility
of it doing so then I would program it differently.

    printf "What do you want me to say? "
    IFS= read -r phrase
    echo $phrase  # Noooo!

    printf "What do you want me to say? "
    IFS= read -r phrase
    printf "%s\n" "$phrase"  # Yes!

The above shows input from an untrusted source.  It's "tainted".  It
should not be used without caution.

> > 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.

Actually no.  Their behaviors were based upon existing echo
implementations that pre-date GNU echo that GNU echo was itself also
based upon.

> 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.

Please no.  That would create yet another different behavior case.  It
would be yet again one of the different odd unusual unique things that
would need to be programmed around with horrid code.  Plus we have
already been there and done that.  The result of which was "printf"
which was created as the answer to the problem.

> 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.

Yes.  A very long time.  Try 50 years of "echo"!

> 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.

That's an excellent idea.  I agree completely.  We should document
echo behavior and invite programmers to use printf instead. :-)

Bob