A patch to man to handle "man.1"...
cswiger at mac.com
Mon Jul 21 14:34:01 PDT 2003
Samuel Tardieu wrote:
[ ... ]
> It may cover all the cases, but I'm still undecided whether it makes
> things simpler or not :-) After all, it's the very same number of
> characters to type and complexity to add (your first implementation
> looked ok but had an hidden flaw, wouldn't your second have one as
Thanks for your feedback, Sam.
You've raised several points which I will attempt to address. First, any change
to 'man' probably will be expected to be 100% backwards-compatible with the
behavior of the existing command, at least as a controllable default.
Most people, particularly novices, are going to type "man foo" without any
section number. People often don't realize that there _are_ several 'versions'
of a manpage, or different manpages of the same basename in different sections.
Until you show them, such people don't even realize that "man 2 sync" and "man
8 sync" display different things.
The following use case helps address such problems.
Type "man sync" then <tab> and get:
7-shot% man sync
sync.2 sync.8 syncer.4 syncok.3
...displayed, with additional <tab>s cycling through the list of items. Whether
shell completion saves typing is less important than whether it can aid
comprehension. [This is in response to your comment vis-a-vis "simpler".]
I acknowledge the point that my patch would make "man foo.1" not work if there
was a foo.1.2 manpage in section two.
[ It is at least arguable that manpage authors should be able to use any
basename they want, although life is much less confusing if one restricts
basenames to not have a period in them. More to the point, such manpages exist,
On the other hand, the suggestion made by Chris appears to address the concern
of retaining the prior behavior for this case.
More information about the freebsd-stable