[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nonconformant behavior for printf(1) (you cannot interpret - as an o

From: Eric Blake
Subject: Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)
Date: Mon, 26 Nov 2007 22:24:08 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071031 Thunderbird/ Mnenhy/

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:


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]