Re: [PATCH] latest ash has broken 'echo' command
Chris Lawrence <quango@watervalley.net> wrote:
> On Oct 24, Herbert Xu wrote:
>>
>> We're doing this because ash can only serve as /bin/sh (which is one of the
>> main reasons why it exists at all) if we make sure that our #!/bin/sh scripts
>> stick to some set of standards. That's currently POSIX.2.
> 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.
> Now, if we want to create a shell that only implements what is
> required by POSIX.2 (which is different from a shell that is compliant
> with POSIX.2), removing the option support from ash may make sense.
Remember it is only possible to have ash serve as /bin/sh if all #!/bin/sh
scripts were POSIX compliant. So either we need to fix all scripts that
use options with echo (because they violate the option), in which case it
would do no harm to remove the options from ash once that is done, or we
need to change the policy. As Anthony Towns suggested, we could change the
policy by specifically allowing echo to have options, overriding POSIX. If
this were done, then that'll be the end of the matter. However, if the
policy were changed to remove POSIX compliance entirely, then ash can no
longer serve as /bin/sh.
> But, as someone said, be liberal in what you accept and conservative
> in what you generate; if ash is intended to be a production shell
> (albeit stripped down for use on boot disks), it should be as liberal
> with options as is required. If it is intended to be a "lint" for
> non-portable shell programming practices, then it shouldn't be a
> production shell.
I've said this many times, but I'll repeat. This argument does not apply
because nobody writes scripts that have #!/bin/ash as their first line. So
nobody actually tailors their scripts with ash in mind. Since we are assuming
that #!/bin/sh scripts will be POSIX compliant, it makes no sense for ash to
support those features not mandated by POSIX.
> (For example, I can put lynx in a really strict HTML parsing mode, but
> it won't view 3/4 of the pages on the web because they are horribly
> broken. In strict mode, it's a great verification tool, but it's
> hardly suitable for browsing the web. That's why normally it's fairly
> loose about things.)
That's because the objects in your case are outside of our control. Shell
scripts on the other hand are not.
--
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: