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