GNU bug report logs - #7434
When an incorrect option is used before --help/--version, automake behaviour is inconsistent with that of other GNU programs.

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 7434 in the body.
You can then email your comments to 7434 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: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: When an incorrect option is used before --help/--version,
	automake behaviour is inconsistent with that of other GNU programs.
Date: Thu, 18 Nov 2010 16:22:29 +0100

Severity: wishlist

Currently, automake and aclocal scan their command line looking for
`--help' and `--version' even after an invalid option has been seen;
and in case one of those two options is seen, it takes precedence
even over error reporting about preceding invalid options.

But this is inconsistent with the behaviour of many others GNU/free
programs; for example:

  $ m4 --version --no-such-option; echo \$? = $?
  m4 (GNU M4) 1.4.14
  Copyright (C) 2010 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Written by Rene' Seindal.
  $? = 0

  $ m4 --no-such-option --version; echo \$? = $?
  m4: unrecognized option '--no-such-option'
  Try `m4 --help' for more information.
  $? = 1

The same beheaviour of GNU m4 can be observed with at least GNU sed,
GNU awk, GNU coreutils, GNU bison, flex, gzip, bzip2, xz, GNU libtool,
GNU autoconf, GNU tar, Zsh, and Git.

On the other hand:
  - Bash exit with failure also in the case an invalid option is used
    *after* `--version' or `--help', but I see no reason to copy this
    behaviour, which IMHO is (slighty) suboptimal, and not at all
    widespread.
  - GCC behaves as automake and aclocal currently do, but it has always
    had a peculiar semantic of command-line scanning, for both intrinsic
    and historical reasons; so it's not a good model to follow IMHO.

In conclusion: would you agree with a patch that converts automake and
aclocal to the same cmdline-scanning behaviour of the majority of other
GNU tools?  Such a patch would also have the advantage of *simplifying*
the current code for command line parsing in automake and aclocal.

Regards,
  Stefano

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

From: Eric Blake <eblake <at> redhat.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7434 <at> debbugs.gnu.org
Subject: Re: bug#7434: When an incorrect option is used before
	--help/--version, 
	automake behaviour is inconsistent with that of other GNU programs.
Date: Thu, 18 Nov 2010 08:55:39 -0700

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

On 11/18/2010 08:22 AM, Stefano Lattarini wrote:
> Severity: wishlist
> 
> Currently, automake and aclocal scan their command line looking for
> `--help' and `--version' even after an invalid option has been seen;
> and in case one of those two options is seen, it takes precedence
> even over error reporting about preceding invalid options.

GNU Coding Standards _only_ require that --help and --version be
recognized as the first argument, with no other arguments.  When
possible, recognizing --help and --version after other arguments, or
with other arguments afterwards, is nice, but there are no rules that
require that consistency.

> 
> But this is inconsistent with the behaviour of many others GNU/free
> programs; for example:
> 
>   $ m4 --version --no-such-option; echo \$? = $?
>   m4 (GNU M4) 1.4.14
>   $? = 0
> 
>   $ m4 --no-such-option --version; echo \$? = $?
>   m4: unrecognized option '--no-such-option'
>   Try `m4 --help' for more information.
>   $? = 1

m4 makes a single pass through its options, and gives up on the first
error (after all, how do we know that a future version of m4 might start
accepting 'm4 --do-this=--version', where --version is the argument of
the new --do-this option, at which point 'm4 --do-this --version' would
suddenly change behavior from printing versions to instead doing this).

Coreutils is also an interesting case study, as there are several idioms
used depending on POSIX restrictions on the utility in question.

For example:

$ /usr/bin/[ --help | head -n1
Usage: test EXPRESSION
$ /usr/bin/[ --help --oops
/usr/bin/[: missing `]'
$ /usr/bin/[ --oops --help
/usr/bin/[: missing `]'


> In conclusion: would you agree with a patch that converts automake and
> aclocal to the same cmdline-scanning behaviour of the majority of other
> GNU tools?  Such a patch would also have the advantage of *simplifying*
> the current code for command line parsing in automake and aclocal.

Not necessarily on the grounds of making things match other tools, but
definitely on the grounds of having simpler code that still complies
with GCS.

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

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

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 7434 <at> debbugs.gnu.org
Subject: Re: bug#7434: When an incorrect option is used before
	--help/--version,
	automake behaviour is inconsistent with that of other GNU programs.
Date: Thu, 18 Nov 2010 17:28:30 +0100

On Thursday 18 November 2010, Eric Blake wrote:
> On 11/18/2010 08:22 AM, Stefano Lattarini wrote:
> > Severity: wishlist
> > 
> > Currently, automake and aclocal scan their command line looking for
> > `--help' and `--version' even after an invalid option has been seen;
> > and in case one of those two options is seen, it takes precedence
> > even over error reporting about preceding invalid options.
> 
> GNU Coding Standards _only_ require that --help and --version be
> recognized as the first argument, with no other arguments.
> When possible, recognizing --help and --version after other arguments,
> or with other arguments afterwards, is nice, but there are no rules
> that require that consistency.
Not exactly.  The GNU Coding Standards read (my emphasis):

  ``The standard --version option should direct the program to print
    information about its name, version, origin and legal status, all
    on standard output, and then exit successfully. Other options and
    arguments should be ignored *once this is seen*, and the program
    should not perform its normal function.''

So it means that the behaviour of GNU m4 (and the other mentioned
programs) is compliant with the GCS, while the automake behaviour
is "overzealous" in this respect.

> [CUT]
> 
> > In conclusion: would you agree with a patch that converts automake and
> > aclocal to the same cmdline-scanning behaviour of the majority of other
> > GNU tools?  Such a patch would also have the advantage of *simplifying*
> > the current code for command line parsing in automake and aclocal.
> 
> Not necessarily on the grounds of making things match other tools, but
> definitely on the grounds of having simpler code that still complies
> with GCS.
Yes, that was truly my primary motivation.  The fact that the new automake
behaviour would match that of many other tools was just a "bonus".

Regards,
  Stefano
 

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

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7434 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#7434: When an incorrect option is used before
	--help/--version,
	automake behaviour is inconsistent with that of other GNU programs.
Date: Thu, 18 Nov 2010 21:26:16 +0100

Hello,

* Stefano Lattarini wrote on Thu, Nov 18, 2010 at 05:28:30PM CET:
> On Thursday 18 November 2010, Eric Blake wrote:
> > On 11/18/2010 08:22 AM, Stefano Lattarini wrote:
> > > Currently, automake and aclocal scan their command line looking for
> > > `--help' and `--version' even after an invalid option has been seen;
> > > and in case one of those two options is seen, it takes precedence
> > > even over error reporting about preceding invalid options.
> > 
> > GNU Coding Standards _only_ require that --help and --version be
> > recognized as the first argument, with no other arguments.
> > When possible, recognizing --help and --version after other arguments,
> > or with other arguments afterwards, is nice, but there are no rules
> > that require that consistency.

> Not exactly.  The GNU Coding Standards read (my emphasis):
> 
>   ``The standard --version option should direct the program to print
>     information about its name, version, origin and legal status, all
>     on standard output, and then exit successfully. Other options and
>     arguments should be ignored *once this is seen*, and the program
>     should not perform its normal function.''
> 
> So it means that the behaviour of GNU m4 (and the other mentioned
> programs) is compliant with the GCS, while the automake behaviour
> is "overzealous" in this respect.

I think the GCS should be adjusted then.  IIUC then GNU has valued
usability over implementation simplicity.  I think --help should work
whereever it is put on a command line, except after -- or right after an
option which requires an argument (or at least GCS should allow for this
behavior).  The point being that I type

$ foo --zork --barf
foo: blabla error, see --help

and then type <up><space>--help<enter> to find out more.

Let's address this on bug-standards before changing any programs.

Thanks,
Ralf

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 7434 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#7434: When an incorrect option is used before
	--help/--version,
	automake behaviour is inconsistent with that of other GNU programs.
Date: Thu, 18 Nov 2010 22:01:06 +0100

On Thursday 18 November 2010, Ralf Wildenhues wrote:
> Hello,
Hi Ralf.  I answer here because I'm not subscribed to bug-standards;
I hope that's not a problem.

> 
> * Stefano Lattarini wrote on Thu, Nov 18, 2010 at 05:28:30PM CET:
> > On Thursday 18 November 2010, Eric Blake wrote:
> > > On 11/18/2010 08:22 AM, Stefano Lattarini wrote:
> > > > Currently, automake and aclocal scan their command line looking for
> > > > `--help' and `--version' even after an invalid option has been seen;
> > > > and in case one of those two options is seen, it takes precedence
> > > > even over error reporting about preceding invalid options.
> > > 
> > > GNU Coding Standards _only_ require that --help and --version be
> > > recognized as the first argument, with no other arguments.
> > > When possible, recognizing --help and --version after other arguments,
> > > or with other arguments afterwards, is nice, but there are no rules
> > > that require that consistency.
> 
> > Not exactly.  The GNU Coding Standards read (my emphasis):
> > 
> >   ``The standard --version option should direct the program to print
> >     information about its name, version, origin and legal status, all
> >     on standard output, and then exit successfully. Other options and
> >     arguments should be ignored *once this is seen*, and the program
> >     should not perform its normal function.''
> > 
> > So it means that the behaviour of GNU m4 (and the other mentioned
> > programs) is compliant with the GCS, while the automake behaviour
> > is "overzealous" in this respect.
> 
> I think the GCS should be adjusted then.
I strongly disagree.

> IIUC then GNU has valued usability over implementation simplicity.
True, but I don't think that the current behaviour of autoconf, m4,
sed, libtool, etc. in this matter can be described as lacking in
usability.  Has any real user ever complained about such a behaviour
(honest question)?  If not, then the behaviour is clearly correct
and good enough.
> I think --help should work whereever it is put on a command line,
> except after -- or right after an option which requires an argument
I disagree; that would complicate the implementation without providing
any real advantage for the users IMHO.

> (or at least GCS should allow for this behavior).
They alrady does (so automake is safe in this respect even with its
current behaviour); they just doesn't require it.  Which is good IMO.

> The point being that I type
> 
> $ foo --zork --barf
> foo: blabla error, see --help
> 
> and then type <up><space>--help<enter> to find out more.
Or type <up><ctrl-a><alt-f><space>--help<enter> to find out more.
Or even type "foo --help" to find out more.  These are not much
more complex or lacking in usability, IMHO.
 
> Let's address this on bug-standards before changing any programs.
I'm not subscribed to that list, so please CC me if you want me to
contribute to the discussion.  Thanks.

Regards,
   Stefano

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 7434 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#7434: When an incorrect option is used before
	--help/--version,
	automake behaviour is inconsistent with that of other GNU programs.
Date: Fri, 19 Nov 2010 11:22:40 +0100

On Thursday 18 November 2010, Stefano Lattarini wrote:
> On Thursday 18 November 2010, Ralf Wildenhues wrote:
>
> > I think --help should work whereever it is put on a command line,
> > except after -- or right after an option which requires an argument
>
> I disagree; that would complicate the implementation without providing
> any real advantage for the users IMHO.
> 
> > The point being that I type
> > 
> > $ foo --zork --barf
> > foo: blabla error, see --help
> > 
> > and then type <up><space>--help<enter> to find out more.
> Or type <up><ctrl-a><alt-f><space>--help<enter> to find out more.
> Or even type "foo --help" to find out more.  These are not much
> more complex or lacking in usability, IMHO.
>
Besides, in the particular case of automake, how often do automake
or aclocal get invoked directly?  To my experience, they are almost
always invoked by autoreconf, ./bootstrap, or some custom autogen.sh
script.
  
> > Let's address this on bug-standards before changing any programs.
>
> I'm not subscribed to that list, so please CC me if you want me to
> contribute to the discussion.  Thanks.
>
FYI, now I've subscribed to the list, so there' no need to CC me
anymore.

Thanks,
   Stefano

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 7434 <at> debbugs.gnu.org
Cc: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>, Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#7434: When an incorrect option is used before
	--help/--version,
	automake behaviour is inconsistent with that of other GNU programs.
Date: Fri, 26 Nov 2010 18:41:20 +0100

Hi Ralf, Eric, and all bug-automake readers.

On Friday 19 November 2010, Stefano Lattarini wrote:
> On Thursday 18 November 2010, Stefano Lattarini wrote:
> > On Thursday 18 November 2010, Ralf Wildenhues wrote:
> >
> > > I think --help should work whereever it is put on a command line,
> > > except after -- or right after an option which requires an argument
> >
> > I disagree; that would complicate the implementation without providing
> > any real advantage for the users IMHO.
> > 
> > > The point being that I type
> > > 
> > > $ foo --zork --barf
> > > foo: blabla error, see --help
> > > 
> > > and then type <up><space>--help<enter> to find out more.
> > Or type <up><ctrl-a><alt-f><space>--help<enter> to find out more.
> > Or even type "foo --help" to find out more.  These are not much
> > more complex or lacking in usability, IMHO.
> >
> Besides, in the particular case of automake, how often do automake
> or aclocal get invoked directly?  To my experience, they are almost
> always invoked by autoreconf, ./bootstrap, or some custom autogen.sh
> script.
>   
> > > Let's address this on bug-standards before changing any programs.
>
Now a decision has been reached on bug-standards *not* to tighten the
specification about the behaviour of --help and --version:
 <http://lists.gnu.org/archive/html/bug-standards/2010-11/msg00010.html>

Considering that, do you agree to simplify the automake/aclocal option
parsing by not trying to process --help/--version options encountered
after invalid options?

Regards,
   Stefano

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

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7434 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#7434: When an incorrect option is used before
	--help/--version,
	automake behaviour is inconsistent with that of other GNU programs.
Date: Sun, 28 Nov 2010 18:41:08 +0100

* Stefano Lattarini wrote on Fri, Nov 26, 2010 at 06:41:20PM CET:
> > Besides, in the particular case of automake, how often do automake
> > or aclocal get invoked directly?  To my experience, they are almost
> > always invoked by autoreconf, ./bootstrap, or some custom autogen.sh
> > script.

(aside: autoreconf works just in the same way as automake in this
respect.)

> > > > Let's address this on bug-standards before changing any programs.
> >
> Now a decision has been reached on bug-standards *not* to tighten the
> specification about the behaviour of --help and --version:
>  <http://lists.gnu.org/archive/html/bug-standards/2010-11/msg00010.html>

Nor to forbid the current behavior of automake.

> Considering that, do you agree to simplify the automake/aclocal option
> parsing by not trying to process --help/--version options encountered
> after invalid options?

I'm painfully aware that this is a near-bikeshed discussion, but I
simply fail to see the advantage of taking away existing functionality
helpful for the user, even if only a few users.  Code simplification is
nice, but this change wouldn't suddenly make automake fast, all that
much more readable, or anything similar.  Barring that there is a
technical advantage for our users[1], I remain unconvinced.

Sorry,
Ralf

[1] A technical reason would be something like: erroring instead of
warning due to an unknown argument is better because it enables users
to write robust configure tests for arguments.  This doesn't apply here,
of course.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 7434 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#7434: When an incorrect option is used before
	--help/--version,
	automake behaviour is inconsistent with that of other GNU programs.
Date: Sun, 28 Nov 2010 19:30:03 +0100

On Sunday 28 November 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Fri, Nov 26, 2010 at 06:41:20PM CET:
> > > Besides, in the particular case of automake, how often do automake
> > > or aclocal get invoked directly?  To my experience, they are almost
> > > always invoked by autoreconf, ./bootstrap, or some custom autogen.sh
> > > script.
> 
> (aside: autoreconf works just in the same way as automake in this
> respect.)
> 
> > > > > Let's address this on bug-standards before changing any programs.
> > >
> > Now a decision has been reached on bug-standards *not* to tighten the
> > specification about the behaviour of --help and --version:
> >  <http://lists.gnu.org/archive/html/bug-standards/2010-11/msg00010.html>
> 
> Nor to forbid the current behavior of automake.
>
True, but as I said before I never considered the automake behaviour to
be wrong or not GCS-compliant, just (IMO uselessly) overzealous.
 
> > Considering that, do you agree to simplify the automake/aclocal option
> > parsing by not trying to process --help/--version options encountered
> > after invalid options?
> 
> I'm painfully aware that this is a near-bikeshed discussion, but I
> simply fail to see the advantage of taking away existing functionality
> helpful for the user, even if only a few users.
>
The point is that IMO such functionality is in fact not helpful for any
user.  But since this claim of mine lacks explicit evidence and is not
backed up by quantitative data ATM, I'll have to accept your decision.

> Code simplification is
> nice, but this change wouldn't suddenly make automake fast, all that
> much more readable, or anything similar.  Barring that there is a
> technical advantage for our users[1],
>
I don't think there is, unfortunately.

> I remain unconvinced.
> 
> Sorry,
> Ralf
> 

Regards,
   Stefano

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 7434 <at> debbugs.gnu.org
Subject: Re: bug#7434: When an incorrect option is used before
	--help/--version,
	automake behaviour is inconsistent with that of other GNU programs.
Date: Tue, 25 Jan 2011 18:36:09 +0100

tags 7434 wontfix
close 7434
thanks

Hello Ralf.

Since it seems to me that we "agreed to differ" on this issue, I'm
tagging the report as "wontfix".

Regards,
  Stefano

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7434-done <at> debbugs.gnu.org
Subject: Re: bug#7434: When an incorrect option is used before
	--help/--version, 
	automake behaviour is inconsistent with that of other GNU programs.
Date: Mon, 25 Jun 2012 12:13:45 +0200

On 01/25/2011 06:36 PM, Stefano Lattarini wrote:
> 
> Since it seems to me that we "agreed to differ" on this issue, I'm
> tagging the report as "wontfix".
> 
Actually, all of this discussion has basically become quite moot after we
have decided to share the option parsing code between Autoconf and Automake,
and implemented that decision:

  <http://git.savannah.gnu.org/cgit/automake.git/commit/?id=52246cc7>

I'm thus closing this bug report for good now, without tagging it as "wontfix".

Regards,
  Stefano

Previous Next

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