GNU bug report logs -
#8420
dirname
Previous Next
Full log
Message #37 received at 8420 <at> debbugs.gnu.org (full text, mbox):
On 4/4/11, Eric Blake <eblake <at> redhat.com> 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
dev <at> suckless.org ;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.
This bug report was last modified 14 years and 52 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.