bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8420: dirname


From: Eric Blake
Subject: bug#8420: dirname
Date: Mon, 04 Apr 2011 13:03:21 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.9

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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]