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
