A patch to man to handle "man.1"...

[Chuck Swiger]

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
> well?).

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.

Yes?  OK.

	--

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, 
so...moot. ]

On the other hand, the suggestion made by Chris appears to address the concern 
of retaining the prior behavior for this case.

-- 
-Chuck