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