On Sun, Dec 18, 2005 at 03:09:15PM +0100, joerg@britannica.bec.de wrote:
> On Sun, Dec 18, 2005 at 01:42:49AM -0500, der Mouse wrote:
> > 
> > > I feel that long options such as "--requires" and "--required-by"
> > > would stick in my mind better, but maybe I'm just getting old and
> > > slow. :)
> > 
> > What I don't get is what's wrong with "-requires" and "-required-by".
> > But maybe *I*'m just old and slow.
> 
> The difference is that GNU style long options (--required-by) can be
> added to a program without changing the way getopt parsing works for
> short options. It is backward compatible. -requires doesn't work if you
> already have a -r option.

For full posix compliance, you should specify "-r equires", not "-requires"
although the latter is allowed for compatibility.  Having options like
that sucks bug time.

> Just saying "no long option" is IMO dumb, a carefully named long option
> is almost always easier to remember than a random short option. But
> that's not really the point. Please keep in mind, it doesn't change the
> way short options work and the amount of code is almost zero. To be
> precise, if every long option has a corresponding short option, all that
> is needed is getopt -> getopt_long and the mapping table. That's all!

Actually if programs use long options I find I have to read the man page
every time in order to find the exact spelling.  So there is little
benefit over reading the man page in order to find the the short option
letter.

There is also no real reason not to output the entire usage in response
to a command line error.
This really ought to say (briefly) what each option does!


	David

-- 
David Laight: david@l8s.co.uk