[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Sun, Oct 24, 1999 at 09:23:46AM -0400, Raul Miller wrote:
> 
> I think you've confused several issues.

I may be confused, but you appear to be confused too :)

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

It's not a draft, it's a standard approved by IEEE and ISO.

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

A POSIX compliant script certainly can use escape codes.  But it must not
rely on -n.  A POSIX compliant shell must support escape codes, and may or
may not do -n.

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

Remember very few people outside Debian actually uses ash, that means the
only shell they've got is bash.  So it's not surprising to see them exploit
its features.  Case in point, the kernel source have long used bashisms like
type, {} expansion, and other things.  That certainly didn't mean ash had to
do those.

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

But if ash is not /bin/sh, what is it supposed to do? Remember that no one
actually writes #!/bin/ash scripts.

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

So I guess what you are saying is that you'd be in favour of chaning our
policy so that #!/bin/sh scripts do not have to be POSIX compliant.  Well,
in that case, I've got nothing more too say.

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

Well, once again, it's a POSIX standard.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Reply to: