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.
On Mon, Oct 25, 1999 at 12:10:11AM +1000, Herbert Xu wrote:
> I may be confused, but you appear to be confused too :)
That's entirely possible.
> > 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.
Yeah, it looks like P1003.2 was approved in Sept 92.
<http://www.pasc.org/standing/sd11.html> P1003.2a has
also been approved, and there's work underway on P1003.2b
<http://www.pasc.org/standing/sd6.html>
Anyways, if you have text that is supposed to be a final standard and it
says something other than echo's support for \ or -n is implementation
defined, could you quote that fragment and indicate what the standard
is?
It's surprising, but entirely possible, for the final standard to say
something different from the drafts.
> > 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.
Quote please.
> > 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.
That was before we fixed up debian enough so that people could use ash
as /bin/sh.
> > 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.
Exactly my point.
> > 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.
I'm saying it's a valid option, given the current situation. I don't
know that it's the best option. But at this point I think we both
understand the basic issues and the only thing up in the air is: what
does the standards text really say?
Thanks,
--
Raul
Reply to: