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

[Rich Felker]

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