Chris Pickett wrote:
> On 7/25/09, Garrett D'Amore <gdamore at sun.com> wrote:
>
>> My main concern here is the integration of manual page functionality into
>> the commands themselves. I see both benefits and costs. The benefit is
>> that the documentation is more likely to match the actual command. But part
>> of the cost is a much higher cost to perform localization for these, and
>> (depending on implementation) a potentially larger minimum size of the
>> binaries. (I'm assuming for the moment that the documentation is stored in
>> the binary, and the command is doing more than just executing some pipeline
>> to access the manual content from /usr/share/man or whatever.)
>>
>> Personally, I think --man, --html and --nroff and such is a dangerous
>> precedent to set.
>>
>
> What about --help and --version? Do you object to those options, too?
> Would you drop your concerns if Roland would rename --man to
> --extended-help?
>
When the --man output really is a manual page, I still object. It
doesn't matter what you call it -- the problem is that we have two
copies of the same information, the on-line manual page and the bits in
the binary.
Actually, if --man were to generate an actual man page by reading the
man text from the on-disk file that is formatted by man(1) itself, then
I would probably answer all (or very nearly so) of my concerns about this.
If you read my architectural concerns about this, then you'd understand
why I have problems with it. (Right now it looks like I'm very much in
the minority -- maybe a minority of one on this -- but if so then a vote
on the issue will be easy for the project team to achieve, and costs
nobody anything except me -- and the cost to me is that I'll have to
write the resulting opinion.)
- Garrett
