GNU bug report logs - #8420
dirname

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8420 in the body.
You can then email your comments to 8420 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Michele Marigliano" <m.marigliano <at> almavivaitalia.it>
To: <bug-coreutils <at> gnu.org>
Subject: dirname 
Date: Mon, 4 Apr 2011 15:43:36 +0200

[Message part 1 (text/plain, inline)]

Hi, 

 

I execute the following bash command on RH 5.3 

CURRENT_DIR=`/usr/bin/dirname $0`

/usr/bin/dirname: invalid option -- b

Try `/usr/bin/dirname --help' for more information.

[oracle <at> mpawls ~]$ /usr/bin/dirname --version

dirname (GNU coreutils) 5.97

Copyright (C) 2006 Free Software Foundation, Inc.

This is free software.  You may redistribute copies of it under the terms of

the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.

There is NO WARRANTY, to the extent permitted by law.

 

Written by David MacKenzie and Jim Meyering.

$ echo $0

-bash

$ dirname

dirname: missing operand

Try `dirname --help' for more information.

$ dirname -b

dirname: invalid option -- b

Try `dirname --help' for more information.

 

I tried it also on Centos 5.5 with same result.

 

Instead on RH 4.x------------------------------------------

$ CURRENT_DIR=`/usr/bin/dirname $0`

$ /usr/bin/dirname --version

dirname (GNU coreutils) 5.2.1

Written by David MacKenzie and Jim Meyering.

 

Copyright (C) 2004 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$

$ echo $0

-bash

$ dirname

dirname: too few arguments

Try `dirname --help' for more information.

$ dirname -b

.

$

 

Best wish

Michael

 

 

[Message part 2 (text/html, inline)]

Message #10 received at 8420-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Michele Marigliano <m.marigliano <at> almavivaitalia.it>
Cc: 8420-done <at> debbugs.gnu.org
Subject: Re: bug#8420: dirname
Date: Mon, 04 Apr 2011 10:02:14 -0600

[Message part 1 (text/plain, inline)]

tag 8420 + invalid
thanks

On 04/04/2011 07:43 AM, Michele Marigliano wrote:
> Hi, 
> 
>  
> 
> I execute the following bash command on RH 5.3 
> 
> CURRENT_DIR=`/usr/bin/dirname $0`
> 
> /usr/bin/dirname: invalid option -- b

Thanks for the report.  However, this is not a bug in dirname, but in
your usage pattern.  You are invoking "dirname -bash", which dirname
(rightly) interprets as the attempt to be the -b option, but dirname
does not have a -b option.  You need to use -- to mark the end of
options and the start of arguments:

dirname -- "$0"

> dirname (GNU coreutils) 5.97

Wow, that's old.  The latest stable version is 8.10.

> $ /usr/bin/dirname --version
> 
> dirname (GNU coreutils) 5.2.1

Wow, that's even older, but same story.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #13 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Etienne Buira <etienne.buira.lists <at> free.fr>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#8420: dirname
Date: Mon, 4 Apr 2011 18:13:24 +0200

On Mon, Apr 04, 2011 at 03:43:36PM +0200, Michele Marigliano wrote:
> Hi, 

Hi.

> I execute the following bash command on RH 5.3 
> 
> CURRENT_DIR=`/usr/bin/dirname $0`

Beware that it will give the script dirname (if specified), not the
current working directory (that you can get using pwd).

> /usr/bin/dirname: invalid option -- b
> 
> Try `/usr/bin/dirname --help' for more information.
> 
> [oracle <at> mpawls ~]$ /usr/bin/dirname --version
> 
> dirname (GNU coreutils) 5.97

You might want to upgrade, it is an ancient version.

> $ echo $0
> 
> -bash

Options are introduced by a hyphen (which your binary name starts with),
if you want to tell that what follows is not option anymore, you want
to use '--'. So your lines looks like that:
CURRENT_DIR=`/usr/bin/dirname -- $0`
(works at least with coreutils8.7, don't know about your version).

> $ echo $0
> 
> -bash
> 
> $ dirname
> 
> dirname: too few arguments

Yes, it understood it like "dirname -b -a -s -h", whithout any filepath.

Message #16 received at 8420 <at> debbugs.gnu.org (full text, mbox):

From: Bjartur Thorlacius <svartman95 <at> gmail.com>
To: Michele Marigliano <m.marigliano <at> almavivaitalia.it>
Cc: 8420 <at> debbugs.gnu.org
Subject: Re: bug#8420: dirname
Date: Mon, 4 Apr 2011 17:23:23 +0000

You should probably not be using $0, as it doesn't contain a pathname.

Nonetheless, I believe there's truly a bug.
Retyped from the manual for dirname 8.5:
SYNOPSIS
   dirname NAME
   dirname OPTION
While simple, this doesn't describe the GNU implementation, which is more like:
   dirname -- NAME
   dirname OPTION
where OPTION begins with a hyphen or two.
The '97 SUS 2 spec has the most simple synopsis:
   dirname string

GNU dirname 8.5 (and some earlier versions) and FreeBSD dirname as
shipped with an  OS X 10.4 fail to filter strings starting with an
ASCII hyphen-minus, followed by one or more characters. FreeBSD
dirname conformingly fails with exit code 1 (presumably EXIT_FAILURE)
in all cases except if argv[1] is "--", in which case both GNU and
FreeBSD dirname ignore it, and use argv[2] instead. As does GNU
dirname 8.5, except for the strings "--version" and "--help", in which
case it writes non-conforming user messages to stdout and exits
successfully.

Busybox 1.14 considers the string "--help" as invalid, and writes
usage message to stderr and exits unsuccessfully. It's conforms to all
aspects of the standard, but the definition of a valid pathname. It
fails uniformly in the undefined case of more than two arguments.

Henceforth, there's no portable way to invoke dirname, as GNU and
FreeBSD dirnames fail if invoked as per SUS (with GNU dirname
sometimes exiting successfully, to confuse matters further), and
busybox fails if invoked per GNU conventions.

Note bene that the former method has to be tried first as GNU dirname
may fail successfully.
dirname() {
   env dirname -- "$1" ||
   env dirname "$1"
}

------------
tl;dr dirname -bash should output a single dot followed by a newline.

Message #19 received at 8420 <at> debbugs.gnu.org (full text, mbox):

From: "Michele Marigliano" <m.marigliano <at> almavivaitalia.it>
Cc: 8420 <at> debbugs.gnu.org
Subject: I: bug#8420: dirname
Date: Mon, 4 Apr 2011 19:37:07 +0200

Ooopss....

-----Messaggio originale-----
Da: Michele Marigliano [mailto:m.marigliano <at> almavivaitalia.it] 
Inviato: lunedì 4 aprile 2011 18.32
A: 'Eric Blake'
Oggetto: R: bug#8420: dirname

Thanks for your reply.

I agree with you, but I was installing some software on RH 5.3 and when I
was going to run a script it exit soon because its first line
(CURRENT_DIR=`/usr/bin/dirname $0`) was in error.
So I copyed that line in an interactive bash shell ad I noticed that

$ CURRENT_DIR=`/usr/bin/dirname $0`
/usr/bin/dirname: invalid option -- b

In a bash script $0 should be script name, so I didn't understand why it
didn't work.

In anycase I tried that line also on Centos 5.5 with same error, of course,
but when I tried it on RH 4.x it didn't report any error.
This was a quite strange, I thought, so I have reported you it to know if
this behavior is all right.

At end, I resolved it running the script in this way:
./script.sh
and NOT
. script.sh (my first run with error).

Bye
Michael


PS: sorry for my bad English.



-----Messaggio originale-----
Da: Eric Blake [mailto:eblake <at> redhat.com] 
Inviato: lunedì 4 aprile 2011 18.02
A: Michele Marigliano
Cc: 8420-done <at> debbugs.gnu.org
Oggetto: Re: bug#8420: dirname

tag 8420 + invalid
thanks

On 04/04/2011 07:43 AM, Michele Marigliano wrote:
> Hi,
> 
>  
> 
> I execute the following bash command on RH 5.3
> 
> CURRENT_DIR=`/usr/bin/dirname $0`
> 
> /usr/bin/dirname: invalid option -- b

Thanks for the report.  However, this is not a bug in dirname, but in your
usage pattern.  You are invoking "dirname -bash", which dirname
(rightly) interprets as the attempt to be the -b option, but dirname does
not have a -b option.  You need to use -- to mark the end of options and the
start of arguments:

dirname -- "$0"

> dirname (GNU coreutils) 5.97

Wow, that's old.  The latest stable version is 8.10.

> $ /usr/bin/dirname --version
> 
> dirname (GNU coreutils) 5.2.1

Wow, that's even older, but same story.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Message #22 received at 8420 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Bjartur Thorlacius <svartman95 <at> gmail.com>
Cc: 8420 <at> debbugs.gnu.org, Michele Marigliano <m.marigliano <at> almavivaitalia.it>
Subject: Re: bug#8420: dirname
Date: Mon, 04 Apr 2011 11:52:48 -0600

[Message part 1 (text/plain, inline)]

On 04/04/2011 11:23 AM, Bjartur Thorlacius wrote:
> You should probably not be using $0, as it doesn't contain a pathname.
> 
> Nonetheless, I believe there's truly a bug.
> Retyped from the manual for dirname 8.5:
> SYNOPSIS
>    dirname NAME
>    dirname OPTION
> While simple, this doesn't describe the GNU implementation, which is more like:
>    dirname -- NAME
>    dirname OPTION
> where OPTION begins with a hyphen or two.
> The '97 SUS 2 spec has the most simple synopsis:
>    dirname string

Coreutils complies with SUSv2, as well as SUSv3 (POSIX 2001) and SUSv4
(POSIX 2008).  Remember, POSIX states that _any_ standardized app _may_,
but not _must_, accept options unless explicitly documented otherwise
(as is the case for 'echo'); and therefore, all compliant apps not
documented otherwise _must_ accept -- for end-of-options, and all
compliant clients _must_ supply -- if they expect that the first
argument might begin with a -.  All of this without having to explicitly
document -- on every utility, because it was documented globally instead.

> 
> GNU dirname 8.5 (and some earlier versions) and FreeBSD dirname as
> shipped with an  OS X 10.4 fail to filter strings starting with an
> ASCII hyphen-minus, followed by one or more characters.

Please give a demonstration of an actual situation to back up your
assertion of a bug; until you do that, I have to assume that your test
is flawed and that GNU coreutils is standard-compliant.

> FreeBSD
> dirname conformingly fails with exit code 1 (presumably EXIT_FAILURE)
> in all cases except if argv[1] is "--", in which case both GNU and
> FreeBSD dirname ignore it, and use argv[2] instead. As does GNU
> dirname 8.5, except for the strings "--version" and "--help", in which
> case it writes non-conforming user messages to stdout and exits
> successfully.

The options --version and --help are _explicitly_ standards-conforming
extensions.  The standard requires that any application (unless
explicitly documented otherwise, as in the case of 'echo') may support
extensions to the option parsing syntax, and since the standard requires
that standardized options _only_ come from the set a-zA-VX-Z0-9 (-W is
reserved for the implementation), then the use of --xyz is an
appropriate implementation-specific extension to select the '-' short
option (which in the GNU world is in reality turning on long-option
parsing).

_ANY_ implementation of dirname that rejects 'dirname -- a' as invalid
is not standards-compliant, and the bug should be raised against that
version of dirname.

> tl;dr dirname -bash should output a single dot followed by a newline.

Wrong conclusion.  That invocation is in violation of the standards, so
it has unspecified behavior.  It _might_ output '.' if "-bash" were
treated as a filename, but the standards _also_ state that it is valid
to be treated as the "-b" option (since the standard explicitly permits
dirname to have extensions of options, even if no options are
standardized); which is exactly how GNU coreutils behaves.  The _only_
standardized way to take the dirname of "-bash" is to use "--":

dirname -- -bash

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #25 received at 8420 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Michele Marigliano <m.marigliano <at> almavivaitalia.it>
Cc: 8420 <at> debbugs.gnu.org
Subject: Re: bug#8420: I: bug#8420: dirname
Date: Mon, 04 Apr 2011 12:39:40 -0600

[Message part 1 (text/plain, inline)]

On 04/04/2011 11:37 AM, Michele Marigliano wrote:
> At end, I resolved it running the script in this way:
> ./script.sh
> and NOT
> . script.sh (my first run with error).

There is a large difference between sourcing a file in the current shell
(. script.sh, where $0 remains unchanged) and executing a script
(./script, where $0 changes to the script name); and as you discovered,
there are a large number of scripts that are not usable when sourced
instead of run as a script.

At any rate, glad to hear that you got things sorted out.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #28 received at 8420 <at> debbugs.gnu.org (full text, mbox):

From: Bjartur Thorlacius <svartman95 <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 8420 <at> debbugs.gnu.org
Subject: Re: bug#8420: dirname
Date: Mon, 4 Apr 2011 18:49:36 +0000

On 4/4/11, Eric Blake <eblake <at> redhat.com> wrote:
> On 04/04/2011 11:23 AM, Bjartur Thorlacius wrote:
>> You should probably not be using $0, as it doesn't contain a pathname.
>>
>> Nonetheless, I believe there's truly a bug.
>> Retyped from the manual for dirname 8.5:
>> SYNOPSIS
>>    dirname NAME
>>    dirname OPTION
>> While simple, this doesn't describe the GNU implementation, which is more
>> like:
>>    dirname -- NAME
>>    dirname OPTION
>> where OPTION begins with a hyphen or two.
>> The '97 SUS 2 spec has the most simple synopsis:
>>    dirname string
>
> Coreutils complies with SUSv2, as well as SUSv3 (POSIX 2001) and SUSv4
> (POSIX 2008).  Remember, POSIX states that _any_ standardized app _may_,
> but not _must_, accept options unless explicitly documented otherwise
> (as is the case for 'echo'); and therefore, all compliant apps not
> documented otherwise _must_ accept -- for end-of-options, and all
> compliant clients _must_ supply -- if they expect that the first
> argument might begin with a -.  All of this without having to explicitly
> document -- on every utility, because it was documented globally instead.
>
>>
>> GNU dirname 8.5 (and some earlier versions) and FreeBSD dirname as
>> shipped with an  OS X 10.4 fail to filter strings starting with an
>> ASCII hyphen-minus, followed by one or more characters.
>
> Please give a demonstration of an actual situation to back up your
> assertion of a bug; until you do that, I have to assume that your test
> is flawed and that GNU coreutils is standard-compliant.
>
>> FreeBSD
>> dirname conformingly fails with exit code 1 (presumably EXIT_FAILURE)
>> in all cases except if argv[1] is "--", in which case both GNU and
>> FreeBSD dirname ignore it, and use argv[2] instead. As does GNU
>> dirname 8.5, except for the strings "--version" and "--help", in which
>> case it writes non-conforming user messages to stdout and exits
>> successfully.
>
> 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?
Implementing only the standard synopsis would be much simpler.
Ideally, dirname shouldn't even check if it's arguments start with a
hyphen or not (save for checking caller for standards compliance).

> application (unless
> explicitly documented otherwise, as in the case of 'echo') may support
> extensions to the option parsing syntax, and since the standard requires
> that standardized options _only_ come from the set a-zA-VX-Z0-9 (-W is
> reserved for the implementation), then the use of --xyz is an
> appropriate implementation-specific extension to select the '-' short
> option (which in the GNU world is in reality turning on long-option
> parsing).
>
It's quite confusing, however, to silently interpret argv[1] as an
option and write output not conforming to the format specified in
STDOUT.

> _ANY_ implementation of dirname that rejects 'dirname -- a' as invalid
> is not standards-compliant, and the bug should be raised against that
> version of dirname.
>
>> tl;dr dirname -bash should output a single dot followed by a newline.
>
> Wrong conclusion.  That invocation is in violation of the standards, so
> it has unspecified behavior.  It _might_ output '.' if "-bash" were
> treated as a filename, but the standards _also_ state that it is valid
> to be treated as the "-b" option (since the standard explicitly permits
> dirname to have extensions of options, even if no options are
> standardized); which is exactly how GNU coreutils behaves.  The _only_
> standardized way to take the dirname of "-bash" is to use "--":
>
> 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?

Message #31 received at 8420 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Bjartur Thorlacius <svartman95 <at> gmail.com>
Cc: 8420 <at> debbugs.gnu.org
Subject: Re: bug#8420: dirname
Date: Mon, 04 Apr 2011 13:03:21 -0600

[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)]

Message #34 received at 8420 <at> debbugs.gnu.org (full text, mbox):

From: "Michele Marigliano" <m.marigliano <at> almavivaitalia.it>
To: "'Eric Blake'" <eblake <at> redhat.com>
Cc: 8420 <at> debbugs.gnu.org
Subject: R: bug#8420: I: bug#8420: dirname
Date: Tue, 5 Apr 2011 11:07:38 +0200

I realize it.
Anyway, I am very sorry for my bad warning.
Thank you very much for your attention.

Bye
Michael

-----Messaggio originale-----
Da: Eric Blake [mailto:eblake <at> redhat.com] 
Inviato: lunedì 4 aprile 2011 20.40
A: Michele Marigliano
Cc: 8420 <at> debbugs.gnu.org
Oggetto: Re: bug#8420: I: bug#8420: dirname

On 04/04/2011 11:37 AM, Michele Marigliano wrote:
> At end, I resolved it running the script in this way:
> ./script.sh
> and NOT
> . script.sh (my first run with error).

There is a large difference between sourcing a file in the current shell (.
script.sh, where $0 remains unchanged) and executing a script (./script,
where $0 changes to the script name); and as you discovered, there are a
large number of scripts that are not usable when sourced instead of run as a
script.

At any rate, glad to hear that you got things sorted out.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Message #37 received at 8420 <at> debbugs.gnu.org (full text, mbox):

From: Bjartur Thorlacius <svartman95 <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 8420 <at> debbugs.gnu.org
Subject: Re: bug#8420: dirname
Date: Tue, 5 Apr 2011 19:08:31 +0000

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.

Message #40 received at 8420 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Bjartur Thorlacius <svartman95 <at> gmail.com>
Cc: 8420 <at> debbugs.gnu.org
Subject: Re: bug#8420: dirname
Date: Tue, 05 Apr 2011 13:50:55 -0600

[Message part 1 (text/plain, inline)]

On 04/05/2011 01:08 PM, Bjartur Thorlacius wrote:
>> _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.

Umm, I _was_ quoting Open Group's formal document on dirname, which is
why I'm quite confident that the bug is in busybox for not complying
with the Open Group standard when it comes to -- handling.  But I will
concede the fact that it can be a bit inconvenient that you have to read
the section on global utility behavior, even if in the long run it makes
more sense to have text just once in that global section than to
duplicate global behavior descriptions into every utility page (even if
too many people end up skipping over the global behavior pages).

>> 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.

That link is the Open Group's online version of IEEE Std 1003.1-2008
(aka POSIX 2008, which in turn is included by reference in SUSv4); if
you have the pdf of the Open Group standard, I was quoting from XCU 1.4,
page 2288, lines 71982-71992.  Since dirname states "OPTIONS None." at
page 2608 line 84080 later in the same document, the global handling
applies to dirname.  Contrast that with the wording for echo at line 84301:

The echo utility shall not recognize the "--" argument in the manner
specified by Guideline 10 of XBD Section 12.2 (on page 215); "--" shall
be recognized as a string operand.

since echo is one of the (few) utilities that does not fall under the
global rules.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #43 received at 8420 <at> debbugs.gnu.org (full text, mbox):

From: Bjartur Thorlacius <svartman95 <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 8420 <at> debbugs.gnu.org
Subject: Re: bug#8420: dirname
Date: Thu, 7 Apr 2011 16:48:14 +0000

On 4/5/11, Eric Blake <eblake <at> redhat.com> wrote:
> On 04/05/2011 01:08 PM, Bjartur Thorlacius wrote:
>>> _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.
>
> Umm, I _was_ quoting Open Group's formal document on dirname, which is
> why I'm quite confident that the bug is in busybox for not complying
> with the Open Group standard when it comes to -- handling.  But I will
> concede the fact that it can be a bit inconvenient that you have to read
> the section on global utility behavior, even if in the long run it makes
> more sense to have text just once in that global section than to
> duplicate global behavior descriptions into every utility page (even if
> too many people end up skipping over the global behavior pages).
>
>>> 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.
>
> That link is the Open Group's online version of IEEE Std 1003.1-2008
> (aka POSIX 2008, which in turn is included by reference in SUSv4); if
> you have the pdf of the Open Group standard, I was quoting from XCU 1.4,
> page 2288, lines 71982-71992.  Since dirname states "OPTIONS None." at
> page 2608 line 84080 later in the same document, the global handling
> applies to dirname.  Contrast that with the wording for echo at line 84301:
>
Yeah, it clearly applies. I'm simply spoiled by other standards groups
putting explicit references to dependancies into every document. HTML5
states that elements may have 'global attributes' when that applies,
even in the single file version. Heck RFCs reference RFC 2119
[http://www.ietf.org/rfc/rfc2119.txt] to clarify what terminology
they're using. The document I read can clearly not be considered
standalone.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.