bug in option parsing

Automake has some option parsing bugs.  I tested these in automake 1.9.2, 
but the bugs appear to be in CVS head, too.

First, it does not gracefully handle the null string:
$ automake ''
Use of uninitialized value in concatenation (.) or string at 
/usr/autotool/devel/bin/automake line 7436.
automake: no Automake input file found for `'
automake: no input file found among supplied arguments

Obviously, the null string can't name a makefile, so a special-case error 
message would be better than the uninit value warning.

Second, it does not handle the POSIX-recommended -- argument as the ignored 
argument meaning end of options.
$ automake --
automake: unrecognized option `--'
automake: Try `/usr/autotool/devel/bin/automake --help' for more information.

Just recognizing -- isn't good enough, in case it was an argument to an 
option.  For example, 'automake --libdir -- --help' should print the help, 
while 'automake --libdir -- -- --help' should try to create a makefile named 
./--help with the libdir set to ./--.

Third, it does not treat --ver as ambiguous.  Other GNU programs accept all 
non-ambiguous prefixes of long option names, but report an error when two or 
more options share that prefix.
$ ls --al #--all or --almost-all
ls: option `--al' is ambiguous
Try `ls --help' for more information.
$ automake --ver
automake: reading autoconf [... running --verbose, rather than --version]

I'm not sure if these last two are bugs inherited from perl's 
Getopt::Long::GetOptions, but it would be nice to fix them in automake.

Finally, it would be nice if --help had a synonym of -h, and --version had a 
synonym of -V.

--
Someday, I might put a cute statement here.

Eric Blake             ebb9@xxxxxxx