nonconformant behavior for printf(1) (you cannot interpret - as an option char)
$ printf ---%s---\\n test bash: printf: --: invalid option printf: usage: printf [-v var] format [arguments] expected: ---test--- This seems to be the third bug I've found in bash's internal printf(1) which breaks conformance to POSIX. Could you either fix this, or else disable the printf (and possibly other) builtins entirely when bash is running in POSIX/sh mode? It's a source of breakage for real valid scripts! Disabling the builtins manually is not an option for sh scripts since the mechanism to disable them is bash-specific. Rich
echo(1) non-conformant (processing -e and -E)
When running in POSIX/sh mode, bash should either disable the echo builtin or stop giving special treatment to -e and -E. In particular, POSIX provides well-defined behavior for: echo -e bash gives: blank line posix gives: line containing only "-e" echo -E bash gives: blank line posix gives: line containing only "-E" echo -e -n bash gives: no output posix gives: line containing "-e -n" POSIX leaves behavior unspecified when -n is the first argument, and also when any argument contains backslashes. However, if conformance to the XSI part of SUSv3 is also desired, -e must be default. I tend to think this is stupid, which you probably agree with, so I have no opinion on changing it to be XSI-conformant but I'm mentioning it anyway for completeness. Basically, my point is that bash, in POSIX/sh mode, should not provide nonconformant builtins for POSIX commands which prevent potentially conformant ones in the host system's path from being used. Either the bash versions should be conformant or they should get out of the way when in standards-conformant mode. Rich
Re: echo(1) non-conformant (processing -e and -E)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Rich Felker on 11/26/2007 8:51 PM: > POSIX leaves behavior unspecified when -n is the first argument, and > also when any argument contains backslashes. However, if conformance > to the XSI part of SUSv3 is also desired, -e must be default. I tend > to think this is stupid, which you probably agree with, so I have no > opinion on changing it to be XSI-conformant but I'm mentioning it > anyway for completeness. POSIX also states that echo is inherently non-portable, for these very reasons, and recommends using printf(1) instead of echo(1). - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHS57m84KuGfSFAYARAglAAKDOQUlF7oF5aUXsFKZecfirobA2UgCfd0X4 f/h3387RHiXENCuU8nwdB3w= =c8Qq -END PGP SIGNATURE-
Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Rich Felker on 11/26/2007 8:43 PM: > $ printf ---%s---\\n test > bash: printf: --: invalid option That's not a bug. If you insist on printing with a format string that starts with -, POSIX requires that you use -- to end arguments, as in: $ printf -- ---%s---\\n test - ---test--- If your non-builtin system printf behaves differently, that is a bug in your system printf. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHS58d84KuGfSFAYARAl6uAKCiyJwxJxwt3pEoIBoOtzAgMAPfdwCdGLk5 5seJo0RZaa7EWH8lcWbvaMU= =5gil -END PGP SIGNATURE-
Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please keep replies on the list, so that others may chime in.
According to Rich Felker on 11/26/2007 9:41 PM:
>>> $ printf ---%s---\\n test
>>> bash: printf: --: invalid option
>> That's not a bug. If you insist on printing with a format string that
>> starts with -, POSIX requires that you use -- to end arguments, as in:
>>
>> $ printf -- ---%s---\\n test
>> - ---test---
>>
>> If your non-builtin system printf behaves differently, that is a bug in
>> your system printf.
>
> This is simply not true. Read the synopsis for POSIX printf. It does
> not support options; usage is simply:
>
> printf format [argument ...]
POSIX merely states that a _conforming_ program cannot use any options;
however, it does not forbid the presence of options as extensions.
Furthermore, it states:
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html
Guideline 10:
The argument -- should be accepted as a delimiter indicating the end
of options. Any following arguments should be treated as operands, even if
they begin with the '-' character. The -- argument should not be used as
an option or as an operand.
The utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001
that claim conformance to these guidelines shall conform completely to
these guidelines as if these guidelines contained the term "shall" instead
of "should".
> Using printf -- ---%s---\\n test is not valid at all and will produce
> unspecified output since there are no format specifiers in the format
> ("--") and yet there are arguments to be formatted.
You are wrong. It is the _only_ POSIX-sanctioned way to print with a
format string starting with a hyphen, because the -- is required to be
interpreted as the end of options, and not as the format string. The
format string is not an option, so it is the first word after the
end-of-options designator, or ---%s---\\n.
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHS6Mc84KuGfSFAYARAhFkAKDLLWTgc7VtWY2JwkqRZidifdg/kwCfZc3Y
Fw8/X5o8vWEjommtHozp8mY=
=cH3R
-END PGP SIGNATURE-
Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Rich Felker on 11/26/2007 10:02 PM: > On Mon, Nov 26, 2007 at 09:54:52PM -0700, Eric Blake wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Please keep replies on the list, so that others may chime in. ^^^ > Printf does not claim conformance to those guidelines; read the > specific documentation on printf. In fact many utilities do not. You > have to read the specific documentation on each one. You should feel free to take this up with the Austin group, then. This is not bash's problem, unless you can prove that POSIX intends for printf(1) to reject the extension of options. POSIX is quite clear that echo(1) rejects options with the statement "The echo utility shall not recognize the "−−" argument in the manner specified by Guideline 10 of XBD Section 12.2; "−−" shall be recognized as a string operand." For any utility that does not have this explicit rejection, then the extension of providing options is valid implicitly. Just because a portable application cannot use those options does not mean that an implementation can provide options; therefore, a portable application MUST use -- to separate the end of theoretical options from the leading argument. And FWIW, coreutils interprets POSIX in the same manner as bash. > Again, go read POSIX and if you're still unclear file a RFI. But it's > very clear and bash is incorrect in this respect. I'm on the Austin group, and feel quite confident that I understand what it permits vs. what it requires. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHS6Z384KuGfSFAYARAi0gAJ4geZku6AQ6heOkbKrHZB/I06CD+wCgyUfD 5Ln1I7JfST58o74mn6tC2lA= =1V5z -END PGP SIGNATURE-
Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)
On Mon, Nov 26, 2007 at 10:09:11PM -0700, Eric Blake wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > According to Rich Felker on 11/26/2007 10:02 PM: > > On Mon, Nov 26, 2007 at 09:54:52PM -0700, Eric Blake wrote: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> Please keep replies on the list, so that others may chime in. > > ^^^ Sorry, will do from now on. > > Printf does not claim conformance to those guidelines; read the > > specific documentation on printf. In fact many utilities do not. You > > have to read the specific documentation on each one. > > You should feel free to take this up with the Austin group, then. This is > not bash's problem, unless you can prove that POSIX intends for printf(1) > to reject the extension of options. > > POSIX is quite clear that echo(1) rejects options with the statement "The > echo utility shall not recognize the "−−" argument in the manner specified > by Guideline 10 > of XBD Section 12.2; "−−" shall be recognized as a string operand." > > For any utility that does not have this explicit rejection, then the > extension of providing options is valid implicitly. Just because a > portable application cannot use those options does not mean that an Every other utility that uses the guidelines explicitly mentions them. Moreover since the guidelines explicitly say that they apply to any utility claiming conformance to them, I think it's clear that they don't apply to a utility whose documentation makes no mention of them. > implementation can provide options; therefore, a portable application MUST > use -- to separate the end of theoretical options from the leading argument. But a portable application cannot do this since it's perfectly valid for an implementation not to support --. Given the mess we have, the only reliable way I see to use a format string beginning with a - is to use \055. And one thing we can probably agree upon is that, due to the prevalence of implementations that treat - specially (whether this is correct or incorrect behavior), changing them now would do little to help the portability of scripts whose authors will want them to work on outdated versions of the shell as well, so this argument is mostly for completeness/correctness sake. > And FWIW, coreutils interprets POSIX in the same manner as bash. GNU coreutils is hardly a model of conformance... > > Again, go read POSIX and if you're still unclear file a RFI. But it's > > very clear and bash is incorrect in this respect. > > I'm on the Austin group, and feel quite confident that I understand what > it permits vs. what it requires. If everyone on the Austin group thought about things exactly the same way, I suspect you guys would have a MUCH easier time. Of course things don't work that way, so why not run it by some of your peers? Even if the behavior you believe is intended is actually what's intended, the specification should be amended to make it explicit to prevent this sort of argument in the future. Rich
Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 11/26/2007 10:09 PM: >> Again, go read POSIX and if you're still unclear file a RFI. But it's >> very clear and bash is incorrect in this respect. > > I'm on the Austin group, and feel quite confident that I understand what > it permits vs. what it requires. Furthermore, read the paragraph about OPTIONS in section 1.11 of: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap01.html Default Behavior: When this section is listed as "None.", it means that the implementation need not support any options. Standard utilities that do not accept options, but that do accept operands, shall recognize "--" as a first argument to be discarded. The requirement for recognizing "--" is because conforming applications need a way to shield their operands from any arbitrary options that the implementation may provide as an extension. For example, if the standard utility foo is listed as taking no options, and the application needed to give it a pathname with a leading hyphen, it could safely do it as: foo -- -myfile Sure enough, the POSIX page for printf(1) lists "None." under OPTIONS, so what I'm saying is _required_ by POSIX, despite your bogus claims to the contrary. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHS6n384KuGfSFAYARAluTAKCr/ijDNeIpgPVWBu5dL1rR+DecewCgsWle nyp3clZphGWM8lBwEFEJSgs= =LT05 -END PGP SIGNATURE-
Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)
On Mon, Nov 26, 2007 at 10:24:08PM -0700, Eric Blake wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > According to Eric Blake on 11/26/2007 10:09 PM: > >> Again, go read POSIX and if you're still unclear file a RFI. But it's > >> very clear and bash is incorrect in this respect. > > > > I'm on the Austin group, and feel quite confident that I understand what > > it permits vs. what it requires. > > Furthermore, read the paragraph about OPTIONS in section 1.11 of: > > http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap01.html > > Default Behavior: When this section is listed as "None.", it means that > the implementation need not support any options. Standard utilities that > do not accept options, but that do accept operands, shall recognize "--" > as a first argument to be discarded. > > The requirement for recognizing "--" is because conforming applications > need a way to shield their operands from any arbitrary options that the > implementation may provide as an extension. For example, if the standard > utility foo is listed as taking no options, and the application needed to > give it a pathname with a leading hyphen, it could safely do it as: > > foo -- -myfile > > > Sure enough, the POSIX page for printf(1) lists "None." under OPTIONS, so > what I'm saying is _required_ by POSIX, despite your bogus claims to the > contrary. Okay, thanks for the clarification. I'll drop this complaint and report bugs to any implementations I find where the -- is not accepted. Sorry for wasting your time. Rich
