bug-standards
[Top][All Lists]
Advanced

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

Re: program --help behavior


From: Stefano Lattarini
Subject: Re: program --help behavior
Date: Sat, 20 Nov 2010 15:03:26 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Saturday 20 November 2010, Ralf Wildenhues wrote:
> In <http://debbugs.gnu.org/7434>, the question has come up whether the
> --help argument to programs should work also when passed after invalid
> command-line arguments, i.e., whether
> 
> $ automake --invalid-option --help
> 
> was
> 1) allowed by the GCS to produce --help output,
> 2) required by the GCS to produce --help output.
> 
> The current GCS text has this:
> 
>   The standard `--help' option should output brief documentation for how
>   to invoke the program, on standard output, then exit successfully.
>   Other options and arguments should be ignored once this is seen, and
>   the program should not perform its normal function.
> 
> as well as this for --version:
> 
>   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.
> 
> indicating a no on (2) but not being clear on (1).
> 
My personal understanding is that (1) is allowed; but maybe the wording
can be clarified to make this explicit.

> I'd like to get a clarification on (1).  My personal take is that even
> a yes on (2) would be desirable
>
I strongly disagree on this.  IMO it would uselessly complicate the
implementation of many GNU packages for no real gain.

BTW, even the requirement (1) is a bit far-fetched (some might say that
just supporting `--version' and `--help' when they're the only command
line argument would be enough); *but* the behaviour mandated by (1) can
be genuinely useful in some (admittedly not very common) situations.

For example, assume we have a script like:

  #!/bin/sh
  AUTOMAKE=${AUTOMAKE-automake}
  ...
  # different code patch taken in case of different automake versions
  case `$AUTOMAKE --version` in
   *\ 1.1[0-9]*) have_newer_automake=yes;
   *) have_newer_automake=no;
  esac
  ...

Than, thanks to the behaviour mandated by (1), the script can continue
to work seamlessly even if the user puts e.g.:
  AUTOMAKE='automake -Wall'
or:
  AUTOMAKE='automake -Wno-portability'
in his environment.

Besides, the behavior specified by (1) is pretty easy to implement
if just a bit of care is used, since it requires no munging or extra
looping on the command line arguments.

> but that convenience may just be me.
> 
> Thanks,
> Ralf
> 

Regards,
  Stefano



reply via email to

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