[Top][All Lists]
[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