Re: [PATCH] latest ash has broken 'echo' command
On Sat, Oct 23, 1999 at 02:11:11PM -0400, Raul Miller wrote:
> > Here's my take on this issue:
> >
> > (1) POSIX.
> > POSIX says you should use printf for new scripts but that echo
> > has not been made obsolete because it's in such widespread use.
> >
> > (2) SUS.
> > In general the linux community seems to treat SUS as advise
> > rather than as a "must meet" standard.
> >
> > (3) ash.
> > We have a large user base, some of whom have come to rely on
> > the current behavior of ash.
On Sun, Oct 24, 1999 at 01:08:07PM +1000, Herbert Xu wrote:
> You miss the point completely. The issue here is whether our #!/bin/sh
> scripts should be POSIX compliant or not. If the answer is yes, the
> change in ash will be OK once our scripts are fixed. If the answer is
> no, nobody should use ash as /bin/sh because it won't be possible.
Once again:
We have a large user base, some of whom have come to rely on the current
behavior of ash.
I understand that the upstream source has a different implementation.
However, our implementation of ash has been changed and that has set a
new standard -- one which we do have some obligation to support.
There's nothing wrong with the debian fork of ash, from the POSIX point
of view. There's nothing wrong with the upstream form of ash, from the
POSIX point of view. They're just different.
If it makes sense for debian scripts to be fixed, it doesn't mean that
the behavior of ash must be changed. There are other ways to achieve
that end.
> > In other words, ash should not have changed its behavior. The changed
> > behavior doesn't solve any real problem but it does break working user
> > systems. [Specifically, anyone who has set up ash as /bin/sh.]
>
> I admit the change was not a good idea at this moment in time. What
> I will do once potato is released is to include two copies of ash in
> the binary package, one that has an echo with options, and one without
> options. This will help us track down #!/bin/sh scripts that aren't
> POSIX compliant. Of course, this is assuming that we actually want
> #!/bin/sh to be POSIX compliant.
If your goal is strict compliance with the POSIX draft then the newly
introduced ash should exit with an error, and an error message if there
are any backslash (\) characters in the argument (and that error message
should be locale specific). And there are probably similar changes that
should be made in other aspects of that program.
Of course, that's subject to change: we're not talking about conformance
to a POSIX standard here. We're talking about conformance to a POSIX
draft. So presumably your "ash-strict" would be changed as new drafts are
released [and to strictly enforce other aspects of strict POSIX behavior,
beyond echo].
--
Raul
Reply to: