From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 14:34:00 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1F8137B409 for ; Mon, 21 Jul 2003 14:34:00 -0700 (PDT) Received: from pop018.verizon.net (pop018pub.verizon.net [206.46.170.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59F2543FB1 for ; Mon, 21 Jul 2003 14:33:59 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([141.149.47.46]) by pop018.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030721213358.KAYZ11703.pop018.verizon.net@mac.com> for ; Mon, 21 Jul 2003 16:33:58 -0500 Message-ID: <3F1C5C42.2090207@mac.com> Date: Mon, 21 Jul 2003 17:33:54 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <3F19C78A.7030008@mac.com> <20030719233535.GF77396@sunbay.com> <3F19D8D3.1040401@mac.com> <87vftyoy91.fsf@inf.enst.fr> <20030721192952.GE23226@zot.electricrain.com> <87el0j1x1x.fsf@inf.enst.fr> In-Reply-To: <87el0j1x1x.fsf@inf.enst.fr> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop018.verizon.net from [141.149.47.46] at Mon, 21 Jul 2003 16:33:58 -0500 Subject: Re: A patch to man to handle "man.1"... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2003 21:34:01 -0000 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 and get: 7-shot% man sync sync.2 sync.8 syncer.4 syncok.3 ...displayed, with additional 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