GNU bug report logs -
#8420
dirname
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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).
> 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
_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 -.
> 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.
>> 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 --.
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.
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
and avoid any problems with -m used as an extension.
--
Eric Blake eblake <at> redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
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.