Subject: Re: using getopt_long (was Re: Bluetooth update)
To: Eric Haszlakiewicz <email@example.com>
From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
Date: 12/18/2005 23:45:34
At 14:55 Uhr -0600 18.12.2005, Eric Haszlakiewicz wrote:
>> Hauke Fath wrote:
>>Good point. Add to that the man page doesn't become more readable with the
>>mixture of short and long options.
> Really? Take a look at the tar man page. It looks quite reasonable to
Quite. Look at man gtar for comparison. They even have several
--long-options for one option in some places...
> In fact, I find it more readable than some short-option-only manpages,
>although that's really due to a reason independent of whether the options
>provided are long or short: the way it is structured clearly separates the
>actual option from the text that describes it.
Strongly seconded. When I use man pages as a reference to calling
conventions, I just _hate_ it when the options are described in flowed
text. Of those that I use regularly, `man 8 disklabel` is probably the
> An example of a man page
>that does _not_ do this, and is IMO not as readable, is shuffle(1).
Sure, but as long as the man page is short, say, less than two (80x24)
screens, you can get away with just anything. For me, --long-options just
decrease the s/n ratio.
> I think it's entirely natural to use the shorter options when you
>are familiar with their usage, but, when dealing with more esoteric
>parameters, having the ability to be more descriptive has benefits.
For the less-used options, I usually go to the man page (or, on some
'progressive distributions' that consider man pages optional, to the --help
output) since I then remember neither the exact functionality, nor the
"It's never straight up and down" (DEVO)