Re: feature request: echo --

[Florent Flament]

Bob Proulx <bob@proulx.com> writes:

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

Ok, this looks like a reasonable interpretation. Though in my mind,
exceptions need to be more explicit (like in "Hey ho ! Beware ! This is
a EXCEPTION ! ..."). Otherwise I tend to see "Don't do X. When doing X
do Y" as an inconsistency.

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

I trust you on this.

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

Ok, I understand your point.

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

I'm not there yet ; )

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

Indeed, 'printf' for the win ! (Like in "if you can't fix something use
something else" ; )

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

Indeed, this looks like a fair use of echo and printf.

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

Ok, I trust you on this one as well.

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

Fair enough.

>> 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"!

Didn't think an issue could last that long ; )

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

Let's do that then.

Cheers,
Florent