Re: [PATCH] latest ash has broken 'echo' command

[Raul Miller <moth@debian.org>]

On Sun, Oct 24, 1999 at 07:06:36PM +1000, Herbert Xu wrote:
> > POSIX.2 specifies that an echo command MAY support options.  How does
> > ash's echo command supporting options break POSIX.2?
> 
> Because POSIX says that you must not do -e, and you may support -n but it
> is optional.  Thus any POSIX compliant script cannot use options but may
> use escape codes *without* specifying -e.

I think you've confused several issues.

I agree that the draft says you can't use -e, and I have no expectation
that that will change, and I don't think echo -e gets much use.  However:

A POSIX compliant *script* cannot rely on -n working nor may it use
escape codes.  A POSIX compliant implementation of */bin/sh* is allowed
to support escape codes, OR it's allowed to support the BSD -n, OR it
may do neither.

Debian has a history of supporting this kernel called "Linux" (you
might have heard of it).  At the moment, building this kernel requires
a /bin/sh which supports echo -n.

If ash is not installed as /bin/sh then POSIX has nothing to say about
what ash does or does not implement. So in a debian ash package, POSIX
conformance does not really matter for an ash which is not suitable as
a debian /bin/sh.


                             * * * * *

If we decide to stick with POSIX on the issue of how echo behaves -- and
by we I also include the LSB and linux kernel folks -- then I approve of
the idea of putting together a package for testing strict conformance
to POSIX in /bin/sh and fixing all debian packages which fail when
tested with that shell as /bin/sh.  But at the moment, I see no such
general acceptance of this idea.  [It's still ok to put together such a
package, but I think it's better to see how some of the other parts of
the community react before we start filing bug reports.]

And, once again: we're talking about a POSIX draft here, not a POSIX
standard.  It's not a good idea to break existing practice based
on a draft standard -- especially not when your existing practice is
supportable according to that draft standard.  The time when the standard
is in draft form should be used to decide how to gracefully deal with
migration issues.

-- 
Raul