bug#8420: dirname

[Bjartur Thorlacius]

On 4/4/11, Eric Blake <address@hidden> wrote:
> On 04/04/2011 12:49 PM, Bjartur Thorlacius wrote:
>>> The options --version and --help are _explicitly_ standards-conforming
>>> extensions.  The standard requires that any
>> But then again, are these extensions needed, or even desired?
>
> Needed?  Debatable (as you've proven by keeping this thread alive).
> Desired?  Yes, GNU Coding Standards require that _all_ GNU software
> (including GNU coreutils) support --help and --version unless standards
> forbid otherwise (which is why 'POSIXLY_CORRECT= echo --help' is one of
> the few exceptions in coreutils).
>
*Adding POSIXLY_CORRECT='' to environ*
The holiness of the current GNU Coding Standards is a matter for
debate in itself, but for another mailing list - traditionally
address@hidden ;P.

>> Implementing only the standard synopsis would be much simpler.
>
> You aren't listening - simplicity has nothing to do with this.  The
> standard _explicitly_ permits --help and --version as extensions, and
I differentiate between permitting and requiring. But I acknowledge
the GNU Coding Standards as next in chain when The Open Group doesn't
mandate one way or another.

> _mandates_ that any portable client software must be aware that
> extensions are permitted, and therefore the burden is on the client (and
> not on dirname itself) to supply the -- end-of-options argument if the
> operand starts with -.
>
True. I raised the issue as this wasn't clear from Open Groups'
document on dirname, and this argv format was incompatible with my
version of busybox.

>> Ideally, dirname shouldn't even check if it's arguments start with a
>> hyphen or not (save for checking caller for standards compliance).
>
>> It's quite confusing, however, to silently interpret argv[1] as an
>> option and write output not conforming to the format specified in
>> STDOUT.
>
> That is _NOT_ confusing, but permitted by the standards.
>
> If you want to find the dirname of a file named --version, then use
> 'dirname -- --version'.  It's as simple as that.
>
> The behavior of 'dirname --version' is _NOT_ mandated by the standard,
> and if you invoke it, you are invoking unspecified behavior, and you
> deserve any breakage that you get, including both breakage due to
> coreutils treating it as an extension option and printing something to
> stdout, as well as breakage for another application rejecting it as an
> unknown option, as well as implementations that happen to treat it as a
> filename and printing '.' since it isn't a known option for that
> implementation.  But the point remains - the standard does _NOT_ require
> 'dirname --version' to treat --version as a file name.
>
It'd be more intuitive to print usage messages to stderr (as you most
like don't want the message to be piped through the rest of the
pipeline).

>>> dirname -- -bash
>>>
>> I see now that portable application programs should *always* invoke
>> dirname with argv[1] set to "--".
>>
>> Anyone up for filing a bug against busybox?
>
> Wouldn't be the first time we've had to tell busybox that they are
> non-compliant for not honoring --.
>
Sadly, I don't find that hard to believe :[.
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_04
>
> OPTIONS
> 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.
>
Thanks. I expected to see explicit references to documents such as
this one in a formal standard, but I guess I need to lie down and read
it in its entirety.