[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: nonconformant behavior for printf(1) (you cannot interpret - as an o
Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)
Mon, 26 Nov 2007 22:24:08 -0700
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20071031 Thunderbird/22.214.171.124 Mnenhy/0.7.5.666
-----BEGIN PGP SIGNED MESSAGE-----
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:
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
Don't work too hard, make some time for fun as well!
Eric Blake address@hidden
-----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
-----END PGP SIGNATURE-----