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

[Rich Felker]

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