Re: gnulib-tool and short options

[Bruno Haible]

Hi Dmitriy,

> short options look nicer and is more native for some users who used
> to type short options. Can I add short options at least for different modes?
> 
> --list: -l
> --find: -f
> --import: -i
> --add-import: -a
> --remove-import: -r
> --update: -u
> --test: -t
> --megatest: -m
> --create-testdir: -td
> --create-megatestdir: -tm
> --copy-file: -c
> --extract-description: -xdescr/-xi
> --extract-comment: -xc
> --extract-status: -xs
> --extract-notice: -xn
> --extract-applicability: -xa
> --extract-filelist: -xf
> --extract-dependencies: -xdeps/-xd
> --extract-autoconf-snippet: -xac
> --extract-automake-snippet: -xam
> --extract-include-directive: -xinc/-xlink
> --extract-license: -xl
> --extract-maintainer: -xm
> 
> I know that usually GNU applications prefer to use long options, but
> I think that short options can be very useful. What do you think?

Short options are fine for programs people use daily and mostly
interactively. In these cases the users remember easily what the short
options mean.

gnulib-tool, on the other hand, is for most people a program they use
once a week at most, and additionally most invocations are from scripts
called autogen.sh or from bootstrap.conf. For these cases it is generally
better to have people use long options.

How to save people from typing long options? There is the bash completion
mode, which achieves this:

  $ git pu<TAB>
  pull   push

  $ gcc -W<TAB>
  Display all 166 possibilities? (y or n)
  ...

If someone could make this work for gnulib-tool:

  $ ./gnulib-tool --add-<TAB>

that would be awesome!

I think this is the way to go for gnulib-tool, because it leads to
unambiguous shell code without loading the users' brain with short options.

Bruno