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 , it could safely do it as: foo -- -myfile and avoid any problems with -m used as an extension. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org