From plocher@sac.sfbay.sun.com Wed Dec 12 23:25:37 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBD7Pb2I000381 for ; Wed, 12 Dec 2007 23:25:37 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBD7PbVe011422; Wed, 12 Dec 2007 23:25:37 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSZ00M018MMQG00@brm-avmta-1.central.sun.com>; Thu, 13 Dec 2007 00:25:34 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSZ0013G8MLKIA0@brm-avmta-1.central.sun.com>; Thu, 13 Dec 2007 00:25:33 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBD7PXgG056763; Wed, 12 Dec 2007 23:25:33 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBD6tYUY000093; Wed, 12 Dec 2007 22:55:34 -0800 (PST) Received: (from plocher@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id lBD6tY3T000089; Wed, 12 Dec 2007 22:55:34 -0800 (PST) Date: Wed, 12 Dec 2007 22:55:34 -0800 (PST) From: John Plocher Subject: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] To: PSARC-ext@sun.com Cc: mgerdts@gmail.com Message-id: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 10404 I am ARC-sponsoring this fasttrack from Mike Gerdts, an OpenSolaris community member. Mike is finding someone else to be his code/putback sponsor... Binding is to a minor release of the ON consolidation. As mentioned in 4.5 below: The interface stability of man(1) is documented as "Standard" ("Comitted", in updated terminology). This project alters the documented "Search Path" behavior when MANPATH is not set. This project also extends the documented interface to man(1) such that "name" arguments that specify a fully qualified or relative path (with at least one '/' character) alter the documented "Search Path" behavior. Corresponding interface changes apply to whatis(1), catman(1), and apropos(1) which are all hard links to man(1). -John Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: manwhich: Deriving MANPATH from PATH 1.2. Name of Document Author/Supplier: Author: Mike Gerdts 1.3 Date of This Document: 12 December, 2007 4. Technical Description 1. Introduction 1.1. Project/Component Working Name: manwhich: Deriving MANPATH from PATH 1.2. Name of Document Author/Supplier: Mike Gerdts OpenSolaris Contributor ID OS0018 1.3. Date of This Document: 12/12/2007 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The Community you expect to review your project: ON 1.4.2. The ARC(s) you expect to review your project: OpenSolaris ARC 1.5. Email Aliases: 1.5.2. Responsible Engineer: Mike Gerdts 1.5.4. Interest List: opensolaris-code@opensolaris.org 2. Project Summary 2.1. Project Description: When projects such as Indiana or individuals customize PATH, MANPATH is often left unset. This leads to confusion because man(1) will display the manual page for the wrong variant of a command. For example, if /usr/gnu/bin is at the front of the path, the default behavior of man(1) would most appropriately be to display a manual page from /usr/gnu/share/man rather than /usr/share/man. Similar, but slightly more complex, considerations are made for /usr/ucb and for invocations of man(1) that specify the path to the executable for which a man page is sought. 2.2. Risks and Assumptions: Traditional behavior and expectation is that /usr/share/man is the only directory searched in the case that the MANPATH environment variable is undefined. This behavior is documented in the man page for man. 3. Business Summary 3.1. Problem Area: This project increases the usability of online help accessed through the command line. History has shown that end-users have little success in keeping MANPATH in sync with PATH. 3.2. Market/Requester: Users and developers who wish to learn how to use the commands and utilities found in OpenSolaris. 3.3. Business Justification: As more FOSS functionality is added to various parts of OpenSolaris and its distros, keeping individual user's MANPATHs up to date gets harder and harder. This project effectively removes the requirement for most users to even bother setting it in the first place. 3.4. Competitive Analysis: Various Linux and *BSD distros provide similar or related mechanisms. 3.5. Opportunity Window/Exposure: // Time-to-market window, if any, and precision. 3.6. How will you know when you are done?: When the user has "unset MANPATH", "man foo" will find the man page associated with foo as determined by the user's PATH setting. 4. Technical Description: 4.1. Details: The source file man.c will be enhanced to refer to PATH only in the absence of MANPATH. Each element of PATH will be translated based into the appropriate MANPATH element based upon the following priorities: - Explicit transformation rule. For example, /usr/ucb in PATH translates to /usr/share/man,1b. - The parent directory of the PATH directory with /share/man appended. For example, /usr/gnu/bin becomes /usr/gnu/share/man. - The parent directory of the PATH directory with /man appended. For example, /opt/VRTSvcs/bin becomes /opt/VRTSvcs/man because /opt/VRTSvcs/share/man does not exist but /opt/VRTSvcs/man does. In addition and higher precedence to the above, if man is invoked referring to particular instance of a command (e.g. "man ./ls" or "man /usr/ucb/ps") the path transformation rules are applied using the directory component of the argument. In all cases where MANPATH is not defined and the path to a command is not specified /usr/share/man will be appended to MANPATH if it is not otherwise included based upon PATH transform rules. This ensures that sections other than 1* are accessible. A prototype of this behavior has been implemented and is available for review at http://cr.opensolaris.org/~mgerdts/manpath-from-path/. 4.2. Bug/RFE Number(s): 6634079 man should take hints from PATH when MANPATH not set 6516767 RFE:/etc/profile should set ${MANPATH} to ${PATH}/${LANG}-related value 4.3. In Scope: Described above. 4.4. Out of Scope: GNU utilities often times provide only stub man pages and more complete documentation using an alternative format known as "info". While translators from info to man do exist, this project does not seek to bridge this gap. 4.5. Interfaces: The interface stability of man(1) is documented as "Standard" ("Comitted", in updated terminology). This project alters the documented "Search Path" behavior when MANPATH is not set. This project also extends the documented interface to man(1) such that "name" arguments that specify a fully qualified or relative path (with at least one '/' character) alter the documented "Search Path" behavior. Corresponding interface changes apply to whatis(1), catman(1), and apropos(1) which are all hard links to man(1). 4.6. Doc Impact: man(1) man page will be enhanced as follows: OPERANDS The following operand is supported: name The name of a standard utility or a keyword. If the name contains a '/' character, the search path (See "Search Path") is altered to search only the man directory corresponding to the name argument. For example, if name is "/usr/ucb/ps" man will behave as if the MANPATH environment variable is set to /usr/share/man,1b. . . . Search Path Before searching for a given name, man constructs a list of candidate directories and sections. man searches for name in the directories specified by the MANPATH environment vari- able. If this variable is not set, a substitute MANPATH is constructed based upon the PATH environment variable. In all cases, except as described above when the name operand has a "/" character, /usr/share/man is searched. For each name operand that contains a "/" character, neither MANPATH nor PATH are used to construct the search path. . . . ENVIRONMENT VARIABLES . . . MANPATH A colon-separated list of directories; each directory can be followed by a comma-separated list of sections. If set, its value overrides the default directory search path, and man.cf as the default section search path. The -M and -s flags, in turn, override these values. The default directory search path is constructed based upon the contents of the PATH environment variable with /usr/share/man appended, as necessary. PATH The search path for commands. If MANPATH is not set, MANPATH is derived from PATH. While the behavior of whatis changes in the event that a relative or absoluate command path provided, the whatis(1) man page is sufficiently vague as to not require any changes to remain accurate. whatis(1) indicates that it is equivalent to "the -f option of the man(1) command" and as such refers users to more complete documentation. 4.7. Admin/Config Impact: On systems without MANPATH explicitly set by the administrator, but with customized PATH, man(1) may provide results that are more likely to be correct for the users' environments. The system administration overhead for "more correct" behavior of man is thus reduced. 4.8. HA Impact: None. 4.9. I18N/L10N Impact: Aside from man pages mentioned above, none. No error or usage strings are added modified or added. 4.10. Packaging & Delivery: No impact. 4.11. Security Impact: No impact. 4.12. Dependencies: None. 5. Reference Documents: 6634079 man should take hints from PATH when MANPATH not set This CR was opened as a means for tracking this specific change. Absent from the scope of this CR is the behavior if the name operand contains a / character. http://mail.opensolaris.org/pipermail/opensolaris-code/2007-November/006390.html Initial discussion of this functionality and initial code review of prototype. 6. Resources and Schedule: 6.1. Projected Availability: December, 2007. 6.2. Cost of Effort: One to two people-months of part-time work. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: ON 6.4.7. Target RTI Date/Release: Build 81, 82, or 83 (December 2007 - January 2008) 6.4.8. Target Code Design Review Date: December 13, 2007 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6.6.1. Rationale: Part of OpenSolaris 7. Prototype Availability: 7.1. Prototype Availability: prototype available December 12, 2007 at http://cr.opensolaris.org/~mgerdts/manpath-from-path/. This prototype offers nearly complete functionality. 7.2. Prototype Cost: 2 part-time programmer-weeks. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Thu Dec 13 05:03:27 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDD3Q12007042 for ; Thu, 13 Dec 2007 05:03:27 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBDD3PaM006947 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Dec 2007 13:03:25 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSZ00901O9OTA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 05:03:24 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSZ002IFO9NGFD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 05:03:24 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lBDCsnwT009319; Thu, 13 Dec 2007 07:54:49 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id lBDCsmFa009316; Thu, 13 Dec 2007 07:54:48 -0500 (EST) Date: Thu, 13 Dec 2007 07:54:48 -0500 From: James Carlson Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> To: John Plocher Cc: PSARC-ext@sun.com, mgerdts@gmail.com Message-id: <18273.11160.616476.890932@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> Status: RO Content-Length: 476 John Plocher writes: > The source file man.c will be enhanced to refer to PATH only in the > absence of MANPATH. Each element of PATH will be translated based > into the appropriate MANPATH element based upon the following > priorities: Yay! -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Lawrence.Lee@sun.com Thu Dec 13 07:25:08 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDFP866009565 for ; Thu, 13 Dec 2007 07:25:08 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBDFP7kR013774 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Dec 2007 07:25:08 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSZ00B0JUTVJI00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 08:25:07 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSZ00FA9UTOKY40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 08:25:01 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBDFP0dH025300 for ; Thu, 13 Dec 2007 07:25:00 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSZ00F01UQI0U00@fe-sfbay-09.sun.com> (original mail from Lawrence.Lee@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 07:25:00 -0800 (PST) Received: from [192.168.1.2] ([75.84.8.184]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSZ00JAVUTNAB80@fe-sfbay-09.sun.com>; Thu, 13 Dec 2007 07:25:00 -0800 (PST) Date: Thu, 13 Dec 2007 07:25:59 -0800 From: Lawrence Lee Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> Sender: Lawrence.Lee@sun.com To: John Plocher Cc: PSARC-ext@sun.com, mgerdts@gmail.com Message-id: <47614F07.3050706@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060828) Status: RO Content-Length: 1821 John Plocher wrote: > 4. Technical Description: > 4.1. Details: > The source file man.c will be enhanced to refer to PATH only in the > absence of MANPATH. Each element of PATH will be translated based > into the appropriate MANPATH element based upon the following > priorities: > > - Explicit transformation rule. For example, /usr/ucb in PATH > translates to /usr/share/man,1b. > - The parent directory of the PATH directory with /share/man > appended. For example, /usr/gnu/bin becomes > /usr/gnu/share/man. > - The parent directory of the PATH directory with /man > appended. For example, /opt/VRTSvcs/bin becomes > /opt/VRTSvcs/man because /opt/VRTSvcs/share/man does not exist > but /opt/VRTSvcs/man does. > > In addition and higher precedence to the above, if man is invoked > referring to particular instance of a command (e.g. "man ./ls" or > "man /usr/ucb/ps") the path transformation rules are applied using > the directory component of the argument. > > In all cases where MANPATH is not defined and the path to a command > is not specified /usr/share/man will be appended to MANPATH if it > is not otherwise included based upon PATH transform rules. This > ensures that sections other than 1* are accessible. > > A prototype of this behavior has been implemented and is available > for review at http://cr.opensolaris.org/~mgerdts/manpath-from-path/. > Would it be an appropriate extension to also use this behavior if MANPATH is defined, but the requested man page is not found? Will the transformation rules be hardcoded in the man.c or will there be a system file which defines the transformation rules. IOW - if sbin or exe is not included in the default transformation rules, could a system administrator extend those rules? From mgerdts@gmail.com Thu Dec 13 08:06:11 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDG6B0s011515 for ; Thu, 13 Dec 2007 08:06:11 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBDG68uX028463 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Dec 2007 08:06:11 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSZ00DBTWQAUF00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 09:06:10 -0700 (MST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSZ00F6MWQ7JM70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 09:06:08 -0700 (MST) Received: from relay17i.sun.com (ip127.net129179-4.block1.us.syntegra.com [129.179.4.127]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBDG67GD015884 for ; Thu, 13 Dec 2007 16:06:07 +0000 (GMT) Received: from mmp13es.sun.com ([160.41.209.23] [160.41.209.23]) by relay17i.sun.com with ESMTP id BT-MMP-18057 for PSARC-ext@sun.com; Thu, 13 Dec 2007 16:06:06 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.sun.com with ESMTP id BT-MMP-20062 for PSARC-ext@sun.com; Thu, 13 Dec 2007 16:06:06 +0000 (Z) Received: from wa-out-1112.google.com ([209.85.146.181] [209.85.146.181]) by relay1ib.sun.com with ESMTP id BT-MMP-42091 for PSARC-ext@sun.com; Thu, 13 Dec 2007 16:05:39 +0000 (Z) Received: by wa-out-1112.google.com with SMTP id l24so1262112waf.22 for ; Thu, 13 Dec 2007 08:03:21 -0800 (PST) Received: by 10.114.95.1 with SMTP id s1mr2410575wab.99.1197561801211; Thu, 13 Dec 2007 08:03:21 -0800 (PST) Received: by 10.115.19.14 with HTTP; Thu, 13 Dec 2007 08:03:21 -0800 (PST) Date: Thu, 13 Dec 2007 10:03:21 -0600 From: Mike Gerdts Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <47614F07.3050706@sun.com> To: Lawrence Lee Cc: John Plocher , PSARC-ext@sun.com Message-id: <65f8f3ad0712130803p4a91e120oc42daa2be30824f@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=3EtGnepxHw/0vYOz4Y+RqXI/lvhfY8ODV/wPi/TYRqM=; b=xeb5/6P5jIiqNJ4rA5XsnYszR723k5bu3FjSO6qClSdH30RbaGGswhDayUQZpAgmdveFRlvucwc0bEhNdgNET257IOLE10/S5ogttW3Z8H0AuhddMjoykLPG65jyjwahglnDavPvfzXHdwKX7hiGtDNHbgVRO+lASgSCyzj0mZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fYcP4HsVhMZxNvIyllIvHfC52bLuyyAXUd2368wm3mlVG2c/cmNMeZsk4UOLOa+7JUrzHfO3Fgj3H2tJ2iZPhbOxek0vzJJePJmHploDkpB/spewhlvczdBpSUG8JxQbWvwtmR3zCd3K0cjbpjA67L0BlSJvNjDKwi8yFhtDjmQ= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.235sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> Status: RO Content-Length: 2922 On Dec 13, 2007 9:25 AM, Lawrence Lee wrote: > John Plocher wrote: > > 4. Technical Description: > > 4.1. Details: > > The source file man.c will be enhanced to refer to PATH only in the > > absence of MANPATH. Each element of PATH will be translated based > > into the appropriate MANPATH element based upon the following > > priorities: > > > > - Explicit transformation rule. For example, /usr/ucb in PATH > > translates to /usr/share/man,1b. > > - The parent directory of the PATH directory with /share/man > > appended. For example, /usr/gnu/bin becomes > > /usr/gnu/share/man. > > - The parent directory of the PATH directory with /man > > appended. For example, /opt/VRTSvcs/bin becomes > > /opt/VRTSvcs/man because /opt/VRTSvcs/share/man does not exist > > but /opt/VRTSvcs/man does. > > > > In addition and higher precedence to the above, if man is invoked > > referring to particular instance of a command (e.g. "man ./ls" or > > "man /usr/ucb/ps") the path transformation rules are applied using > > the directory component of the argument. > > > > In all cases where MANPATH is not defined and the path to a command > > is not specified /usr/share/man will be appended to MANPATH if it > > is not otherwise included based upon PATH transform rules. This > > ensures that sections other than 1* are accessible. > > > > A prototype of this behavior has been implemented and is available > > for review at http://cr.opensolaris.org/~mgerdts/manpath-from-path/. > > > Would it be an appropriate extension to also use this behavior > if MANPATH is defined, but the requested man page is not found? My thought is that a person wishing to have legacy behavior can set MANPATH and avoid using name arguments with a /. If it were extended as you suggest those requesting, legacy behavior would not be available. If there is consensus that such an extension would be desirable, my approach would likely be to implement and document as appending the derived manpath onto any (possibly null) value from the MANPATH environment variable. > Will the transformation rules be hardcoded in the man.c > or will there be a system file which defines the transformation rules. > IOW - if sbin or exe is not included in the default transformation rules, > could a system administrator extend those rules? Currently they are hard-coded because I don't expect that these rules will need frequent updates. However, I could see where ISV's may want to append on things like: /opt/VRTSvlic/bin /opt/VRTS/man If this route is taken, where should the config file go? Should it have a syntax that allows future man configuration or be a simple two-column file with comments allowed? -- Mike Gerdts http://mgerdts.blogspot.com/ From Bart.Blanquart@sun.com Thu Dec 13 09:01:59 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDH1xN6012865 for ; Thu, 13 Dec 2007 09:01:59 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBDH1woY015704 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Dec 2007 09:01:59 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSZ00245ZB9JL00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 09:01:57 -0800 (PST) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSZ00L8JZB8WO70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 09:01:57 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBDH1tGP009484 for ; Thu, 13 Dec 2007 17:01:55 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSZ00401Z2CYE00@fe-emea-10.sun.com> (original mail from Bart.Blanquart@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 17:01:55 +0000 (GMT) Received: from [129.159.231.198] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSZ00ALJZB2IE80@fe-emea-10.sun.com>; Thu, 13 Dec 2007 17:01:50 +0000 (GMT) Date: Thu, 13 Dec 2007 18:01:47 +0100 From: Bart Blanquart Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <65f8f3ad0712130803p4a91e120oc42daa2be30824f@mail.gmail.com> Sender: Bart.Blanquart@sun.com To: Mike Gerdts Cc: Lawrence Lee , John Plocher , PSARC-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> <65f8f3ad0712130803p4a91e120oc42daa2be30824f@mail.gmail.com> Status: RO Content-Length: 1709 > >> Will the transformation rules be hardcoded in the man.c >> or will there be a system file which defines the transformation >> rules. >> IOW - if sbin or exe is not included in the default transformation >> rules, >> could a system administrator extend those rules? > > Currently they are hard-coded because I don't expect that these rules > will need frequent updates. However, I could see where ISV's may > want to append on things like: > > /opt/VRTSvlic/bin /opt/VRTS/man > > If this route is taken, where should the config file go? Should it > have a syntax that allows future man configuration or be a simple > two-column file with comments allowed? The option to make the transformations configurable could be useful for other os.o distributions that have a different layout (changing a configuration file is easier to maintain than changing something in the source tree) and, come to think of it, might this not be useful for anyone delivering executables and manpages? If these transformations are configured correctly it removes the need for users to deal with MANPATH at all, though to keep things manageable some kind of wildcarding would be useful: e.g. if there's /opt/ /bin in the PATH, add /opt//man to the corresponding MANPATH (except if a more specific, non-wildcarded rule applies). Whatever syntax is chosen I would expect that it would get updated automatically by packages/the packaging system, so something easily updated programmatically (but, pending those packaging software to add this information to their packages admins would need to maintain this information so ideally it should be something readable too). Bart From danek.duvall@sun.com Thu Dec 13 09:21:37 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDHLamN013007 for ; Thu, 13 Dec 2007 09:21:37 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBDHKuZt014996 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Dec 2007 01:21:35 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT00031P07W3D00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 09:21:32 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT000L4007VWM80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 09:21:31 -0800 (PST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id lBDHLTBo005509; Thu, 13 Dec 2007 09:21:29 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lBDHLTg1005767; Thu, 13 Dec 2007 09:21:29 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id lBDHLTX4005766; Thu, 13 Dec 2007 09:21:29 -0800 (PST) Date: Thu, 13 Dec 2007 09:21:29 -0800 From: Danek Duvall Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: To: Bart Blanquart Cc: Mike Gerdts , Lawrence Lee , PSARC-ext@sun.com, John Plocher Message-id: <20071213172129.GU17670@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> <65f8f3ad0712130803p4a91e120oc42daa2be30824f@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 952 On Thu, Dec 13, 2007 at 06:01:47PM +0100, Bart Blanquart wrote: > The option to make the transformations configurable could be useful > for other os.o distributions that have a different layout (changing a > configuration file is easier to maintain than changing something in > the source tree) and, come to think of it, might this not be useful > for anyone delivering executables and manpages? If they wanted to put executables and manpages in willy-nilly places, sure. But is there any real need to support that kind of installation? How often do you envision such a situation being required, rather than just being a mistake in how a component is integrated? Is ../man or ../share/man really going to be an issue all that often, particularly if that directory could be a symlink to the real one (as in Mike's /opt/VRTSvlic/bin /opt/VRTS/man example)? Rope is great and all, but there's no need to deliver it in pre-made nooses. Danek From gdamore@sun.com Thu Dec 13 10:07:13 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDI7Dso013757 for ; Thu, 13 Dec 2007 10:07:13 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBDI7CG9000439 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Dec 2007 11:07:12 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT0005032C03300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 10:07:12 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT000LGF2C0WMA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 10:07:12 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBDI7BAl014102 for ; Thu, 13 Dec 2007 10:07:11 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT000801193ZB00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 10:07:11 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT0001NC2BXCA80@fe-sfbay-10.sun.com>; Thu, 13 Dec 2007 10:07:09 -0800 (PST) Date: Thu, 13 Dec 2007 10:01:37 -0800 From: "Garrett D'Amore" Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <20071213172129.GU17670@zruty.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Danek Duvall Cc: Bart Blanquart , Mike Gerdts , Lawrence Lee , PSARC-ext@sun.com, John Plocher Message-id: <47617381.5050004@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> <65f8f3ad0712130803p4a91e120oc42daa2be30824f@mail.gmail.com> <20071213172129.GU17670@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1536 Danek Duvall wrote: > On Thu, Dec 13, 2007 at 06:01:47PM +0100, Bart Blanquart wrote: > > >> The option to make the transformations configurable could be useful >> for other os.o distributions that have a different layout (changing a >> configuration file is easier to maintain than changing something in >> the source tree) and, come to think of it, might this not be useful >> for anyone delivering executables and manpages? >> > > If they wanted to put executables and manpages in willy-nilly places, sure. > But is there any real need to support that kind of installation? How often > do you envision such a situation being required, rather than just being a > mistake in how a component is integrated? Is ../man or ../share/man really > going to be an issue all that often, particularly if that directory could > be a symlink to the real one (as in Mike's /opt/VRTSvlic/bin /opt/VRTS/man > example)? > > Rope is great and all, but there's no need to deliver it in pre-made > nooses. > > Danek > Ever install a package in ~? It does come up... ./configure --prefix=${HOME} I suspect it comes up more often than you think. I also know of at least one major site that uses /pkg/${PKG}/(bin,man,info,lib} etc. Right now they have the notion of "subscribing" to a package, which basically puts /pkg/${PKG}/bin in the PATH, and /pkg/${PKG}/man in the MANPATH. It would be nicer if they only had to worry about PATH, and didn't have to worry about MANPATH being out of sync with PATH. -- Garrett From danek.duvall@sun.com Thu Dec 13 10:26:36 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDIQZlM014171 for ; Thu, 13 Dec 2007 10:26:36 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBDIQG8q003878; Thu, 13 Dec 2007 18:26:33 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT000503386OX00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Dec 2007 10:26:30 -0800 (PST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT000LPZ385XBA0@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Dec 2007 10:26:29 -0800 (PST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id lBDIQS4D016095; Thu, 13 Dec 2007 10:26:28 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lBDIQRNF007033; Thu, 13 Dec 2007 10:26:27 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id lBDIQRrw007032; Thu, 13 Dec 2007 10:26:27 -0800 (PST) Date: Thu, 13 Dec 2007 10:26:27 -0800 From: Danek Duvall Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <47617381.5050004@sun.com> To: "Garrett D'Amore" Cc: Bart Blanquart , Mike Gerdts , Lawrence Lee , PSARC-ext@sun.com, John Plocher Message-id: <20071213182627.GA6925@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> <65f8f3ad0712130803p4a91e120oc42daa2be30824f@mail.gmail.com> <20071213172129.GU17670@zruty.sfbay.sun.com> <47617381.5050004@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 912 On Thu, Dec 13, 2007 at 10:01:37AM -0800, Garrett D'Amore wrote: > Ever install a package in ~? It does come up... ./configure > --prefix=${HOME} Then executables go in ~/bin and man pages in ~/man. Thus ../man works just fine. What's the special case here? > I also know of at least one major site that uses > /pkg/${PKG}/(bin,man,info,lib} etc. Right now they have the notion of > "subscribing" to a package, which basically puts /pkg/${PKG}/bin in the > PATH, and /pkg/${PKG}/man in the MANPATH. Ditto here. > It would be nicer if they only had to worry about PATH, and didn't have > to worry about MANPATH being out of sync with PATH. Sure, absolutely. But if Mike's proposal is to look in ../man, then this likely handles 99% of the cases or more. Show me a case where this doesn't work today. Otherwise, why not push fixing this hole until we actually find that the hole exists? Danek From gdamore@sun.com Thu Dec 13 11:42:26 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDJgPJT015609 for ; Thu, 13 Dec 2007 11:42:26 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBDJgNUw011934 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Dec 2007 03:42:24 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT0006036QMTC00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 13 Dec 2007 12:42:22 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT0001476QLBZ60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 13 Dec 2007 12:42:21 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBDJgLkI027818 for ; Thu, 13 Dec 2007 11:42:21 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT0008016G6BK00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 13 Dec 2007 11:42:21 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT000KAB6QD3CB0@fe-sfbay-09.sun.com>; Thu, 13 Dec 2007 11:42:14 -0800 (PST) Date: Thu, 13 Dec 2007 11:36:41 -0800 From: "Garrett D'Amore" Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <20071213182627.GA6925@zruty.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Danek Duvall Cc: Bart Blanquart , Mike Gerdts , Lawrence Lee , PSARC-ext@sun.com, John Plocher Message-id: <476189C9.4090307@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> <65f8f3ad0712130803p4a91e120oc42daa2be30824f@mail.gmail.com> <20071213172129.GU17670@zruty.sfbay.sun.com> <47617381.5050004@sun.com> <20071213182627.GA6925@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1156 Danek Duvall wrote: > On Thu, Dec 13, 2007 at 10:01:37AM -0800, Garrett D'Amore wrote: > > >> Ever install a package in ~? It does come up... ./configure >> --prefix=${HOME} >> > > Then executables go in ~/bin and man pages in ~/man. Thus ../man works > just fine. What's the special case here? > > >> I also know of at least one major site that uses >> /pkg/${PKG}/(bin,man,info,lib} etc. Right now they have the notion of >> "subscribing" to a package, which basically puts /pkg/${PKG}/bin in the >> PATH, and /pkg/${PKG}/man in the MANPATH. >> > > Ditto here. > > >> It would be nicer if they only had to worry about PATH, and didn't have >> to worry about MANPATH being out of sync with PATH. >> > > Sure, absolutely. But if Mike's proposal is to look in ../man, then this > likely handles 99% of the cases or more. Show me a case where this doesn't > work today. Otherwise, why not push fixing this hole until we actually > find that the hole exists? > Ah, I misunderstood... I thought you were arguing against searching ../man, since that's not the case, I'll shut up now. :-) - Garrett > Danek > From jek3@sun.com Thu Dec 13 11:43:41 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDJheuQ015727 for ; Thu, 13 Dec 2007 11:43:40 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBDJhbSf032041 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Dec 2007 12:43:40 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT000B116SRGZ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 11:43:39 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT00086K6SRM830@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 11:43:39 -0800 (PST) Received: from [129.150.12.37] (vpn-129-150-12-37.SFBay.Sun.COM [129.150.12.37]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lBDJhabh220585; Thu, 13 Dec 2007 11:43:37 -0800 (PST) Date: Thu, 13 Dec 2007 09:43:21 -1000 From: Joseph Kowalski Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> To: John Plocher Cc: PSARC-ext@sun.com, mgerdts@gmail.com Message-id: <47618B59.6030704@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 2173 Glad to see you are making an enhancement in this area. I have an observation which is only marginally related to the actual content of this proposal... > - The parent directory of the PATH directory with /share/man > appended. For example, /usr/gnu/bin becomes > /usr/gnu/share/man. > The semantic of "share", as in "/usr/share", is that files here are platform independent. This not only means "ISA", but it also can mean "endian-ness". This directory was invented by Sun to allow these files to be shared by diskless clients of different flavors: mount server:/.../hostname.root / mount server:/.../$ISA/usr /usr mount server:/.../usr/share /usr/share Yea, when it was invented, a couple of 10's of megabytes of rotating rust was significant. I doubt anyone does this anymore, but its legacy. My point is that while /usr/share has a real use, all the other "share" directories are just noise (at best) and misleading (at worse). Nobody adds them to the share command on a server. We shouldn't do anything which validates this practice, hence I think the above step should be deleted from your algorithm. I guess the rationale is that Linux (and the LSB/FSH) had no clue as to why Sun/Solaris (er, SunOS) had something called /usr/share and it seems they just propagated it with out understanding why. (Actually, to be fair, the same can be said about many employees.) Hence, as Sun imports FOSS, it probably isn't worth the effort (or confusion) of refactoring these local directories. We could just add a link "man -> ./share/man" as needed. That's what I'd like. However, I'd accept wording on the man(1) (and related) pages that highlighted that the second set above is just a legacy/convenience thing. We don't want to validate the practice of sprinkling "share" directories around. Also, along this line, shouldn't the algorithm reverse the priority of steps #2 and #3? Finally, for this proposal to be complete, I think you need to enumerate the cases handled by #1 (the explicit translation rules). I doubt they are controversial, but they should be enumerated for completeness. - thanks, - jek3 From jek3@sun.com Thu Dec 13 11:50:43 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDJogXK015745 for ; Thu, 13 Dec 2007 11:50:43 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBDJoaDo008312; Thu, 13 Dec 2007 19:50:37 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT000C0D74CLV00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Dec 2007 11:50:36 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT0008ZX74BM930@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Dec 2007 11:50:35 -0800 (PST) Received: from [129.150.12.37] (vpn-129-150-12-37.SFBay.Sun.COM [129.150.12.37]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lBDJoY33221977; Thu, 13 Dec 2007 11:50:34 -0800 (PST) Date: Thu, 13 Dec 2007 09:50:20 -1000 From: Joseph Kowalski Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <47614F07.3050706@sun.com> To: Lawrence Lee Cc: John Plocher , PSARC-ext@sun.com, mgerdts@gmail.com Message-id: <47618CFC.5070707@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 733 Lawrence Lee wrote: > Would it be an appropriate extension to also use this behavior > if MANPATH is defined, but the requested man page is not found? I think not. If the user explicitly sets MANPATH, the man command shouldn't second guess him. (To do so, would probably be considered an incompatible change anyway.) > Will the transformation rules be hardcoded in the man.c > or will there be a system file which defines the transformation rules. > IOW - if sbin or exe is not included in the default transformation rules, > could a system administrator extend those rules? Interesting idea. However, I expect that the syntax for the rules may be hard to get right. I guess its up to Mike if he wants to pursue this. - jek3 From jek3@sun.com Thu Dec 13 11:59:11 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDJxAUt016131 for ; Thu, 13 Dec 2007 11:59:10 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBDJx3dJ018270; Fri, 14 Dec 2007 03:59:06 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT000D097IFRA00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Dec 2007 11:59:04 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT00081Q7IDM950@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Dec 2007 11:59:02 -0800 (PST) Received: from [129.150.12.37] (vpn-129-150-12-37.SFBay.Sun.COM [129.150.12.37]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lBDJx0s0223505; Thu, 13 Dec 2007 11:59:00 -0800 (PST) Date: Thu, 13 Dec 2007 09:58:46 -1000 From: Joseph Kowalski Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: To: Bart Blanquart Cc: Mike Gerdts , Lawrence Lee , John Plocher , PSARC-ext@sun.com Message-id: <47618EF6.6040203@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> <65f8f3ad0712130803p4a91e120oc42daa2be30824f@mail.gmail.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 2316 Bart Blanquart wrote: >> >>> Will the transformation rules be hardcoded in the man.c >>> or will there be a system file which defines the transformation rules. >>> IOW - if sbin or exe is not included in the default transformation >>> rules, >>> could a system administrator extend those rules? >> >> Currently they are hard-coded because I don't expect that these rules >> will need frequent updates. However, I could see where ISV's may >> want to append on things like: >> >> /opt/VRTSvlic/bin /opt/VRTS/man >> >> If this route is taken, where should the config file go? Should it >> have a syntax that allows future man configuration or be a simple >> two-column file with comments allowed? > > The option to make the transformations configurable could be useful > for other os.o distributions that have a different layout (changing a > configuration file is easier to maintain than changing something in > the source tree) and, come to think of it, might this not be useful > for anyone delivering executables and manpages? If these > transformations are configured correctly it removes the need for users > to deal with MANPATH at all, though to keep things manageable some > kind of wildcarding would be useful: e.g. if there's > /opt//bin in the PATH, add /opt//man to the > corresponding MANPATH (except if a more specific, non-wildcarded rule > applies). > > Whatever syntax is chosen I would expect that it would get updated > automatically by packages/the packaging system, so something easily > updated programmatically (but, pending those packaging software to add > this information to their packages admins would need to maintain this > information so ideally it should be something readable too). > > Bart I'm not sure who you want to be able to change this file. In the past, this would be "root", but now it would be controlled by RBAC. Anyway, a normal user wouldn't be able to change this. (Yea, there could be a $HOME/.file to allow this, but that is *way* too much complexity.) Also, don't forget how difficult for package creators to get "editable" files right. They always seem to trip over something unexpected added by another package. This is "rope" I would not suggest be used. A best practice would suggest not to do this. - jek3 From mgerdts@gmail.com Thu Dec 13 12:10:42 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDKAfsr016361 for ; Thu, 13 Dec 2007 12:10:42 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBDKARm4022531 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Dec 2007 04:10:40 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT00081P81PSI00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 13:10:37 -0700 (MST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT0001DZ81OC560@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 13:10:37 -0700 (MST) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBDJnpCa000894 for ; Thu, 13 Dec 2007 20:10:36 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay43i.sun.com with ESMTP id BT-MMP-788176 for PSARC-ext@sun.com; Thu, 13 Dec 2007 20:10:36 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms48es.sun.com with ESMTP id BT-MMP-2506288 for PSARC-ext@sun.com; Thu, 13 Dec 2007 20:10:36 +0000 (Z) Received: from nz-out-0506.google.com ([64.233.162.229] [64.233.162.229]) by relay4i.sun.com with ESMTP id BT-MMP-12160201 for PSARC-ext@sun.com; Thu, 13 Dec 2007 20:10:35 +0000 (Z) Received: by nz-out-0506.google.com with SMTP id z31so429851nzd.23 for ; Thu, 13 Dec 2007 12:10:26 -0800 (PST) Received: by 10.114.151.13 with SMTP id y13mr1334425wad.60.1197576625085; Thu, 13 Dec 2007 12:10:25 -0800 (PST) Received: by 10.115.19.14 with HTTP; Thu, 13 Dec 2007 12:10:25 -0800 (PST) Date: Thu, 13 Dec 2007 14:10:25 -0600 From: Mike Gerdts Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <47618B59.6030704@sun.com> To: Joseph Kowalski Cc: John Plocher , PSARC-ext@sun.com Message-id: <65f8f3ad0712131210l3dda6260lcb712bc29e7b9429@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OGD4JZR6npCVvpvVbQUeO7B6tQegHO8z07ZzXp7/qSQ=; b=g9xTCdQeQHPWvipJohxwtEsZhzhoKXjAC/5z5TOAYXAl/AzKxBqb0ZSZR6XHZZJy+ve9BGUXXPamz5hIbX8HnjFgtMFKiPeYSqp1ZVMVJ6E7QmtcRegfVoqFxY5VWSg8PazXBSpFmgu1H+bGXsMqGnv4YK6HbfSzE9xFXJ8eFmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WGg87B466dCtyL7Th2aDi9zaN57oSeGfDC2lUpRV49nF0RNgkMPZtuMou79DsZude3uuXyZgAXRYxW/Cfsz0wnmE2JY66xfPCO/KycZ6HZ0dnuc2I2dUZPfvSi2e7D/pbFgzzihYUXovM5MMoZkYleHhXdEA16X0OBimyhgJ8nU= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47618B59.6030704@sun.com> Status: RO Content-Length: 3552 On Dec 13, 2007 1:43 PM, Joseph Kowalski wrote: > > Glad to see you are making an enhancement in this area. > > I have an observation which is only marginally related to the actual > content of this proposal... > > - The parent directory of the PATH directory with /share/man > > appended. For example, /usr/gnu/bin becomes > > /usr/gnu/share/man. > > > The semantic of "share", as in "/usr/share", is that files here are > platform independent. > This not only means "ISA", but it also can mean "endian-ness". This > directory was > invented by Sun to allow these files to be shared by diskless clients of > different flavors: > > mount server:/.../hostname.root / > mount server:/.../$ISA/usr /usr > mount server:/.../usr/share /usr/share > > Yea, when it was invented, a couple of 10's of megabytes of rotating > rust was > significant. I doubt anyone does this anymore, but its legacy. > > My point is that while /usr/share has a real use, all the other "share" > directories are > just noise (at best) and misleading (at worse). Nobody adds them to the > share > command on a server. > > We shouldn't do anything which validates this practice, hence I think > the above > step should be deleted from your algorithm. > > I guess the rationale is that Linux (and the LSB/FSH) had no clue as to why > Sun/Solaris (er, SunOS) had something called /usr/share and it seems > they just > propagated it with out understanding why. (Actually, to be fair, the > same can > be said about many employees.) Hence, as Sun imports FOSS, it probably > isn't worth the effort (or confusion) of refactoring these local > directories. We > could just add a link "man -> ./share/man" as needed. The /usr/man -> share/man link does exist today and is documented in filesystem(5). I'm not sure that I am ready to take on filesystem(5) today. > That's what I'd like. > > However, I'd accept wording on the man(1) (and related) pages that > highlighted > that the second set above is just a legacy/convenience thing. We don't > want to > validate the practice of sprinkling "share" directories around. > > Also, along this line, shouldn't the algorithm reverse the priority of > steps #2 and #3? This working in filesystem(5) suggests it may be the right thing to do. Unfortunately, those that created /usr/gnu/{bin,share/man} didn't take it into consideration: /usr/share/man Platform-independent sharable manual pages. An approved installation location for bundled Solaris software. The analogous location for add-on system software or for applications is /opt/packagename/man. Given that there is now more focus on adding to /usr/bin rather than adding more directories like /usr/sfw and /usr/gnu, there should be relatively few *Solaris directories that subscribe to share/man. Since third parties should be installing software to /opt/packagename with /opt/packagename/man as the man directory, reversing the search order to prefer man over share/man seems appropriate. > Finally, for this proposal to be complete, I think you need to enumerate > the cases > handled by #1 (the explicit translation rules). I doubt they are > controversial, but > they should be enumerated for completeness. The mapping is... /sbin /usr/share/man,1m /usr/sbin /usr/share/man,1m /usr/ucb /usr/share/man,1b /usr/bin /usr/share/man,1,1m,1s,1t,1c,1f /usr/xpg4/bin /usr/share/man,1 /usr/xpg6/bin /usr/share/man,1 -- Mike Gerdts http://mgerdts.blogspot.com/ From mgerdts@gmail.com Thu Dec 13 12:16:43 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDKGg8r016472 for ; Thu, 13 Dec 2007 12:16:43 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBDKGbue024369 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Dec 2007 04:16:41 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT0009018BSQZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 12:16:40 -0800 (PST) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT00085W8BSE420@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 12:16:40 -0800 (PST) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBDKBkrl027118 for ; Thu, 13 Dec 2007 20:16:39 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay42i.sun.com with ESMTP id BT-MMP-8852 for PSARC-ext@sun.com; Thu, 13 Dec 2007 20:16:39 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms49es.sun.com with ESMTP id BT-MMP-2305929 for PSARC-ext@sun.com; Thu, 13 Dec 2007 20:16:39 +0000 (Z) Received: from wa-out-1112.google.com ([209.85.146.183] [209.85.146.183]) by relay4i.sun.com with ESMTP id BT-MMP-12257035 for PSARC-ext@sun.com; Thu, 13 Dec 2007 20:16:39 +0000 (Z) Received: by wa-out-1112.google.com with SMTP id l24so1389976waf.22 for ; Thu, 13 Dec 2007 12:16:28 -0800 (PST) Received: by 10.114.13.1 with SMTP id 1mr2713993wam.106.1197576988555; Thu, 13 Dec 2007 12:16:28 -0800 (PST) Received: by 10.115.19.14 with HTTP; Thu, 13 Dec 2007 12:16:28 -0800 (PST) Date: Thu, 13 Dec 2007 14:16:28 -0600 From: Mike Gerdts Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <47618CFC.5070707@sun.com> To: Joseph Kowalski Cc: Lawrence Lee , John Plocher , PSARC-ext@sun.com Message-id: <65f8f3ad0712131216r7941d7car8ac74185a125a0e7@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=LdTx2+OvHwXnF8CqvBY8/69IYUztiSQls87glt7K9zg=; b=DihZV7lGGdJvB/6ROXhIDDL2wSk33C8Xe3RnDUmLgEKM3CKcZp/Qv+ULU8txOdyJ1rl/qhIHQhBDl7tM8d17oOcguRGChiBohyj5rKEv+8KmdnxSrNFfjJrQuKgBF2zcupiiTIlL5p9mG5FVwduduGjcV2y9xpdtJqAA7Y8OKXs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=W51+ErDEpnJhEXTFpcO1vAsqebmfFzcAGp1gNqYj6d2KVH1x2tk2YR/tGomDlklmLe2n7DK0Gu6l+5jHLhdbON+4rrhedQR0HDFjjVF5PJunM3hnmRfk3O7CPDyimFm6MufHN42RQ/h2z5or0SVTdCi4Xomp1AYtgC+5bmzokNI= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> <47618CFC.5070707@sun.com> Status: RO Content-Length: 924 On Dec 13, 2007 1:50 PM, Joseph Kowalski wrote: > Lawrence Lee wrote: > > Will the transformation rules be hardcoded in the man.c > > or will there be a system file which defines the transformation rules. > > IOW - if sbin or exe is not included in the default transformation rules, > > could a system administrator extend those rules? > Interesting idea. However, I expect that the syntax for the rules may > be hard to get right. I guess its up to Mike if he wants to pursue this. If I did this, I would prefer to make it a simple two column file that maps path to manpath elements. For sanity of those that do packaging, or have other reasons to script modifications, it would likely be helpful to keep the file private but provide stable options to manage changes to the configuration. However, I am not convinced that it is needed or worth the effort. -- Mike Gerdts http://mgerdts.blogspot.com/ From Nicolas.Williams@sun.com Thu Dec 13 12:46:58 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDKkw9B017094 for ; Thu, 13 Dec 2007 12:46:58 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBDKku9H049691; Thu, 13 Dec 2007 13:46:57 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT000B0B9Q72N00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Dec 2007 12:46:55 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT0008ZC9Q6E040@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Dec 2007 12:46:54 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lBDKkrkj014807; Thu, 13 Dec 2007 14:46:53 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lBDKkqnr014806; Thu, 13 Dec 2007 14:46:52 -0600 (CST) Date: Thu, 13 Dec 2007 14:46:52 -0600 From: Nicolas Williams Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <65f8f3ad0712131216r7941d7car8ac74185a125a0e7@mail.gmail.com> To: Mike Gerdts Cc: Joseph Kowalski , Lawrence Lee , PSARC-ext@sun.com, John Plocher Mail-followup-to: Mike Gerdts , Joseph Kowalski , Lawrence Lee , PSARC-ext@sun.com, John Plocher Message-id: <20071213204652.GM14367@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> <47618CFC.5070707@sun.com> <65f8f3ad0712131216r7941d7car8ac74185a125a0e7@mail.gmail.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 283 On Thu, Dec 13, 2007 at 02:16:28PM -0600, Mike Gerdts wrote: > However, I am not convinced that it is needed or worth the effort. I say we leave that for another day, if we ever do need it. In the meantime packagers not used to having $BASEDIR/bin/../man can get by with symlinks. From jek3@sun.com Thu Dec 13 12:48:59 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDKmwOE017152 for ; Thu, 13 Dec 2007 12:48:59 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBDKmpYj006484 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Dec 2007 04:48:58 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT000K0R9TIZ900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 12:48:54 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT0008KQ9TGM8C0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 12:48:52 -0800 (PST) Received: from [129.150.12.37] (vpn-129-150-12-37.SFBay.Sun.COM [129.150.12.37]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lBDKmpsJ232061; Thu, 13 Dec 2007 12:48:51 -0800 (PST) Date: Thu, 13 Dec 2007 10:48:37 -1000 From: Joseph Kowalski Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <65f8f3ad0712131210l3dda6260lcb712bc29e7b9429@mail.gmail.com> To: Mike Gerdts Cc: John Plocher , PSARC-ext@sun.com Message-id: <47619AA5.5020309@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47618B59.6030704@sun.com> <65f8f3ad0712131210l3dda6260lcb712bc29e7b9429@mail.gmail.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 3230 Mike Gerdts wrote: > On Dec 13, 2007 1:43 PM, Joseph Kowalski wrote: > >> We could just add a link "man -> ./share/man" as needed. >> > > The /usr/man -> share/man link does exist today and is documented in > filesystem(5). I'm not sure that I am ready to take on filesystem(5) > today. > Opps. I was trying to *not* search "../share/man" based on the PATH setting. > >> That's what I'd like. >> >> However, I'd accept wording on the man(1) (and related) pages that >> highlighted >> that the second set above is just a legacy/convenience thing. We don't >> want to >> validate the practice of sprinkling "share" directories around. >> I can't find a clear response here... :-) >> Also, along this line, shouldn't the algorithm reverse the priority of >> steps #2 and #3? >> > > This working in filesystem(5) suggests it may be the right thing to > do. Unfortunately, those that created /usr/gnu/{bin,share/man} didn't > take it into consideration: > > /usr/share/man > > Platform-independent sharable manual pages. An approved > installation location for bundled Solaris software. The > analogous location for add-on system software or for > applications is /opt/packagename/man. > > Given that there is now more focus on adding to /usr/bin rather than > adding more directories like /usr/sfw and /usr/gnu, there should be > relatively few *Solaris directories that subscribe to share/man. > Since third parties should be installing software to /opt/packagename > with /opt/packagename/man as the man directory, reversing the search > order to prefer man over share/man seems appropriate. > Great! (Now lets resolve if ../share/man should even be in the algorithm.) >> Finally, for this proposal to be complete, I think you need to enumerate >> the cases >> handled by #1 (the explicit translation rules). I doubt they are >> controversial, but >> they should be enumerated for completeness. >> > > The mapping is... > > /sbin /usr/share/man,1m > /usr/sbin /usr/share/man,1m > /usr/ucb /usr/share/man,1b > /usr/bin /usr/share/man,1,1m,1s,1t,1c,1f > /usr/xpg4/bin /usr/share/man,1 > /usr/xpg6/bin /usr/share/man,1 > I'm not sure I'm getting it. These are absolute paths. These transforms don't apply to any random PATH/../man searches, right? To make this clear, given the PATH: /usr/bin:/usr/sbin:/usr/ucb There would be no effective change due to this proposal. /usr/sbin:/usr/bin:/usr/ucb Would only change the priority of a page under (1M) over (1) (but hopefully we try not to do that). /usr/ucb:/usr/bin:/usr/sbin Would display "ucb" pages with preference. The PATH: /opt/mumble/bin:/usr/bin Would be effective: /opt/mumble/bin/../man:/opt/mumble/bin/../share/man:/usr/share/man (with the bin/../share/man entry still being discussed) Right? ------- next topic ------ Is the explicit list of /usr/bin subsections a good idea? Everytime a new subsection was added, it would require a change to the man command. I also suspect that this limitation may be an incompatible change in behavior - currently an empty MANPATH value doesn't restrict the subsections. - jek3 From jek3@sun.com Thu Dec 13 13:09:03 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDL93kd018201 for ; Thu, 13 Dec 2007 13:09:03 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBDL93Ut000312; Thu, 13 Dec 2007 13:09:03 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT00000DAR2K600@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Dec 2007 13:09:02 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT00005EAQXFQ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Dec 2007 13:08:57 -0800 (PST) Received: from [129.150.12.37] (vpn-129-150-12-37.SFBay.Sun.COM [129.150.12.37]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lBDL8uJT237371; Thu, 13 Dec 2007 13:08:57 -0800 (PST) Date: Thu, 13 Dec 2007 11:08:43 -1000 From: Joseph Kowalski Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <65f8f3ad0712131216r7941d7car8ac74185a125a0e7@mail.gmail.com> To: Mike Gerdts Cc: Lawrence Lee , John Plocher , PSARC-ext@sun.com Message-id: <47619F5B.8050604@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> <47618CFC.5070707@sun.com> <65f8f3ad0712131216r7941d7car8ac74185a125a0e7@mail.gmail.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 765 Re: transforms /usr/bin /usr/share/man,1,1m,1s,1t,1c,1f I think I get it (right after I sent my mail). In the absence of a defined MANPATH, man will search search all of /usr/man after all the directories indicated by "bin" directories. I see the motivation now (if I finally understand). Eventually, all of the subsections will be searched, this just alters the order of the search. Of course, that still begs the question as to if this is a compatible change. I think it technically is, but its one of those things that are obvious enhancements that we can cut things a little slack on this (IMHO). (The minor binding is important.) (Nit, I just noticed, and I have this right, (1m) should *not* be in the list for /usr/bin, right?) - jek3 From mgerdts@gmail.com Thu Dec 13 13:32:02 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDLW1xn019282 for ; Thu, 13 Dec 2007 13:32:02 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBDLW1YV006400 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Dec 2007 13:32:01 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT000E09BTDXW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 14:32:01 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT0001H7BTDC8C0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 14:32:01 -0700 (MST) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBDLD34T022637 for ; Thu, 13 Dec 2007 21:32:00 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay43i.sun.com with ESMTP id BT-MMP-795368 for PSARC-ext@sun.com; Thu, 13 Dec 2007 21:32:00 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms48es.sun.com with ESMTP id BT-MMP-2771188 for PSARC-ext@sun.com; Thu, 13 Dec 2007 21:32:00 +0000 (Z) Received: from wa-out-1112.google.com ([209.85.146.183] [209.85.146.183]) by relay4i.sun.com with ESMTP id BT-MMP-12306631 for PSARC-ext@sun.com; Thu, 13 Dec 2007 21:32:00 +0000 (Z) Received: by wa-out-1112.google.com with SMTP id l24so1430304waf.22 for ; Thu, 13 Dec 2007 13:31:59 -0800 (PST) Received: by 10.114.159.1 with SMTP id h1mr2772717wae.122.1197581519323; Thu, 13 Dec 2007 13:31:59 -0800 (PST) Received: by 10.115.19.14 with HTTP; Thu, 13 Dec 2007 13:31:59 -0800 (PST) Date: Thu, 13 Dec 2007 15:31:59 -0600 From: Mike Gerdts Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <47619AA5.5020309@sun.com> To: Joseph Kowalski Cc: John Plocher , PSARC-ext@sun.com Message-id: <65f8f3ad0712131331i7fc07665l91e9dba2a26059c8@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=lTF3Vno0xgNz54IvqMBxDlOiZYIlrNJPTfWPcM7Icxc=; b=jUuWTYkMpqkiV6aENJpkNc+CYJpHJvgxb2xU8fjbT0PbwTjstO5xbx4tHmuALfCnsr+HejgbUGQ3dyjmBVCYcBHPht7lEqV6oP+Gpp1RLKbltoEheRDAJBJURyfzktU6b5MZ2N5yZJaIS6LSZ6y/fWFV1xlahBH20R5K1jgsf0Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TZ6f1TJ5zUGCOyEp4TgXTcGX7LFeJTEYuqYYpdeiCyct8aOFnLqKuutyOViplJRIEqBeZ+s6afJziN3r3M/bErG+A9nsu4nzsABOnEmtpO3EcYETitIUseWqZcKkJZ1i09nNeYTI4+WuVpEk72EEPwwMmeepNreXTNY74LvSADE= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47618B59.6030704@sun.com> <65f8f3ad0712131210l3dda6260lcb712bc29e7b9429@mail.gmail.com> <47619AA5.5020309@sun.com> Status: RO Content-Length: 4867 On Dec 13, 2007 2:48 PM, Joseph Kowalski wrote: > Mike Gerdts wrote: > > On Dec 13, 2007 1:43 PM, Joseph Kowalski wrote: > > > >> We could just add a link "man -> ./share/man" as needed. > >> > > > > The /usr/man -> share/man link does exist today and is documented in > > filesystem(5). I'm not sure that I am ready to take on filesystem(5) > > today. > > > Opps. I was trying to *not* search "../share/man" based on the PATH > setting. > > > >> That's what I'd like. > >> > >> However, I'd accept wording on the man(1) (and related) pages that > >> highlighted > >> that the second set above is just a legacy/convenience thing. We don't > >> want to > >> validate the practice of sprinkling "share" directories around. > >> > I can't find a clear response here... :-) The use of share/man rather than man was on the recommendation of Darren Moffat. http://mail.opensolaris.org/pipermail/opensolaris-code/2007-November/006394.html Subsequent reading of filesystem(5) suggests that third parties should be creating /opt/something/man, not /opt/something/share/man. As such, it seems to make sense use man as the default and share/man as the fallback. share/man as a fallback is an important part because there is misunderstanding, even among those at Sun, as to where things really belong. > >> Also, along this line, shouldn't the algorithm reverse the priority of > >> steps #2 and #3? > >> > > > > This working in filesystem(5) suggests it may be the right thing to > > do. Unfortunately, those that created /usr/gnu/{bin,share/man} didn't > > take it into consideration: > > > > /usr/share/man > > > > Platform-independent sharable manual pages. An approved > > installation location for bundled Solaris software. The > > analogous location for add-on system software or for > > applications is /opt/packagename/man. > > > > Given that there is now more focus on adding to /usr/bin rather than > > adding more directories like /usr/sfw and /usr/gnu, there should be > > relatively few *Solaris directories that subscribe to share/man. > > Since third parties should be installing software to /opt/packagename > > with /opt/packagename/man as the man directory, reversing the search > > order to prefer man over share/man seems appropriate. > > > Great! (Now lets resolve if ../share/man should even be in the algorithm.) Per above, share/man belongs for usability reasons. > >> Finally, for this proposal to be complete, I think you need to enumerate > >> the cases > >> handled by #1 (the explicit translation rules). I doubt they are > >> controversial, but > >> they should be enumerated for completeness. > >> > > > > The mapping is... > > > > /sbin /usr/share/man,1m > > /usr/sbin /usr/share/man,1m > > /usr/ucb /usr/share/man,1b > > /usr/bin /usr/share/man,1,1m,1s,1t,1c,1f > > /usr/xpg4/bin /usr/share/man,1 > > /usr/xpg6/bin /usr/share/man,1 > > > I'm not sure I'm getting it. These are absolute paths. These > transforms don't apply to any random PATH/../man searches, right? > > To make this clear, given the PATH: > > /usr/bin:/usr/sbin:/usr/ucb > > There would be no effective change due to this proposal. Correct. > > /usr/sbin:/usr/bin:/usr/ucb > > Would only change the priority of a page under (1M) over (1) (but > hopefully we try not to do that). Hopefully such collisions do not exist. If they do, the man page you get will refer to the page for the command in /usr/sbin, assuming a 1m page exists. > > /usr/ucb:/usr/bin:/usr/sbin > > Would display "ucb" pages with preference. Correct. > > The PATH: > > /opt/mumble/bin:/usr/bin > > Would be effective: > > /opt/mumble/bin/../man:/opt/mumble/bin/../share/man:/usr/share/man > > (with the bin/../share/man entry still being discussed) No - if stat(/opt/mumble/man, ...) returns 0, /opt/mumble/share/man is not added. If /opt/mumble/man exists, the effective MANPATH would be: /opt/mumble/man:/usr/share/man If /opt/mumble/man does not exist but /opt/mumble/share/man does: /opt/mumble/share/man:/usr/share/man > > Right? Amost. :) > > ------- next topic ------ > > Is the explicit list of /usr/bin subsections a good idea? Everytime a > new subsection was added, it would require a change to the man command. > I also suspect that this limitation may be an incompatible change in > behavior - currently an empty MANPATH value doesn't restrict the > subsections. Suppose: PATH=/usr/bin:/usr/gnu/bin:/usr/ucb By listing the sections for /usr/bin: $ man -l ls ls (1) -M /usr/share/man ls (1) -M /usr/gnu/share/man ls (1b) -M /usr/share/man Similar for "man -a". Otherwise ls(1b) would show up in the output early. Thanks for your feedback! -- Mike Gerdts http://mgerdts.blogspot.com/ From mgerdts@gmail.com Thu Dec 13 13:37:44 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDLbh1e019416 for ; Thu, 13 Dec 2007 13:37:43 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBDLbfeV020536 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Dec 2007 21:37:42 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT000C03C2TZY00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 13:37:41 -0800 (PST) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT0008NYC2TDV70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 13:37:41 -0800 (PST) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBDLJNPs015046 for ; Thu, 13 Dec 2007 21:37:40 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay43i.sun.com with ESMTP id BT-MMP-795912 for PSARC-ext@sun.com; Thu, 13 Dec 2007 21:37:40 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms49es.sun.com with ESMTP id BT-MMP-2571010 for PSARC-ext@sun.com; Thu, 13 Dec 2007 21:37:40 +0000 (Z) Received: from wa-out-1112.google.com ([209.85.146.181] [209.85.146.181]) by relay4i.sun.com with ESMTP id BT-MMP-281308 for PSARC-ext@sun.com; Thu, 13 Dec 2007 21:37:40 +0000 (Z) Received: by wa-out-1112.google.com with SMTP id l24so1433332waf.22 for ; Thu, 13 Dec 2007 13:37:39 -0800 (PST) Received: by 10.114.38.2 with SMTP id l2mr2811907wal.89.1197581859526; Thu, 13 Dec 2007 13:37:39 -0800 (PST) Received: by 10.115.19.14 with HTTP; Thu, 13 Dec 2007 13:37:39 -0800 (PST) Date: Thu, 13 Dec 2007 15:37:39 -0600 From: Mike Gerdts Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <20071213204652.GM14367@Sun.COM> To: Mike Gerdts , Joseph Kowalski , Lawrence Lee , PSARC-ext@sun.com, John Plocher Message-id: <65f8f3ad0712131337u7a18cf4fnc4490738220b6e8a@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=XDdR68no7Jd/rJEOc4cj2sKgP+mzRBKBI5jLWpLfVLo=; b=Zcrt3pv8QHkZqOt7Qa61skrSFOitM574Mx14wNLsKPeP29oZWOYxUzT88a1m5XhYUzzqmYl076GJoCvvtCx2xLS/SgV5v+4fOGGBwwTxyjO7z/QPBzYIsg21ad9gkjpV8+HQmRD1Fwy/IZtSDnGOZN7dkFTfZr/u+4mHNByyFIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sfWD1zES76wYda0FRpBuA9auzJniXDAKLRoP3HYI4SAetZe22hYnyFe5Aw1aSaE5DBPBjBWImr0PCaJWiV81Ytlm9R0t33diuOPV4Ed3pzjnhVmFO5LKE5AC/3NuWSPKOCQMcNM1QtztNKT7FnHVp22ztFVQLOpmf3i1FPjn+GU= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> <47618CFC.5070707@sun.com> <65f8f3ad0712131216r7941d7car8ac74185a125a0e7@mail.gmail.com> <20071213204652.GM14367@Sun.COM> Status: RO Content-Length: 811 On Dec 13, 2007 2:46 PM, Nicolas Williams wrote: > On Thu, Dec 13, 2007 at 02:16:28PM -0600, Mike Gerdts wrote: > > However, I am not convinced that it is needed or worth the effort. > > I say we leave that for another day, if we ever do need it. > > In the meantime packagers not used to having $BASEDIR/bin/../man can get > by with symlinks. > Nit, but potentially important to some. The exact directory is not $BASEDIR/bin/../man. It is $BASEDIR/man. This is an important distinction for potentially broken directory hierarchies: /opt/foo/bin -> sparcv9/bin /opt/foo/sparcv9/bin/foo /opt/foo/man /opt/foo/man/man1/foo.1 If PATH had /opt/foo/bin, then /opt/foo/bin/../man would really be /opt/foo/sparcv9/man, which doesn't exist. -- Mike Gerdts http://mgerdts.blogspot.com/ From mgerdts@gmail.com Thu Dec 13 13:43:58 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDLhw7q019887 for ; Thu, 13 Dec 2007 13:43:58 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBDLhv0J001925 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Dec 2007 13:43:58 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT000D11CD8CM00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 13:43:56 -0800 (PST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT0008AECD5E090@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 13:43:54 -0800 (PST) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBDLcuU4000520 for ; Thu, 13 Dec 2007 21:43:53 +0000 (GMT) Received: from mms23es.sun.com ([150.143.232.54] [150.143.232.54]) by relay23i.sun.com with ESMTP id BT-MMP-830975 for PSARC-ext@sun.com; Thu, 13 Dec 2007 21:43:53 +0000 (Z) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24]) by mms23es.sun.com with ESMTP id BT-MMP-184027 for PSARC-ext@sun.com; Thu, 13 Dec 2007 21:43:53 +0000 (Z) Received: from wa-out-1112.google.com ([209.85.146.180] [209.85.146.180]) by relay21i.sun.com with ESMTP id BT-MMP-10054824 for PSARC-ext@sun.com; Thu, 13 Dec 2007 21:43:53 +0000 (Z) Received: by wa-out-1112.google.com with SMTP id l24so1436575waf.22 for ; Thu, 13 Dec 2007 13:43:52 -0800 (PST) Received: by 10.114.160.1 with SMTP id i1mr2833200wae.49.1197582232728; Thu, 13 Dec 2007 13:43:52 -0800 (PST) Received: by 10.115.19.14 with HTTP; Thu, 13 Dec 2007 13:43:52 -0800 (PST) Date: Thu, 13 Dec 2007 15:43:52 -0600 From: Mike Gerdts Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <47619F5B.8050604@sun.com> To: Joseph Kowalski Cc: Lawrence Lee , John Plocher , PSARC-ext@sun.com Message-id: <65f8f3ad0712131343s5394d539m26ccfa0730796a4@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=EjuYuYS9KPfn60SQJcRqVxDrlAMw3qCXL4aztV/5U8g=; b=kSPo/wZLJPio6qBNMEVAzHq7o9RKVHeaWiZ6HAHB4FblZAd7nG81xbNrYtha7k8FW87QKotVlfoNQwSGm5VVrzFI+x0320IAbz5qcHnN6sTDrLm9EuGs4jLEeUkdTXCT7/5k43LIyi2YPTEhA+N36HDNbhSd54E05LeRqOZltAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uduzx3NPt6fzAczVPfgC6yAP8qqvGRpQQoXFXhp06ip55QGey5UXW3zLj03qeMnTtxtGN3eHmsYH9NYgqZLi1vvb9U+T/n+C+n73+E9NyExJso42bibiqoQiVaub8y6TnidbXPq2ukEspnHtzDC5fes9jRFhzpk+us6rHsP6GK8= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> <47618CFC.5070707@sun.com> <65f8f3ad0712131216r7941d7car8ac74185a125a0e7@mail.gmail.com> <47619F5B.8050604@sun.com> Status: RO Content-Length: 1286 On Dec 13, 2007 3:08 PM, Joseph Kowalski wrote: > > Re: transforms > > /usr/bin /usr/share/man,1,1m,1s,1t,1c,1f > > > I think I get it (right after I sent my mail). > > In the absence of a defined MANPATH, man will search search all of > /usr/man after all the directories indicated by "bin" directories. I > see the motivation now (if I finally understand). Eventually, all of > the subsections will be searched, this just alters the order of the search. Correct. > Of course, that still begs the question as to if this is a compatible > change. I think it technically is, but its one of > those things that are obvious enhancements that we can cut things a > little slack on this (IMHO). > > (The minor binding is important.) I'll have to trust others on this point. > (Nit, I just noticed, and I have this right, (1m) should *not* be in the > list for /usr/bin, right?) Sigh. You would think so (I did). Do this with your legacy man(1). cd /usr/bin man -l * 2>/dev/null | grep 1m Based upon what I see in there, I wonder why /usr/sbin even exists. It seems as though all it does is hide ping(1M) from those that aren't worthy. Surely the typical person doesn't run savecore or wracct. -- Mike Gerdts http://mgerdts.blogspot.com/ From Nicolas.Williams@sun.com Thu Dec 13 14:09:09 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDM99PI021106 for ; Thu, 13 Dec 2007 14:09:09 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBDM984B008945; Thu, 13 Dec 2007 14:09:08 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT000E09DJ8CE00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Dec 2007 14:09:08 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT0008KLDJ7E6A0@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Dec 2007 14:09:07 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lBDM96vD014861; Thu, 13 Dec 2007 16:09:06 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lBDM95GJ014860; Thu, 13 Dec 2007 16:09:05 -0600 (CST) Date: Thu, 13 Dec 2007 16:09:05 -0600 From: Nicolas Williams Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <65f8f3ad0712131343s5394d539m26ccfa0730796a4@mail.gmail.com> To: Mike Gerdts Cc: Joseph Kowalski , Lawrence Lee , PSARC-ext@sun.com, John Plocher Mail-followup-to: Mike Gerdts , Joseph Kowalski , Lawrence Lee , PSARC-ext@sun.com, John Plocher Message-id: <20071213220905.GP14367@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> <47618CFC.5070707@sun.com> <65f8f3ad0712131216r7941d7car8ac74185a125a0e7@mail.gmail.com> <47619F5B.8050604@sun.com> <65f8f3ad0712131343s5394d539m26ccfa0730796a4@mail.gmail.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1002 On Thu, Dec 13, 2007 at 03:43:52PM -0600, Mike Gerdts wrote: > On Dec 13, 2007 3:08 PM, Joseph Kowalski wrote: > > (Nit, I just noticed, and I have this right, (1m) should *not* be in the > > list for /usr/bin, right?) > > Sigh. You would think so (I did). Do this with your legacy man(1). > > cd /usr/bin > man -l * 2>/dev/null | grep 1m > > Based upon what I see in there, I wonder why /usr/sbin even exists. > It seems as though all it does is hide ping(1M) from those that aren't > worthy. Surely the typical person doesn't run savecore or wracct. I think the situation with /usr/sbin is a bit confused and confusing. Many things in /usr/sbin probably belong in /usr/bin. I think one criterion for deciding whether something belongs in /usr/bin or /usr/sbin should be how much damage someone with the right RBAC profiles might do when executing some admin command in a regular shell, or in a profile shell. Certainly all the *stat(1M) commands belong in /usr/bin. Nico -- From jek3@sun.com Thu Dec 13 14:24:27 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDMOQQm021540 for ; Thu, 13 Dec 2007 14:24:26 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBDMOI5d008962 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Dec 2007 22:24:25 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT000I03E8OO000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 15:24:24 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT000I62E8NGO00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Dec 2007 15:24:23 -0700 (MST) Received: from [129.150.12.37] (vpn-129-150-12-37.SFBay.Sun.COM [129.150.12.37]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lBDMOLam252678; Thu, 13 Dec 2007 14:24:22 -0800 (PST) Date: Thu, 13 Dec 2007 12:24:06 -1000 From: Joseph Kowalski Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <65f8f3ad0712131331i7fc07665l91e9dba2a26059c8@mail.gmail.com> To: Mike Gerdts Cc: John Plocher , PSARC-ext@sun.com Message-id: <4761B106.9090405@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47618B59.6030704@sun.com> <65f8f3ad0712131210l3dda6260lcb712bc29e7b9429@mail.gmail.com> <47619AA5.5020309@sun.com> <65f8f3ad0712131331i7fc07665l91e9dba2a26059c8@mail.gmail.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 231 Mike Gerdts wrote: > > Per above, share/man belongs for usability reasons. > OK. Not really architecture, but when you update the man manpage, please make it clear that this is legacy or 3rd party support. - thanks, - jek3 From jek3@sun.com Thu Dec 13 14:54:54 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDMsrJd023012 for ; Thu, 13 Dec 2007 14:54:53 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBDMshNC020132; Fri, 14 Dec 2007 06:54:50 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT000K09FNBXG00@brm-avmta-1.central.sun.com>; Thu, 13 Dec 2007 15:54:47 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT000IOSFNAGS20@brm-avmta-1.central.sun.com>; Thu, 13 Dec 2007 15:54:46 -0700 (MST) Received: from [129.150.12.37] (vpn-129-150-12-37.SFBay.Sun.COM [129.150.12.37]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lBDMsjt8258437; Thu, 13 Dec 2007 14:54:45 -0800 (PST) Date: Thu, 13 Dec 2007 12:54:29 -1000 From: Joseph Kowalski Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <65f8f3ad0712131343s5394d539m26ccfa0730796a4@mail.gmail.com> To: Mike Gerdts Cc: Lawrence Lee , John Plocher , PSARC-ext@sun.com Message-id: <4761B825.5080607@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> <47618CFC.5070707@sun.com> <65f8f3ad0712131216r7941d7car8ac74185a125a0e7@mail.gmail.com> <47619F5B.8050604@sun.com> <65f8f3ad0712131343s5394d539m26ccfa0730796a4@mail.gmail.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1067 Mike Gerdts wrote: > On Dec 13, 2007 3:08 PM, Joseph Kowalski wrote: > ... >> (Nit, I just noticed, and I have this right, (1m) should *not* be in the >> list for /usr/bin, right?) >> > > Sigh. You would think so (I did). Do this with your legacy man(1). > > cd /usr/bin > man -l * 2>/dev/null | grep 1m > > Based upon what I see in there, I wonder why /usr/sbin even exists. > It seems as though all it does is hide ping(1M) from those that aren't > worthy. Surely the typical person doesn't run savecore or wracct. > Well, thanks for making my day. :-) I was going to make a plea that you shouldn't embed this inconsistency between object location and man section. Heck, at one level, this makes this a bug in the proposed man command, not just our file system layout. However, there are so many of these, (and we will probably never "fix" them,) what you propose is probably the right thing to do. You should add a sentence about this as a NOTE in the updated man manpage. Did I mention this made my day? - cheers, - jek3 From bart.smaalders@sun.com Thu Dec 13 14:57:22 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBDMvM0C023072 for ; Thu, 13 Dec 2007 14:57:22 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBDMvM6G021575; Thu, 13 Dec 2007 14:57:22 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT000D01FRKAX00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Dec 2007 14:57:21 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT0000GIFREFSA0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Dec 2007 14:57:14 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lBDMvDmU258645; Thu, 13 Dec 2007 14:57:13 -0800 (PST) Date: Thu, 13 Dec 2007 14:53:01 -0800 From: Bart Smaalders Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <20071213220905.GP14367@Sun.COM> To: Mike Gerdts , Joseph Kowalski , Lawrence Lee , PSARC-ext@sun.com, John Plocher Message-id: <4761B7CD.1000408@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <47614F07.3050706@sun.com> <47618CFC.5070707@sun.com> <65f8f3ad0712131216r7941d7car8ac74185a125a0e7@mail.gmail.com> <47619F5B.8050604@sun.com> <65f8f3ad0712131343s5394d539m26ccfa0730796a4@mail.gmail.com> <20071213220905.GP14367@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 1482 Nicolas Williams wrote: > On Thu, Dec 13, 2007 at 03:43:52PM -0600, Mike Gerdts wrote: >> On Dec 13, 2007 3:08 PM, Joseph Kowalski wrote: >>> (Nit, I just noticed, and I have this right, (1m) should *not* be in the >>> list for /usr/bin, right?) >> Sigh. You would think so (I did). Do this with your legacy man(1). >> >> cd /usr/bin >> man -l * 2>/dev/null | grep 1m >> >> Based upon what I see in there, I wonder why /usr/sbin even exists. >> It seems as though all it does is hide ping(1M) from those that aren't >> worthy. Surely the typical person doesn't run savecore or wracct. > > I think the situation with /usr/sbin is a bit confused and confusing. > Many things in /usr/sbin probably belong in /usr/bin. I think one > criterion for deciding whether something belongs in /usr/bin or > /usr/sbin should be how much damage someone with the right RBAC profiles > might do when executing some admin command in a regular shell, or in a > profile shell. Certainly all the *stat(1M) commands belong in /usr/bin. > > Nico Have fought one bruising ARC case about what belongs in /usr/sbin already, I'm loathe to jump in again... however, it's pretty obvious that commands that are useful w/o privilege don't belong in /usr/sbin, since adding /usr/sbin to your path to pickup those useful commands means that any perceived safety advantage is lost. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From mgerdts@gmail.com Sat Dec 15 22:26:18 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBG6QHQe022767 for ; Sat, 15 Dec 2007 22:26:17 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBG6Q9E1019146 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 16 Dec 2007 14:26:16 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT400801PVM8300@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 15 Dec 2007 23:26:10 -0700 (MST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT400DMQPVM7GD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 15 Dec 2007 23:26:10 -0700 (MST) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBG6NgXP009189 for ; Sun, 16 Dec 2007 06:26:10 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay41i.sun.com with ESMTP id BT-MMP-73963 for PSARC-ext@sun.com; Sun, 16 Dec 2007 06:26:09 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms48es.sun.com with ESMTP id BT-MMP-2479743 for PSARC-ext@sun.com; Sun, 16 Dec 2007 06:26:09 +0000 (Z) Received: from wa-out-1112.google.com ([209.85.146.183] [209.85.146.183]) by relay4i.sun.com with ESMTP id BT-MMP-2674865 for PSARC-ext@sun.com; Sun, 16 Dec 2007 06:26:09 +0000 (Z) Received: by wa-out-1112.google.com with SMTP id l24so2707142waf.22 for ; Sat, 15 Dec 2007 22:26:08 -0800 (PST) Received: by 10.114.59.1 with SMTP id h1mr955302waa.39.1197786368470; Sat, 15 Dec 2007 22:26:08 -0800 (PST) Received: by 10.114.109.20 with HTTP; Sat, 15 Dec 2007 22:26:08 -0800 (PST) Date: Sun, 16 Dec 2007 00:26:08 -0600 From: Mike Gerdts Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> To: John Plocher Cc: PSARC-ext@sun.com Message-id: <65f8f3ad0712152226l5b542a79h47b894680072d69a@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=RFqCyTcEc0yE0FbN6Uio7QZ6DBQmruHU+rQRjO6xbI0=; b=vtN0tUDC/8BBHQTTQz1jOoibKyT2ESB59cv7EOKk6eWJI1U0shuwDvjFaWjUt7Lquz4nZv+KwOHs971yIC3jbrpjcktFNpCq72dhx2aq84xudwKTZT0EfKKNJ0+jGbvh+SKlewrHYvrn4GVR8QNpQpgaVV0LrwvF9p2SrVFmMrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZTGi68Cvkgdwmdw/rVIxTAPM/MftKMlbC8gH6tdFGl/uFgJ3g/Rl1wQ1uhLxOCNjQ3ir6nxZYh0A5In/dM1Y1QBsdivPdTjIU8fjc2z/A6LwUwaWtoSPQKjXbZdnvjq49NoAiOv3BOuKcxWes68ZSz0fJtlXjr81oRTOUWNISXE= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> Status: RO Content-Length: 9957 On Dec 13, 2007 12:55 AM, John Plocher wrote: > I am ARC-sponsoring this fasttrack from Mike Gerdts, an > OpenSolaris community member. Mike is finding someone else > to be his code/putback sponsor... Based upon feedback received (thanks!), the spec has been updated with the following changes: - Made it clear that legacy behavior is to be expected if MANPATH is set. - Add more detailed explanation of PATH to MANPATH transformation rules - Reversed relative precedence of share/man vs. man to align with filesystem(5). - Added NOTE in man(1) that path transformations involving /share/man exist for legacy support reasons and refer to filesystem(5) - Add SEE ALSO in man(1) for filesystem(5). - Clarify "Search Path" section of man(1) with regards to "man -M ..." - Add Sections 4.6.2 and 4.6.3 to clarify changes or lack thereof for catman(1M), whatis(1), and apropos(1). Updated spec follows: 2. Project Summary 2.1. Project Description: When projects such as Indiana or individuals customize PATH, MANPATH is often left unset. This leads to confusion because man(1) will display the manual page for the wrong variant of a command. For example, if /usr/gnu/bin is at the front of the path, the default behavior of man(1) would most appropriately be to display a manual page from /usr/gnu/share/man rather than /usr/share/man. Similar, but slightly more complex, considerations are made for /usr/ucb and for invocations of man(1) that specify the path to the executable for which a man page is sought. 2.2. Risks and Assumptions: Traditional behavior and expectation is that /usr/share/man is the only directory searched in the case that the MANPATH environment variable is undefined. This behavior is documented in the man page for man. To allow behavior that closely resembles the legacy behavior of man(1), setting MANPATH and using name arguments that do not contain the "/" character will not invoke any PATH to MANPATH translations. 4. Technical Description: 4.1. Details: The source file man.c will be enhanced to refer to PATH only in the absence of MANPATH. Each element of PATH will be translated based into the appropriate MANPATH element based upon the following priorities: - Explicit transformation rule. For example, /usr/ucb in PATH translates to /usr/share/man,1b. See below for details. - The parent directory of the PATH directory with /man appended. For example, /opt/VRTSvcs/bin becomes /opt/VRTSvcs/man, assuming /opt/VRTSvcs/man exists. - The parent directory of the PATH directory with /share/man appended. For example, /usr/gnu/bin becomes /usr/gnu/share/man because /usr/gnu/man does not exist. In addition and higher precedence to the above, if man is invoked referring to particular instance of a command (e.g. "man ./ls" or "man /usr/ucb/ps") the path transformation rules are applied using the directory component of the argument. In all cases where MANPATH is not defined and the path to a command is not specified /usr/share/man will be appended to MANPATH if it is not otherwise included based upon PATH transform rules. This ensures that sections other than 1* are accessible. The PATH to MANPATH transformations are as follows: PATH element MANPATH element ---------------- ------------------------------- /sbin /usr/share/man,1m /usr/sbin /usr/share/man,1m /usr/ucb /usr/share/man,1b /usr/bin /usr/share/man,1,1m,1s,1t,1c,1f /usr/xpg4/bin /usr/share/man,1 /usr/xpg6/bin /usr/share/man,1 Sections within each directory are explicitely set to ensure proper ordering of results for invocations such as "man -l", "man -a", whatis(1), etc. The transformation rules are stored in a data structure within man.c. The use of such a static mapping instead of a configuration file is chosen based upon the following: - The rules to use /man or /share/man directories will accomodate the vast majority of add-on software. - The alternative would be to create a configuration file to store the mappings. History has shown that providers of add-on software do not do a good job of modifying configuration files properly during installation and removal of software. In contrast, add-on software providers can easily create strategically placed symbolic links to trigger the automatic /man or /share/man translation. - Providing a command to update the configuration file would be significant work for a presumably very small number of edge cases. - If demand is shown, a configuration file can be added with very little rework in the future. A prototype of this behavior has been implemented and is available for review at http://cr.opensolaris.org/~mgerdts/manpath-from-path/. 4.3. In Scope: Described above. 4.4. Out of Scope: GNU utilities often times provide only stub man pages and more complete documentation using an alternative format known as "info". While translators from info to man do exist, this project does not seek to bridge this gap. 4.5. Interfaces The interface stability of man(1) is documented as "Standard" ("Comitted", in updated terminology). This project alters the documented "Search Path" behavior when MANPATH is not set. This project also extends the documented interface to man(1) such that "name" arguments that specify a fully qualified or relative path (with at least one '/' character) alter the documented "Search Path" behavior. Corresponding interface changes apply to whatis(1), catman(1M), and apropos(1) which are all hard links to man(1). 4.6. Doc Impact 4.6.1. man(1) manual page The man(1) manual page will be enhanced as follows. OPERANDS The following operand is supported: name The name of a standard utility or a keyword. If the name contains a '/' character, the search path (See "Search Path") is altered to search only the man directory corresponding to the name argument. For example, if name is "/usr/ucb/ps" man will behave as if the MANPATH environment variable is set to /usr/share/man,1b. . . . Search Path Before searching for a given name, man constructs a list of candidate directories and sections. man searches for name in the directories specified by the MANPATH environment vari- able. If this variable is not set and the -M option is not used, a substitute MANPATH is constructed based upon the PATH environment variable. In all cases, except as described above when the name operand has a "/" character, /usr/share/man is searched. For each name operand that contains a "/" character, neither MANPATH nor PATH are used to construct the search path. . . . ENVIRONMENT VARIABLES . . . MANPATH A colon-separated list of directories; each directory can be followed by a comma-separated list of sections. If set, its value overrides the default directory search path, and man.cf as the default section search path. The -M and -s flags, in turn, override these values. The default directory search path is constructed based upon the contents of the PATH environment variable with /usr/share/man appended, as necessary. PATH The search path for commands. If MANPATH is not set, MANPATH is derived from PATH. SEE ALSO apropos(1), cat(1), col(1), dpost(1), eqn(1), more(1), nroff(1), refer(1), tbl(1), troff(1), vgrind(1), whatis(1), catman(1M), attributes(5), environ(5), eqnchar(5), filesystem(5), man(5), sgml(5), standards(5) NOTES When transforming PATH elements to MANPATH elements, man(1) first attempts to transform /bin or /sbin to /man, as filesystem(5) indicates that add-on software should use /opt/packagename/man for manual pages. In the event that /man does not exist but /share/man does exist, /share/man will be searched. Searching /share/man is intended for legacy compatibility only. 4.6.2. catman(1M) manaul page changes The catman(1M) manual page will change as follows: ENVIRONMENT VARIABLES . . . MANPATH A colon-separated list of directories; each directory can be followed by a comma-separated list of sections. If set, its value overrides the default directory search path, and man.cf as the default section search path. The -M and -s flags, in turn, override these values. The default directory search path is constructed based upon the contents of the PATH environment variable with /usr/share/man appended, as necessary. PATH The search path for commands. If MANPATH is not set, MANPATH is derived from PATH. 4.6.3. Related manual pages not changing While the behavior of whatis(1) changes in the event that MANPATH is not set or a relative or absolute command path provided, the whatis(1) man page is sufficiently vague as to not require any changes to remain accurate. whatis(1) indicates that it is equivalent to "the -f option of the man(1) command" and as such refers users to more complete documentation. Similarly, the behavior of apropos(1) changes in the event that MANPATH is not set. However, the man page for apropos(1) is sufficiently vague to as to not require any changes to remain accurate. apropos(1) indicates "apropos is actually just the -k option to the man(1) command" and as such refers users to more complete documentation. -- Mike Gerdts http://mgerdts.blogspot.com/ From edward.pilatowicz@sun.com Mon Dec 17 16:22:24 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBI0MNQE002720 for ; Mon, 17 Dec 2007 16:22:24 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBI0M9Be001056; Tue, 18 Dec 2007 00:22:21 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT700B17YD8WO00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 17 Dec 2007 16:22:20 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT700FXMYD75K50@nwk-avmta-1.sfbay.Sun.COM>; Mon, 17 Dec 2007 16:22:19 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lBI0MIhC760548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Dec 2007 16:22:19 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id lBI0MIEx760541; Mon, 17 Dec 2007 16:22:18 -0800 (PST) Date: Mon, 17 Dec 2007 16:22:18 -0800 From: Edward Pilatowicz Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> To: John Plocher Cc: PSARC-ext@sun.com, mgerdts@gmail.com Message-id: <20071218002218.GC741781@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 11823 i really like the suggested manpatch search mechanism. it should make the management of manpath much easier. that said, currently i have some MANPATH entries (ie, entries in my MANPATH environment variable) which aren't associated with any PATH entries. so to switch to this new mechanism i'd have to drop these entries. so what i was wondering is would it be possible to have some new man(1) cli option that would display the current dynamic man search path in the format of a MANPATH variable? this would allow me to do something like the following in my profile: PATH=" unset MANPATH MANPATH=`man --found-dynamic-manpath-search-directories` MANPATH=$MANPATH: export MANPATH thoughts? ed On Wed, Dec 12, 2007 at 10:55:34PM -0800, John Plocher wrote: > I am ARC-sponsoring this fasttrack from Mike Gerdts, an > OpenSolaris community member. Mike is finding someone else > to be his code/putback sponsor... > > Binding is to a minor release of the ON consolidation. > > As mentioned in 4.5 below: > > The interface stability of man(1) is documented as "Standard" > ("Comitted", in updated terminology). This project alters the > documented "Search Path" behavior when MANPATH is not set. > > This project also extends the documented interface to man(1) > such that "name" arguments that specify a fully qualified or > relative path (with at least one '/' character) alter the > documented "Search Path" behavior. > > Corresponding interface changes apply to whatis(1), catman(1), > and apropos(1) which are all hard links to man(1). > > -John > > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2007 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > manwhich: Deriving MANPATH from PATH > 1.2. Name of Document Author/Supplier: > Author: Mike Gerdts > 1.3 Date of This Document: > 12 December, 2007 > 4. Technical Description > 1. Introduction > 1.1. Project/Component Working Name: > manwhich: Deriving MANPATH from PATH > > 1.2. Name of Document Author/Supplier: > Mike Gerdts > OpenSolaris Contributor ID OS0018 > > 1.3. Date of This Document: > 12/12/2007 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > 1.4.1. The Community you expect to review your project: > ON > > 1.4.2. The ARC(s) you expect to review your project: > OpenSolaris ARC > > 1.5. Email Aliases: > 1.5.2. Responsible Engineer: > Mike Gerdts > > 1.5.4. Interest List: > opensolaris-code@opensolaris.org > > 2. Project Summary > 2.1. Project Description: > When projects such as Indiana or individuals customize PATH, > MANPATH is often left unset. This leads to confusion because man(1) > will display the manual page for the wrong variant of a command. > For example, if /usr/gnu/bin is at the front of the path, the > default behavior of man(1) would most appropriately be to display a > manual page from /usr/gnu/share/man rather than /usr/share/man. > Similar, but slightly more complex, considerations are made for > /usr/ucb and for invocations of man(1) that specify the path to the > executable for which a man page is sought. > > 2.2. Risks and Assumptions: > Traditional behavior and expectation is that /usr/share/man is the > only directory searched in the case that the MANPATH environment > variable is undefined. This behavior is documented in the man page > for man. > > 3. Business Summary > 3.1. Problem Area: > This project increases the usability of online help accessed through > the command line. History has shown that end-users have little > success in keeping MANPATH in sync with PATH. > > 3.2. Market/Requester: > Users and developers who wish to learn how to use the commands and > utilities found in OpenSolaris. > > 3.3. Business Justification: > As more FOSS functionality is added to various parts of OpenSolaris > and its distros, keeping individual user's MANPATHs up to date gets > harder and harder. This project effectively removes the > requirement for most users to even bother setting it in the first > place. > > 3.4. Competitive Analysis: > Various Linux and *BSD distros provide similar or related > mechanisms. > > 3.5. Opportunity Window/Exposure: > // Time-to-market window, if any, and precision. > > 3.6. How will you know when you are done?: > When the user has "unset MANPATH", "man foo" will find the man page > associated with foo as determined by the user's PATH setting. > > 4. Technical Description: > 4.1. Details: > The source file man.c will be enhanced to refer to PATH only in the > absence of MANPATH. Each element of PATH will be translated based > into the appropriate MANPATH element based upon the following > priorities: > > - Explicit transformation rule. For example, /usr/ucb in PATH > translates to /usr/share/man,1b. > - The parent directory of the PATH directory with /share/man > appended. For example, /usr/gnu/bin becomes > /usr/gnu/share/man. > - The parent directory of the PATH directory with /man > appended. For example, /opt/VRTSvcs/bin becomes > /opt/VRTSvcs/man because /opt/VRTSvcs/share/man does not exist > but /opt/VRTSvcs/man does. > > In addition and higher precedence to the above, if man is invoked > referring to particular instance of a command (e.g. "man ./ls" or > "man /usr/ucb/ps") the path transformation rules are applied using > the directory component of the argument. > > In all cases where MANPATH is not defined and the path to a command > is not specified /usr/share/man will be appended to MANPATH if it > is not otherwise included based upon PATH transform rules. This > ensures that sections other than 1* are accessible. > > A prototype of this behavior has been implemented and is available > for review at http://cr.opensolaris.org/~mgerdts/manpath-from-path/. > > 4.2. Bug/RFE Number(s): > 6634079 man should take hints from PATH when MANPATH not set > 6516767 RFE:/etc/profile should set ${MANPATH} to > ${PATH}/${LANG}-related value > > 4.3. In Scope: > Described above. > > 4.4. Out of Scope: > GNU utilities often times provide only stub man pages and more > complete documentation using an alternative format known as "info". > While translators from info to man do exist, this project does not > seek to bridge this gap. > > 4.5. Interfaces: > The interface stability of man(1) is documented as "Standard" > ("Comitted", in updated terminology). This project alters the > documented "Search Path" behavior when MANPATH is not set. > > This project also extends the documented interface to man(1) such > that "name" arguments that specify a fully qualified or relative > path (with at least one '/' character) alter the documented "Search > Path" behavior. > > Corresponding interface changes apply to whatis(1), catman(1), and > apropos(1) which are all hard links to man(1). > > 4.6. Doc Impact: > > man(1) man page will be enhanced as follows: > > OPERANDS > The following operand is supported: > > name The name of a standard utility or a keyword. If the > name contains a '/' character, the search path (See > "Search Path") is altered to search only the man > directory corresponding to the name argument. For > example, if name is "/usr/ucb/ps" man will behave as > if the MANPATH environment variable is set to > /usr/share/man,1b. > . . . > > Search Path > Before searching for a given name, man constructs a list of > candidate directories and sections. man searches for name in > the directories specified by the MANPATH environment vari- > able. If this variable is not set, a substitute MANPATH > is constructed based upon the PATH environment variable. In > all cases, except as described above when the name operand > has a "/" character, /usr/share/man is searched. > > For each name operand that contains a "/" character, neither > MANPATH nor PATH are used to construct the search path. > > . . . > > ENVIRONMENT VARIABLES > . . . > > MANPATH A colon-separated list of directories; each > directory can be followed by a comma-separated > list of sections. If set, its value overrides > the default directory search path, and man.cf as > the default section search path. The -M and -s > flags, in turn, override these values. The > default directory search path is constructed > based upon the contents of the PATH environment > variable with /usr/share/man appended, as > necessary. > > PATH The search path for commands. If MANPATH is not > set, MANPATH is derived from PATH. > > While the behavior of whatis changes in the event that a relative > or absoluate command path provided, the whatis(1) man page is > sufficiently vague as to not require any changes to remain > accurate. whatis(1) indicates that it is equivalent to "the -f > option of the man(1) command" and as such refers users to more > complete documentation. > > 4.7. Admin/Config Impact: > On systems without MANPATH explicitly set by the administrator, but > with customized PATH, man(1) may provide results that are more > likely to be correct for the users' environments. The system > administration overhead for "more correct" behavior of man is thus > reduced. > > 4.8. HA Impact: > None. > > 4.9. I18N/L10N Impact: > Aside from man pages mentioned above, none. No error or usage > strings are added modified or added. > > 4.10. Packaging & Delivery: > No impact. > > 4.11. Security Impact: > No impact. > > 4.12. Dependencies: > None. > > 5. Reference Documents: > 6634079 man should take hints from PATH when MANPATH not set > > This CR was opened as a means for tracking this specific change. > Absent from the scope of this CR is the behavior if the name > operand contains a / character. > > http://mail.opensolaris.org/pipermail/opensolaris-code/2007-November/006390.html > > Initial discussion of this functionality and initial code review > of prototype. > > 6. Resources and Schedule: > 6.1. Projected Availability: > December, 2007. > > 6.2. Cost of Effort: > One to two people-months of part-time work. > > 6.4. Product Approval Committee requested information: > 6.4.1. Consolidation or Component Name: > ON > > 6.4.7. Target RTI Date/Release: > Build 81, 82, or 83 (December 2007 - January 2008) > > 6.4.8. Target Code Design Review Date: > December 13, 2007 > > 6.5. ARC review type: > FastTrack > 6.6. ARC Exposure: open > 6.6.1. Rationale: Part of OpenSolaris > > 7. Prototype Availability: > 7.1. Prototype Availability: > prototype available December 12, 2007 at > http://cr.opensolaris.org/~mgerdts/manpath-from-path/. This > prototype offers nearly complete functionality. > > 7.2. Prototype Cost: > 2 part-time programmer-weeks. > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From alan.coopersmith@sun.com Mon Dec 17 16:50:33 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBI0oX5c003820 for ; Mon, 17 Dec 2007 16:50:33 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBI0oX9A011935 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 17 Dec 2007 16:50:33 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT70000NZO9FO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 17 Dec 2007 16:50:33 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT700MOKZO8OU00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 17 Dec 2007 16:50:32 -0800 (PST) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id lBI0oVhU008498; Mon, 17 Dec 2007 16:50:31 -0800 (PST) Date: Mon, 17 Dec 2007 16:50:31 -0800 From: Alan Coopersmith Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <20071218002218.GC741781@eng.sun.com> To: Edward Pilatowicz Cc: John Plocher , PSARC-ext@sun.com, mgerdts@gmail.com Message-id: <47671957.6070802@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Enigmail-Version: 0.95.1 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <20071218002218.GC741781@eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071105) Status: RO Content-Length: 12646 It would seem simpler (from the user perspective at least, not sure about the code) if you could insert a value into the $MANPATH to add the automatic paths at that point, so your example would reduce to something more like: MANPATH=auto: though a --found-dynamic-manpath-search-directories would be useful for debugging purposes. -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering Edward Pilatowicz wrote: > i really like the suggested manpatch search mechanism. > it should make the management of manpath much easier. > > that said, currently i have some MANPATH entries (ie, > entries in my MANPATH environment variable) which aren't > associated with any PATH entries. so to switch to this > new mechanism i'd have to drop these entries. so what > i was wondering is would it be possible to have some > new man(1) cli option that would display the current > dynamic man search path in the format of a MANPATH variable? > this would allow me to do something like the following > in my profile: > > PATH=" > unset MANPATH > MANPATH=`man --found-dynamic-manpath-search-directories` > MANPATH=$MANPATH: > export MANPATH > > thoughts? > ed > > On Wed, Dec 12, 2007 at 10:55:34PM -0800, John Plocher wrote: >> I am ARC-sponsoring this fasttrack from Mike Gerdts, an >> OpenSolaris community member. Mike is finding someone else >> to be his code/putback sponsor... >> >> Binding is to a minor release of the ON consolidation. >> >> As mentioned in 4.5 below: >> >> The interface stability of man(1) is documented as "Standard" >> ("Comitted", in updated terminology). This project alters the >> documented "Search Path" behavior when MANPATH is not set. >> >> This project also extends the documented interface to man(1) >> such that "name" arguments that specify a fully qualified or >> relative path (with at least one '/' character) alter the >> documented "Search Path" behavior. >> >> Corresponding interface changes apply to whatis(1), catman(1), >> and apropos(1) which are all hard links to man(1). >> >> -John >> >> >> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >> This information is Copyright 2007 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> manwhich: Deriving MANPATH from PATH >> 1.2. Name of Document Author/Supplier: >> Author: Mike Gerdts >> 1.3 Date of This Document: >> 12 December, 2007 >> 4. Technical Description >> 1. Introduction >> 1.1. Project/Component Working Name: >> manwhich: Deriving MANPATH from PATH >> >> 1.2. Name of Document Author/Supplier: >> Mike Gerdts >> OpenSolaris Contributor ID OS0018 >> >> 1.3. Date of This Document: >> 12/12/2007 >> >> 1.4. Name of Major Document Customer(s)/Consumer(s): >> 1.4.1. The Community you expect to review your project: >> ON >> >> 1.4.2. The ARC(s) you expect to review your project: >> OpenSolaris ARC >> >> 1.5. Email Aliases: >> 1.5.2. Responsible Engineer: >> Mike Gerdts >> >> 1.5.4. Interest List: >> opensolaris-code@opensolaris.org >> >> 2. Project Summary >> 2.1. Project Description: >> When projects such as Indiana or individuals customize PATH, >> MANPATH is often left unset. This leads to confusion because man(1) >> will display the manual page for the wrong variant of a command. >> For example, if /usr/gnu/bin is at the front of the path, the >> default behavior of man(1) would most appropriately be to display a >> manual page from /usr/gnu/share/man rather than /usr/share/man. >> Similar, but slightly more complex, considerations are made for >> /usr/ucb and for invocations of man(1) that specify the path to the >> executable for which a man page is sought. >> >> 2.2. Risks and Assumptions: >> Traditional behavior and expectation is that /usr/share/man is the >> only directory searched in the case that the MANPATH environment >> variable is undefined. This behavior is documented in the man page >> for man. >> >> 3. Business Summary >> 3.1. Problem Area: >> This project increases the usability of online help accessed through >> the command line. History has shown that end-users have little >> success in keeping MANPATH in sync with PATH. >> >> 3.2. Market/Requester: >> Users and developers who wish to learn how to use the commands and >> utilities found in OpenSolaris. >> >> 3.3. Business Justification: >> As more FOSS functionality is added to various parts of OpenSolaris >> and its distros, keeping individual user's MANPATHs up to date gets >> harder and harder. This project effectively removes the >> requirement for most users to even bother setting it in the first >> place. >> >> 3.4. Competitive Analysis: >> Various Linux and *BSD distros provide similar or related >> mechanisms. >> >> 3.5. Opportunity Window/Exposure: >> // Time-to-market window, if any, and precision. >> >> 3.6. How will you know when you are done?: >> When the user has "unset MANPATH", "man foo" will find the man page >> associated with foo as determined by the user's PATH setting. >> >> 4. Technical Description: >> 4.1. Details: >> The source file man.c will be enhanced to refer to PATH only in the >> absence of MANPATH. Each element of PATH will be translated based >> into the appropriate MANPATH element based upon the following >> priorities: >> >> - Explicit transformation rule. For example, /usr/ucb in PATH >> translates to /usr/share/man,1b. >> - The parent directory of the PATH directory with /share/man >> appended. For example, /usr/gnu/bin becomes >> /usr/gnu/share/man. >> - The parent directory of the PATH directory with /man >> appended. For example, /opt/VRTSvcs/bin becomes >> /opt/VRTSvcs/man because /opt/VRTSvcs/share/man does not exist >> but /opt/VRTSvcs/man does. >> >> In addition and higher precedence to the above, if man is invoked >> referring to particular instance of a command (e.g. "man ./ls" or >> "man /usr/ucb/ps") the path transformation rules are applied using >> the directory component of the argument. >> >> In all cases where MANPATH is not defined and the path to a command >> is not specified /usr/share/man will be appended to MANPATH if it >> is not otherwise included based upon PATH transform rules. This >> ensures that sections other than 1* are accessible. >> >> A prototype of this behavior has been implemented and is available >> for review at http://cr.opensolaris.org/~mgerdts/manpath-from-path/. >> >> 4.2. Bug/RFE Number(s): >> 6634079 man should take hints from PATH when MANPATH not set >> 6516767 RFE:/etc/profile should set ${MANPATH} to >> ${PATH}/${LANG}-related value >> >> 4.3. In Scope: >> Described above. >> >> 4.4. Out of Scope: >> GNU utilities often times provide only stub man pages and more >> complete documentation using an alternative format known as "info". >> While translators from info to man do exist, this project does not >> seek to bridge this gap. >> >> 4.5. Interfaces: >> The interface stability of man(1) is documented as "Standard" >> ("Comitted", in updated terminology). This project alters the >> documented "Search Path" behavior when MANPATH is not set. >> >> This project also extends the documented interface to man(1) such >> that "name" arguments that specify a fully qualified or relative >> path (with at least one '/' character) alter the documented "Search >> Path" behavior. >> >> Corresponding interface changes apply to whatis(1), catman(1), and >> apropos(1) which are all hard links to man(1). >> >> 4.6. Doc Impact: >> >> man(1) man page will be enhanced as follows: >> >> OPERANDS >> The following operand is supported: >> >> name The name of a standard utility or a keyword. If the >> name contains a '/' character, the search path (See >> "Search Path") is altered to search only the man >> directory corresponding to the name argument. For >> example, if name is "/usr/ucb/ps" man will behave as >> if the MANPATH environment variable is set to >> /usr/share/man,1b. >> . . . >> >> Search Path >> Before searching for a given name, man constructs a list of >> candidate directories and sections. man searches for name in >> the directories specified by the MANPATH environment vari- >> able. If this variable is not set, a substitute MANPATH >> is constructed based upon the PATH environment variable. In >> all cases, except as described above when the name operand >> has a "/" character, /usr/share/man is searched. >> >> For each name operand that contains a "/" character, neither >> MANPATH nor PATH are used to construct the search path. >> >> . . . >> >> ENVIRONMENT VARIABLES >> . . . >> >> MANPATH A colon-separated list of directories; each >> directory can be followed by a comma-separated >> list of sections. If set, its value overrides >> the default directory search path, and man.cf as >> the default section search path. The -M and -s >> flags, in turn, override these values. The >> default directory search path is constructed >> based upon the contents of the PATH environment >> variable with /usr/share/man appended, as >> necessary. >> >> PATH The search path for commands. If MANPATH is not >> set, MANPATH is derived from PATH. >> >> While the behavior of whatis changes in the event that a relative >> or absoluate command path provided, the whatis(1) man page is >> sufficiently vague as to not require any changes to remain >> accurate. whatis(1) indicates that it is equivalent to "the -f >> option of the man(1) command" and as such refers users to more >> complete documentation. >> >> 4.7. Admin/Config Impact: >> On systems without MANPATH explicitly set by the administrator, but >> with customized PATH, man(1) may provide results that are more >> likely to be correct for the users' environments. The system >> administration overhead for "more correct" behavior of man is thus >> reduced. >> >> 4.8. HA Impact: >> None. >> >> 4.9. I18N/L10N Impact: >> Aside from man pages mentioned above, none. No error or usage >> strings are added modified or added. >> >> 4.10. Packaging & Delivery: >> No impact. >> >> 4.11. Security Impact: >> No impact. >> >> 4.12. Dependencies: >> None. >> >> 5. Reference Documents: >> 6634079 man should take hints from PATH when MANPATH not set >> >> This CR was opened as a means for tracking this specific change. >> Absent from the scope of this CR is the behavior if the name >> operand contains a / character. >> >> http://mail.opensolaris.org/pipermail/opensolaris-code/2007-November/006390.html >> >> Initial discussion of this functionality and initial code review >> of prototype. >> >> 6. Resources and Schedule: >> 6.1. Projected Availability: >> December, 2007. >> >> 6.2. Cost of Effort: >> One to two people-months of part-time work. >> >> 6.4. Product Approval Committee requested information: >> 6.4.1. Consolidation or Component Name: >> ON >> >> 6.4.7. Target RTI Date/Release: >> Build 81, 82, or 83 (December 2007 - January 2008) >> >> 6.4.8. Target Code Design Review Date: >> December 13, 2007 >> >> 6.5. ARC review type: >> FastTrack >> 6.6. ARC Exposure: open >> 6.6.1. Rationale: Part of OpenSolaris >> >> 7. Prototype Availability: >> 7.1. Prototype Availability: >> prototype available December 12, 2007 at >> http://cr.opensolaris.org/~mgerdts/manpath-from-path/. This >> prototype offers nearly complete functionality. >> >> 7.2. Prototype Cost: >> 2 part-time programmer-weeks. >> >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> ON >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org From scott.rotondo@sun.com Mon Dec 17 17:42:02 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBI1g2s4005749 for ; Mon, 17 Dec 2007 17:42:02 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBI1g1cZ020858 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 17 Dec 2007 17:42:01 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT800703221TJ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 17 Dec 2007 18:42:01 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT800D52220SY80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 17 Dec 2007 18:42:00 -0700 (MST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBI1g0We018797; Mon, 17 Dec 2007 17:42:00 -0800 (PST) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id lBI1fxY17177; Mon, 17 Dec 2007 17:41:59 -0800 (PST) Date: Mon, 17 Dec 2007 17:41:59 -0800 From: Scott Rotondo Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <47671957.6070802@sun.com> To: Alan Coopersmith Cc: Edward Pilatowicz , John Plocher , PSARC-ext@sun.com, mgerdts@gmail.com Message-id: <47672567.3090904@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <20071218002218.GC741781@eng.sun.com> <47671957.6070802@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1655 Alan Coopersmith wrote: > It would seem simpler (from the user perspective at least, > not sure about the code) if you could insert a value into the > $MANPATH to add the automatic paths at that point, so your > example would reduce to something more like: > MANPATH=auto: > > though a --found-dynamic-manpath-search-directories would be > useful for debugging purposes. To me, Ed's proposal seems more consistent with the approach traditionally used by UNIX utilities. It lets you do everything you could do with the magic "auto" keyword, plus: 1. You can use sed / perl / whatever to transform the automatic paths in some way before adding them to MANPATH. 2. It's useful for debugging, as you said. 3. It doesn't require reserving a special "auto" keyword or recognizing it when parsing MANPATH. Scott > Edward Pilatowicz wrote: >> i really like the suggested manpatch search mechanism. >> it should make the management of manpath much easier. >> >> that said, currently i have some MANPATH entries (ie, >> entries in my MANPATH environment variable) which aren't >> associated with any PATH entries. so to switch to this >> new mechanism i'd have to drop these entries. so what >> i was wondering is would it be possible to have some >> new man(1) cli option that would display the current >> dynamic man search path in the format of a MANPATH variable? >> this would allow me to do something like the following >> in my profile: >> >> PATH=" >> unset MANPATH >> MANPATH=`man --found-dynamic-manpath-search-directories` >> MANPATH=$MANPATH: >> export MANPATH >> >> thoughts? >> ed >> From mgerdts@gmail.com Mon Dec 17 19:18:03 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBI3I2PP008067 for ; Mon, 17 Dec 2007 19:18:02 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBI3HwoU013735 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 18 Dec 2007 11:18:01 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT8007036HXP600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 17 Dec 2007 19:17:57 -0800 (PST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT800MXT6HXOX60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 17 Dec 2007 19:17:57 -0800 (PST) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBI3Hu3K021094 for ; Tue, 18 Dec 2007 03:17:56 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay42i.sun.com with ESMTP id BT-MMP-224539 for PSARC-ext@sun.com; Tue, 18 Dec 2007 03:17:56 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms48es.sun.com with ESMTP id BT-MMP-57303 for PSARC-ext@sun.com; Tue, 18 Dec 2007 03:17:56 +0000 (Z) Received: from wa-out-1112.google.com ([209.85.146.183] [209.85.146.183]) by relay4i.sun.com with ESMTP id BT-MMP-7208621 for PSARC-ext@sun.com; Tue, 18 Dec 2007 03:17:56 +0000 (Z) Received: by wa-out-1112.google.com with SMTP id l24so4069711waf.22 for ; Mon, 17 Dec 2007 19:17:55 -0800 (PST) Received: by 10.114.170.1 with SMTP id s1mr66925wae.54.1197947875237; Mon, 17 Dec 2007 19:17:55 -0800 (PST) Received: by 10.114.109.20 with HTTP; Mon, 17 Dec 2007 19:17:55 -0800 (PST) Date: Mon, 17 Dec 2007 21:17:55 -0600 From: Mike Gerdts Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <20071218002218.GC741781@eng.sun.com> To: Edward Pilatowicz Cc: John Plocher , PSARC-ext@sun.com Message-id: <65f8f3ad0712171917l69097411kb605897894fbccf4@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=7vTSLOe1LX22EdliCFJwSX06jCfooFqsLDOBeJqaQ4Q=; b=BDw8IB10U6wc284vZYPCJJXZgbwxI8VoLqOEujG2bTExD9NnnbRZ1GmVd3CHQnMIi/BMIakzzSZT5+OtIwTVUXZ4A5Ho6ZT18hN9jfa+jmjgI90rLgbp0GatZx/p73wJSgTq/Boh/PeyZFI3DhZwB4I9RER6t+8lny2TydVYEG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EJ2OAN26h7VMx1Of7kn/vkXWh+ziDAfMMZwRg8IizHeqoLmbMnsgLi5RuCMZoz8Z4EbQHU2acC46/XjZ5bPctVNSSJacsEpxzOCVqOWugTwYe5OkO8aVOaaPNUsJumKnPfPYYUbmyYlQJdqlvPcokKVuFCi7jVRiaSoMI+IVyTU= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <20071218002218.GC741781@eng.sun.com> Status: RO Content-Length: 1646 On Dec 17, 2007 6:22 PM, Edward Pilatowicz wrote: > i really like the suggested manpatch search mechanism. > it should make the management of manpath much easier. > > that said, currently i have some MANPATH entries (ie, > entries in my MANPATH environment variable) which aren't > associated with any PATH entries. so to switch to this > new mechanism i'd have to drop these entries. so what > i was wondering is would it be possible to have some > new man(1) cli option that would display the current > dynamic man search path in the format of a MANPATH variable? > this would allow me to do something like the following > in my profile: > > PATH=" > unset MANPATH > MANPATH=`man --found-dynamic-manpath-search-directories` > MANPATH=$MANPATH: > export MANPATH > > thoughts? > ed Interesting idea. As others have stated, this would also be useful for debugging or understanding path to manpath translations. How does this usage look? $ PATH=/usr/gnu/bin:/usr/xpg4/bin:/usr/ucb man -p /usr/gnu/share/man:/usr/share/man,1:/usr/share/man,1b:/usr/share/man, $ cd /usr/sbin $ man -p ./ping ./ping /usr/share/man,1m $ man -p /usr/sbin/ping /usr/gnu/bin/ls /usr/sbin/ping /usr/share/man,1m /usr/gnu/bin/ls /usr/gnu/share/man Note that the output would expose the internals of duplicate avoidance logic that I've added, which could be ugly. From a debugging perspective, it could be useful information. It would also give the ability to set up a functional (but ugly) MANPATH. -- Mike Gerdts http://mgerdts.blogspot.com/ From mgerdts@gmail.com Mon Dec 17 20:05:16 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBI45GMG008657 for ; Mon, 17 Dec 2007 20:05:16 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBI45G7S013265 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 17 Dec 2007 20:05:16 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT800J0T8ORS600@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 17 Dec 2007 21:05:15 -0700 (MST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT800D7X8OQSWD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 17 Dec 2007 21:05:15 -0700 (MST) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBI45AR2011417 for ; Tue, 18 Dec 2007 04:05:10 +0000 (GMT) Received: from mms22es.sun.com ([150.143.232.34] [150.143.232.34]) by relay22i.sun.com with ESMTP id BT-MMP-260208 for PSARC-ext@sun.com; Tue, 18 Dec 2007 04:05:10 +0000 (Z) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24]) by mms22es.sun.com with ESMTP id BT-MMP-1496912 for PSARC-ext@sun.com; Tue, 18 Dec 2007 04:05:09 +0000 (Z) Received: from wa-out-1112.google.com ([209.85.146.181] [209.85.146.181]) by relay21i.sun.com with ESMTP id BT-MMP-6942914 for PSARC-ext@sun.com; Tue, 18 Dec 2007 04:05:09 +0000 (Z) Received: by wa-out-1112.google.com with SMTP id l24so4092016waf.22 for ; Mon, 17 Dec 2007 20:05:09 -0800 (PST) Received: by 10.114.107.19 with SMTP id f19mr1283392wac.113.1197950709132; Mon, 17 Dec 2007 20:05:09 -0800 (PST) Received: by 10.114.109.20 with HTTP; Mon, 17 Dec 2007 20:05:09 -0800 (PST) Date: Mon, 17 Dec 2007 22:05:09 -0600 From: Mike Gerdts Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <47671957.6070802@sun.com> To: Alan Coopersmith Cc: Edward Pilatowicz , John Plocher , PSARC-ext@sun.com Message-id: <65f8f3ad0712172005m241521a4i1e4d19cc875eed4c@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Bu0I/MZoo8CptT6Ya5iYaFeobCBc5jio+1dQ24OfbCc=; b=NeW/Vu40GMhCRRRwVeTwpCELH5+j6KCo8R7rQaEYEY5+JsqBAHAp3qdpjaPZ9wP8En67EYLYOR5Jh12sgZD2sedrxbgjsL5g4FFxSDklEztEkDkC+1yXrNsI0qEDlWNWcKLn/sf9kGxzMWMy5PkJcN/zD8eGayXP7M57kEjtMCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jdARNxPS32ONjuTm22hQFuGDI05S7Lh/qz5v7ftKiiVx3beRz8/b5+wpHKLNVm6WSg7nabeIy8VZoOHnHRZYkQzd+fgsZUuxK3ao4JsGduT7k9BUlEJ78CKFaBdXx/RgXL8fF5IMhAz85WuyS6IxCIjB/zrOYB0y/I/IrRA2Los= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <20071218002218.GC741781@eng.sun.com> <47671957.6070802@sun.com> Status: RO Content-Length: 892 On Dec 17, 2007 6:50 PM, Alan Coopersmith wrote: > It would seem simpler (from the user perspective at least, > not sure about the code) if you could insert a value into the > $MANPATH to add the automatic paths at that point, so your > example would reduce to something more like: > MANPATH=auto: The code for this would be somewhat ugly given the current structure of the code. My initial reaction is that I would like to put off this addition given that a much less intrusive option exists. Those that are likely to be picky about their manpath are likely to be the same set that would not find using Ed's proposed method terribly onerous. > though a --found-dynamic-manpath-search-directories would be > useful for debugging purposes. I think that for Ed's usage, it would work as well. -- Mike Gerdts http://mgerdts.blogspot.com/ From Darren.Reed@sun.com Mon Dec 17 20:06:47 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBI46k05008676 for ; Mon, 17 Dec 2007 20:06:46 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBI46OmT014953 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 18 Dec 2007 04:06:45 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT80020T8R7K200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 17 Dec 2007 20:06:43 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT800FZZ8R45RC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 17 Dec 2007 20:06:42 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBI46eVa022558 for ; Tue, 18 Dec 2007 04:06:40 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JT8003018L7RQ00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 Dec 2007 12:06:40 +0800 (SGT) Received: from [129.158.87.34] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JT80045O8R3UDR0@mail-apac.sun.com>; Tue, 18 Dec 2007 12:06:40 +0800 (SGT) Date: Tue, 18 Dec 2007 15:06:12 +1100 From: Darren Reed Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <65f8f3ad0712152226l5b542a79h47b894680072d69a@mail.gmail.com> Sender: Darren.Reed@sun.com To: Mike Gerdts Cc: John Plocher , PSARC-ext@sun.com Message-id: <47674734.3070806@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <65f8f3ad0712152226l5b542a79h47b894680072d69a@mail.gmail.com> User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) Status: RO Content-Length: 10615 For completeness, is there any requirement to mention how the -M command line option interacts here or should it just be assumed that this is the equivalent of setting MANPATH to the same value for the execution of the command (man/catman)? Mike Gerdts wrote: > On Dec 13, 2007 12:55 AM, John Plocher wrote: > >> I am ARC-sponsoring this fasttrack from Mike Gerdts, an >> OpenSolaris community member. Mike is finding someone else >> to be his code/putback sponsor... >> > > Based upon feedback received (thanks!), the spec has been updated with the > following changes: > > - Made it clear that legacy behavior is to be expected if MANPATH is > set. > - Add more detailed explanation of PATH to MANPATH transformation rules > - Reversed relative precedence of share/man vs. man to align with > filesystem(5). > - Added NOTE in man(1) that path transformations involving > /share/man exist for legacy support reasons and refer to > filesystem(5) > - Add SEE ALSO in man(1) for filesystem(5). > - Clarify "Search Path" section of man(1) with regards to "man -M ..." > - Add Sections 4.6.2 and 4.6.3 to clarify changes or lack thereof for > catman(1M), whatis(1), and apropos(1). > > Updated spec follows: > > 2. Project Summary > 2.1. Project Description: > When projects such as Indiana or individuals customize PATH, > MANPATH is often left unset. This leads to confusion because man(1) > will display the manual page for the wrong variant of a command. > For example, if /usr/gnu/bin is at the front of the path, the > default behavior of man(1) would most appropriately be to display a > manual page from /usr/gnu/share/man rather than /usr/share/man. > Similar, but slightly more complex, considerations are made for > /usr/ucb and for invocations of man(1) that specify the path to the > executable for which a man page is sought. > > 2.2. Risks and Assumptions: > Traditional behavior and expectation is that /usr/share/man is the > only directory searched in the case that the MANPATH environment > variable is undefined. This behavior is documented in the man page > for man. > > To allow behavior that closely resembles the legacy behavior of > man(1), setting MANPATH and using name arguments that do not > contain the "/" character will not invoke any PATH to MANPATH > translations. > > 4. Technical Description: > 4.1. Details: > The source file man.c will be enhanced to refer to PATH only in the > absence of MANPATH. Each element of PATH will be translated based > into the appropriate MANPATH element based upon the following > priorities: > > - Explicit transformation rule. For example, /usr/ucb in PATH > translates to /usr/share/man,1b. See below for details. > - The parent directory of the PATH directory with /man > appended. For example, /opt/VRTSvcs/bin becomes > /opt/VRTSvcs/man, assuming /opt/VRTSvcs/man exists. > - The parent directory of the PATH directory with /share/man > appended. For example, /usr/gnu/bin becomes > /usr/gnu/share/man because /usr/gnu/man does not exist. > > In addition and higher precedence to the above, if man is invoked > referring to particular instance of a command (e.g. "man ./ls" or > "man /usr/ucb/ps") the path transformation rules are applied using > the directory component of the argument. > > In all cases where MANPATH is not defined and the path to a command > is not specified /usr/share/man will be appended to MANPATH if it > is not otherwise included based upon PATH transform rules. This > ensures that sections other than 1* are accessible. > > The PATH to MANPATH transformations are as follows: > > PATH element MANPATH element > ---------------- ------------------------------- > /sbin /usr/share/man,1m > /usr/sbin /usr/share/man,1m > /usr/ucb /usr/share/man,1b > /usr/bin /usr/share/man,1,1m,1s,1t,1c,1f > /usr/xpg4/bin /usr/share/man,1 > /usr/xpg6/bin /usr/share/man,1 > > Sections within each directory are explicitely set to ensure proper > ordering of results for invocations such as "man -l", "man -a", > whatis(1), etc. > > The transformation rules are stored in a data structure within > man.c. The use of such a static mapping instead of a configuration > file is chosen based upon the following: > > - The rules to use /man or /share/man directories > will accomodate the vast majority of add-on software. > - The alternative would be to create a configuration file to > store the mappings. History has shown that providers of add-on > software do not do a good job of modifying configuration files > properly during installation and removal of software. In > contrast, add-on software providers can easily create > strategically placed symbolic links to trigger the automatic > /man or /share/man translation. > - Providing a command to update the configuration file would be > significant work for a presumably very small number of edge > cases. > - If demand is shown, a configuration file can be added with very > little rework in the future. > > A prototype of this behavior has been implemented and is available > for review at http://cr.opensolaris.org/~mgerdts/manpath-from-path/. > > 4.3. In Scope: > Described above. > > 4.4. Out of Scope: > GNU utilities often times provide only stub man pages and more > complete documentation using an alternative format known as "info". > While translators from info to man do exist, this project does not > seek to bridge this gap. > > 4.5. Interfaces > The interface stability of man(1) is documented as "Standard" > ("Comitted", in updated terminology). This project alters the > documented "Search Path" behavior when MANPATH is not set. > > This project also extends the documented interface to man(1) such > that "name" arguments that specify a fully qualified or relative > path (with at least one '/' character) alter the documented "Search > Path" behavior. > > Corresponding interface changes apply to whatis(1), catman(1M), and > apropos(1) which are all hard links to man(1). > > 4.6. Doc Impact > 4.6.1. man(1) manual page > > The man(1) manual page will be enhanced as follows. > > OPERANDS > The following operand is supported: > > name The name of a standard utility or a keyword. If the > name contains a '/' character, the search path (See > "Search Path") is altered to search only the man > directory corresponding to the name argument. For > example, if name is "/usr/ucb/ps" man will behave as > if the MANPATH environment variable is set to > /usr/share/man,1b. > . . . > > Search Path > Before searching for a given name, man constructs a list of > candidate directories and sections. man searches for name in > the directories specified by the MANPATH environment vari- > able. If this variable is not set and the -M option is not > used, a substitute MANPATH is constructed based upon the > PATH environment variable. In all cases, except as described > above when the name operand has a "/" character, > /usr/share/man is searched. > > For each name operand that contains a "/" character, neither > MANPATH nor PATH are used to construct the search path. > > . . . > > ENVIRONMENT VARIABLES > . . . > > MANPATH A colon-separated list of directories; each > directory can be followed by a comma-separated > list of sections. If set, its value overrides > the default directory search path, and man.cf as > the default section search path. The -M and -s > flags, in turn, override these values. The > default directory search path is constructed > based upon the contents of the PATH environment > variable with /usr/share/man appended, as > necessary. > > PATH The search path for commands. If MANPATH is not > set, MANPATH is derived from PATH. > > SEE ALSO > apropos(1), cat(1), col(1), dpost(1), eqn(1), more(1), > nroff(1), refer(1), tbl(1), troff(1), vgrind(1), whatis(1), > catman(1M), attributes(5), environ(5), eqnchar(5), > filesystem(5), man(5), sgml(5), standards(5) > > NOTES > > When transforming PATH elements to MANPATH elements, man(1) > first attempts to transform /bin or /sbin to > /man, as filesystem(5) indicates that add-on software > should use /opt/packagename/man for manual pages. In the > event that /man does not exist but /share/man > does exist, /share/man will be searched. Searching > /share/man is intended for legacy compatibility only. > > 4.6.2. catman(1M) manaul page changes > > The catman(1M) manual page will change as follows: > > ENVIRONMENT VARIABLES > . . . > > MANPATH A colon-separated list of directories; each > directory can be followed by a comma-separated > list of sections. If set, its value overrides > the default directory search path, and man.cf as > the default section search path. The -M and -s > flags, in turn, override these values. The > default directory search path is constructed > based upon the contents of the PATH environment > variable with /usr/share/man appended, as > necessary. > > PATH The search path for commands. If MANPATH is not > set, MANPATH is derived from PATH. > > 4.6.3. Related manual pages not changing > > While the behavior of whatis(1) changes in the event that MANPATH > is not set or a relative or absolute command path provided, the > whatis(1) man page is sufficiently vague as to not require any > changes to remain accurate. whatis(1) indicates that it is > equivalent to "the -f option of the man(1) command" and as such > refers users to more complete documentation. > > Similarly, the behavior of apropos(1) changes in the event that > MANPATH is not set. However, the man page for apropos(1) is > sufficiently vague to as to not require any changes to remain > accurate. apropos(1) indicates "apropos is actually just the -k > option to the man(1) command" and as such refers users to more > complete documentation. > > From mgerdts@gmail.com Mon Dec 17 20:21:51 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBI4Lo8t008718 for ; Mon, 17 Dec 2007 20:21:51 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBI4LfDb003985 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 18 Dec 2007 12:21:50 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT800L099GB3N00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 17 Dec 2007 21:21:47 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT800DJO9GAT0D0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 17 Dec 2007 21:21:46 -0700 (MST) Received: from relay16i.sun.com (ip126.net129179-4.block1.us.syntegra.com [129.179.4.126]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBI4LkgW026662 for ; Tue, 18 Dec 2007 04:21:46 +0000 (GMT) Received: from mmp12es.sun.com ([160.41.209.22] [160.41.209.22]) by relay16i.sun.com with ESMTP id BT-MMP-11885 for PSARC-ext@sun.com; Tue, 18 Dec 2007 04:21:46 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp12es.sun.com with ESMTP id BT-MMP-118566 for PSARC-ext@sun.com; Tue, 18 Dec 2007 04:21:46 +0000 (Z) Received: from wa-out-1112.google.com ([209.85.146.182] [209.85.146.182]) by relay1ib.sun.com with ESMTP id BT-MMP-34038 for PSARC-ext@sun.com; Tue, 18 Dec 2007 04:21:46 +0000 (Z) Received: by wa-out-1112.google.com with SMTP id l24so4099042waf.22 for ; Mon, 17 Dec 2007 20:20:46 -0800 (PST) Received: by 10.114.144.1 with SMTP id r1mr3511354wad.53.1197951646096; Mon, 17 Dec 2007 20:20:46 -0800 (PST) Received: by 10.114.109.20 with HTTP; Mon, 17 Dec 2007 20:20:46 -0800 (PST) Date: Mon, 17 Dec 2007 22:20:46 -0600 From: Mike Gerdts Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <47674734.3070806@Sun.COM> To: Darren Reed Cc: John Plocher , PSARC-ext@sun.com Message-id: <65f8f3ad0712172020jc2486bfkf3401a12f3ebcda@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=YXNDtMN02RdRE5itF5r4o58bA/0kdRJnPcDHGFzKqqM=; b=EAE9TaIHSE24bNJlKWlf/TvY8yrVx7vG60W/JP78TmMJe/kTZyYzS9PoFvoOQZsVpd5ApOF4sZ02dbi4hDFZ5SYzj+754B4s7YJhQrFQNbye/xtIZQ75wFz2ypr8MxAUWdq27m/x4Na1uaomJ6tZmmnhCsETqQo+GCCq9kCDkwo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UZvb9xsK6iB893Fzl2V6oBzuDN/hL/DuhKuW8u1QneIeK7C7TNpXQhrsgh4YlpZ58rc6F7ktMVPXPKMR0Axlxst+HHk+XOpdcPEEt6EhJ4veeasv8Rl0/MUYoESPY0DciFzC2v9yOT4DRp+KZhvieGq1l4Md1tfbBxQYETco5hI= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.3/5.0, scanned in 0.072sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <65f8f3ad0712152226l5b542a79h47b894680072d69a@mail.gmail.com> <47674734.3070806@Sun.COM> Status: RO Content-Length: 526 On Dec 17, 2007 10:06 PM, Darren Reed wrote: > For completeness, is there any requirement to mention how the > -M command line option interacts here or should it just be assumed > that this is the equivalent of setting MANPATH to the same value > for the execution of the command (man/catman)? Some clarity in the options section for -M is likely appropriate. I'll update the spec once Ed Pilatowicz' suggestion gets a few (US) daytime hours of discussion. -- Mike Gerdts http://mgerdts.blogspot.com/ From edward.pilatowicz@sun.com Tue Dec 18 17:28:08 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJ1S7WH008721 for ; Tue, 18 Dec 2007 17:28:08 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBJ1RwZB010922; Wed, 19 Dec 2007 09:28:05 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT90070VW2QBQ00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 18 Dec 2007 17:28:02 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT900L4ZW2P9CA0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 18 Dec 2007 17:28:02 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lBJ1Rv5t963378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Dec 2007 17:27:57 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id lBJ1Rv2p963377; Tue, 18 Dec 2007 17:27:57 -0800 (PST) Date: Tue, 18 Dec 2007 17:27:57 -0800 From: Edward Pilatowicz Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <65f8f3ad0712171917l69097411kb605897894fbccf4@mail.gmail.com> To: Mike Gerdts Cc: John Plocher , PSARC-ext@sun.com Message-id: <20071219012757.GB949816@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <20071218002218.GC741781@eng.sun.com> <65f8f3ad0712171917l69097411kb605897894fbccf4@mail.gmail.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 2289 On Mon, Dec 17, 2007 at 09:17:55PM -0600, Mike Gerdts wrote: > On Dec 17, 2007 6:22 PM, Edward Pilatowicz wrote: > > i really like the suggested manpatch search mechanism. > > it should make the management of manpath much easier. > > > > that said, currently i have some MANPATH entries (ie, > > entries in my MANPATH environment variable) which aren't > > associated with any PATH entries. so to switch to this > > new mechanism i'd have to drop these entries. so what > > i was wondering is would it be possible to have some > > new man(1) cli option that would display the current > > dynamic man search path in the format of a MANPATH variable? > > this would allow me to do something like the following > > in my profile: > > > > PATH=" > > unset MANPATH > > MANPATH=`man --found-dynamic-manpath-search-directories` > > MANPATH=$MANPATH: > > export MANPATH > > > > thoughts? > > ed > > Interesting idea. As others have stated, this would also be useful > for debugging or understanding path to manpath translations. How does > this usage look? > > $ PATH=/usr/gnu/bin:/usr/xpg4/bin:/usr/ucb man -p > /usr/gnu/share/man:/usr/share/man,1:/usr/share/man,1b:/usr/share/man, of sections> > so is there any reason to have the ",
" entries? couldn't we just set MANPATH without these? (that's how i currently setup my manpath. > $ cd /usr/sbin > $ man -p ./ping > ./ping /usr/share/man,1m > > $ man -p /usr/sbin/ping /usr/gnu/bin/ls > /usr/sbin/ping /usr/share/man,1m > /usr/gnu/bin/ls /usr/gnu/share/man > well, aside from debugging i can't really come up with a use case for the functionality above. also, i was hoping that the output of the '-p' option to always be in the format of a MANPATH variable. ie, the output would always consist of directory paths seperated by a ':'. > Note that the output would expose the internals of duplicate avoidance > logic that I've added, which could be ugly. From a debugging > perspective, it could be useful information. It would also give the > ability to set up a functional (but ugly) MANPATH. > hm. i'm not sure i understand how your duplicate avoidance logic would be exposed. could you provide an example? ed From binarycrusader@gmail.com Tue Dec 18 21:15:48 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJ5FlkK012738 for ; Tue, 18 Dec 2007 21:15:47 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBJ5FfDZ026175 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 Dec 2007 13:15:46 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTA00L016M7TV00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 Dec 2007 21:15:43 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTA00JYZ6M79E00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 Dec 2007 21:15:43 -0800 (PST) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBJ5FhwW025231 for ; Wed, 19 Dec 2007 05:15:43 +0000 (GMT) Received: from mmp13es.sun.com ([160.41.209.23] [160.41.209.23]) by relay14i.sun.com with ESMTP id BT-MMP-17827 for PSARC-ext@sun.com; Wed, 19 Dec 2007 05:15:42 +0000 (Z) Received: from relay18i.sun.com (relay18i.sun.com [129.179.4.128]) by mmp13es.sun.com with ESMTP id BT-MMP-60539 for PSARC-ext@sun.com; Wed, 19 Dec 2007 05:15:42 +0000 (Z) Received: from rv-out-0910.google.com ([209.85.198.188] [209.85.198.188]) by relay1i.sun.com with ESMTP id BT-MMP-142679 for PSARC-ext@sun.com; Wed, 19 Dec 2007 05:15:42 +0000 (Z) Received: by rv-out-0910.google.com with SMTP id c27so2572071rvf.8 for ; Tue, 18 Dec 2007 21:15:42 -0800 (PST) Received: by 10.140.180.11 with SMTP id c11mr5593255rvf.137.1198041342027; Tue, 18 Dec 2007 21:15:42 -0800 (PST) Received: by 10.140.127.12 with HTTP; Tue, 18 Dec 2007 21:15:41 -0800 (PST) Date: Tue, 18 Dec 2007 23:15:41 -0600 From: Shawn Walker Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <20071219012757.GB949816@eng.sun.com> Sender: binarycrusader@gmail.com To: Edward Pilatowicz Cc: Mike Gerdts , PSARC-ext@sun.com, John Plocher Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=9W8qr5UjwMbM9ZzsEwMDUuptwPfc+1LX6moNz++5kN0=; b=GgcblCu/pgK/bVF72PAtdAQy6Uanq3logzgOh1SDR7gpqsEEZbZA2YvJCAkCKPTPZRCi5Z1YWP26dUcPBeQA58A37Rxsvcb1cEge6/PKU0+lVNZ5JvIXjNa5Q1norHltUm95vEgdBshwCGahdGt32JdUmXovDw+cG/P6Tvw+n3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Ippda+4SFZrtQj4c+MfmLkyfhesHtprB5RHOQNmUVv03ILVs04/YzSY+4P62kzowGhopTArsLbi7IVJjhDBPlDMLU62RVYqD9sC3zo6yy3jyTASJ3wyQi5xWGSYM4zFWMclXg7TEYs2+6rZN0UDKpAxr05eLDNHMh5VMt9gASmM= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 83289ebf13a5c22d X-Antispam: No, score=-2.2/5.0, scanned in 0.073sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <20071218002218.GC741781@eng.sun.com> <65f8f3ad0712171917l69097411kb605897894fbccf4@mail.gmail.com> <20071219012757.GB949816@eng.sun.com> Status: RO Content-Length: 1828 On Dec 18, 2007 7:27 PM, Edward Pilatowicz wrote: > > On Mon, Dec 17, 2007 at 09:17:55PM -0600, Mike Gerdts wrote: > > On Dec 17, 2007 6:22 PM, Edward Pilatowicz wrote: > > > i really like the suggested manpatch search mechanism. > > > it should make the management of manpath much easier. > > > > > > that said, currently i have some MANPATH entries (ie, > > > entries in my MANPATH environment variable) which aren't > > > associated with any PATH entries. so to switch to this > > > new mechanism i'd have to drop these entries. so what > > > i was wondering is would it be possible to have some > > > new man(1) cli option that would display the current > > > dynamic man search path in the format of a MANPATH variable? > > > this would allow me to do something like the following > > > in my profile: > > > > > > PATH=" > > > unset MANPATH > > > MANPATH=`man --found-dynamic-manpath-search-directories` > > > MANPATH=$MANPATH: > > > export MANPATH > > > > > > thoughts? > > > ed > > > > Interesting idea. As others have stated, this would also be useful > > for debugging or understanding path to manpath translations. How does > > this usage look? > > > > $ PATH=/usr/gnu/bin:/usr/xpg4/bin:/usr/ucb man -p > > /usr/gnu/share/man:/usr/share/man,1:/usr/share/man,1b:/usr/share/man, > of sections> > > > > so is there any reason to have the ",
" entries? > couldn't we just set MANPATH without these? (that's how i currently > setup my manpath. I believe these are to accommodate things like /usr/ucb, etc. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben From edward.pilatowicz@sun.com Tue Dec 18 21:21:25 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJ5LOpc012916 for ; Tue, 18 Dec 2007 21:21:24 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBJ5L9B3028307; Wed, 19 Dec 2007 13:21:21 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTA00M096VJSM00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 18 Dec 2007 21:21:19 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTA00JBZ6VJ9E10@nwk-avmta-1.sfbay.Sun.COM>; Tue, 18 Dec 2007 21:21:19 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lBJ5LI5Z986830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Dec 2007 21:21:18 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id lBJ5LI3n986829; Tue, 18 Dec 2007 21:21:18 -0800 (PST) Date: Tue, 18 Dec 2007 21:21:18 -0800 From: Edward Pilatowicz Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: To: Shawn Walker Cc: Mike Gerdts , PSARC-ext@sun.com, John Plocher Message-id: <20071219052118.GO949816@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <20071218002218.GC741781@eng.sun.com> <65f8f3ad0712171917l69097411kb605897894fbccf4@mail.gmail.com> <20071219012757.GB949816@eng.sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1965 On Tue, Dec 18, 2007 at 11:15:41PM -0600, Shawn Walker wrote: > On Dec 18, 2007 7:27 PM, Edward Pilatowicz wrote: > > > > On Mon, Dec 17, 2007 at 09:17:55PM -0600, Mike Gerdts wrote: > > > On Dec 17, 2007 6:22 PM, Edward Pilatowicz wrote: > > > > i really like the suggested manpatch search mechanism. > > > > it should make the management of manpath much easier. > > > > > > > > that said, currently i have some MANPATH entries (ie, > > > > entries in my MANPATH environment variable) which aren't > > > > associated with any PATH entries. so to switch to this > > > > new mechanism i'd have to drop these entries. so what > > > > i was wondering is would it be possible to have some > > > > new man(1) cli option that would display the current > > > > dynamic man search path in the format of a MANPATH variable? > > > > this would allow me to do something like the following > > > > in my profile: > > > > > > > > PATH=" > > > > unset MANPATH > > > > MANPATH=`man --found-dynamic-manpath-search-directories` > > > > MANPATH=$MANPATH: > > > > export MANPATH > > > > > > > > thoughts? > > > > ed > > > > > > Interesting idea. As others have stated, this would also be useful > > > for debugging or understanding path to manpath translations. How does > > > this usage look? > > > > > > $ PATH=/usr/gnu/bin:/usr/xpg4/bin:/usr/ucb man -p > > > /usr/gnu/share/man:/usr/share/man,1:/usr/share/man,1b:/usr/share/man, > > of sections> > > > > > > > so is there any reason to have the ",
" entries? > > couldn't we just set MANPATH without these? (that's how i currently > > setup my manpath. > > I believe these are to accommodate things like /usr/ucb, etc. > ah. i get it. if /usr/ucb comes earlier in the path then you need ",1b" before ",1". right? if so, then ok. leave them in. thanks for the enlightenment. ed From Darren.Reed@sun.com Tue Dec 18 22:30:10 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJ6UAW4013718 for ; Tue, 18 Dec 2007 22:30:10 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBJ6U9rr019632 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 18 Dec 2007 22:30:10 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTA00E01A29PN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 Dec 2007 22:30:09 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTA007LZA27I470@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 Dec 2007 22:30:09 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBJ6U7fe002300 for ; Wed, 19 Dec 2007 06:30:07 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JTA00A01A1ECE00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Dec 2007 14:30:07 +0800 (SGT) Received: from [129.158.87.228] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JTA00CTMA25UAH2@mail-apac.sun.com>; Wed, 19 Dec 2007 14:30:07 +0800 (SGT) Date: Wed, 19 Dec 2007 17:29:36 +1100 From: Darren Reed Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <20071219052118.GO949816@eng.sun.com> Sender: Darren.Reed@sun.com To: Edward Pilatowicz Cc: Shawn Walker , Mike Gerdts , PSARC-ext@sun.com, John Plocher Message-id: <4768BA50.8000507@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <20071218002218.GC741781@eng.sun.com> <65f8f3ad0712171917l69097411kb605897894fbccf4@mail.gmail.com> <20071219012757.GB949816@eng.sun.com> <20071219052118.GO949816@eng.sun.com> User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) Status: RO Content-Length: 2324 Edward Pilatowicz wrote: > On Tue, Dec 18, 2007 at 11:15:41PM -0600, Shawn Walker wrote: > >> On Dec 18, 2007 7:27 PM, Edward Pilatowicz wrote: >> >>> On Mon, Dec 17, 2007 at 09:17:55PM -0600, Mike Gerdts wrote: >>> >>>> On Dec 17, 2007 6:22 PM, Edward Pilatowicz wrote: >>>> >>>>> i really like the suggested manpatch search mechanism. >>>>> it should make the management of manpath much easier. >>>>> >>>>> that said, currently i have some MANPATH entries (ie, >>>>> entries in my MANPATH environment variable) which aren't >>>>> associated with any PATH entries. so to switch to this >>>>> new mechanism i'd have to drop these entries. so what >>>>> i was wondering is would it be possible to have some >>>>> new man(1) cli option that would display the current >>>>> dynamic man search path in the format of a MANPATH variable? >>>>> this would allow me to do something like the following >>>>> in my profile: >>>>> >>>>> PATH=" >>>>> unset MANPATH >>>>> MANPATH=`man --found-dynamic-manpath-search-directories` >>>>> MANPATH=$MANPATH: >>>>> export MANPATH >>>>> >>>>> thoughts? >>>>> ed >>>>> >>>> Interesting idea. As others have stated, this would also be useful >>>> for debugging or understanding path to manpath translations. How does >>>> this usage look? >>>> >>>> $ PATH=/usr/gnu/bin:/usr/xpg4/bin:/usr/ucb man -p >>>> /usr/gnu/share/man:/usr/share/man,1:/usr/share/man,1b:/usr/share/man,>>> of sections> >>>> >>>> >>> so is there any reason to have the ",
" entries? >>> couldn't we just set MANPATH without these? (that's how i currently >>> setup my manpath. >>> >> I believe these are to accommodate things like /usr/ucb, etc. >> >> > > ah. i get it. if /usr/ucb comes earlier in the path then you need > ",1b" before ",1". right? if so, then ok. leave them in. > thanks for the enlightenment. > What is the intended behaviour when if I have MANSECTS set in man.cf, but MANPATH unset, possibly in conflict with the ordering of paths in PATH? e.g. $PATH has /usr/ucb:/usr/bin, but MANSECTS in man.cf has 1,1b. Will this case result in /usr/share/man/man1,1b or /usr/share/man/man1b,1? Darren From mgerdts@gmail.com Wed Dec 19 06:16:50 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJEGo0D022693 for ; Wed, 19 Dec 2007 06:16:50 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBJEGc5Z000467 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 Dec 2007 14:16:48 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTA00C0RVNZT000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Dec 2007 06:16:47 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTA00KJSVNXHYC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Dec 2007 06:16:46 -0800 (PST) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBJECugT024444 for ; Wed, 19 Dec 2007 14:16:45 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay43i.sun.com with ESMTP id BT-MMP-354060 for PSARC-ext@sun.com; Wed, 19 Dec 2007 14:16:45 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms49es.sun.com with ESMTP id BT-MMP-383359 for PSARC-ext@sun.com; Wed, 19 Dec 2007 14:16:45 +0000 (Z) Received: from hs-out-2122.google.com ([64.233.178.242] [64.233.178.242]) by relay4i.sun.com with ESMTP id BT-MMP-10484163 for PSARC-ext@sun.com; Wed, 19 Dec 2007 14:16:45 +0000 (Z) Received: by hs-out-2122.google.com with SMTP id 4so3060792hsl.8 for ; Wed, 19 Dec 2007 06:16:44 -0800 (PST) Received: by 10.143.161.3 with SMTP id n3mr1690366wfo.114.1198073803380; Wed, 19 Dec 2007 06:16:43 -0800 (PST) Received: by 10.142.172.15 with HTTP; Wed, 19 Dec 2007 06:16:43 -0800 (PST) Date: Wed, 19 Dec 2007 08:16:43 -0600 From: Mike Gerdts Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <4768BA50.8000507@Sun.COM> To: Darren Reed Cc: Edward Pilatowicz , Shawn Walker , PSARC-ext@sun.com, John Plocher Message-id: <65f8f3ad0712190616m6fe718c9i637c488e7ce8dd25@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=zrD/+7MeJ1NktYux5JkThf+xLFp9fftqdiFQRONAtgU=; b=R8VUrxz/ITOXOwO7oF1vXCmylfBurzPhkZM/SPukFCzzcAorNxGw/B8OxtyqQcBD7SuHl5pNpAJ3BG2OcbHX/Q39QlBSVod88pzODgZTTrShl5eAcQaZuOc+RGngwOAOs7rwdmNFzIo0ntLi0/snQqKd7Y+7boudxBKx8Qf3qcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lEH4v2vPnQpthgxxYwIHHCXe8jXGIY+Tvc3BqoN7W9yv9zYyebbFB3OhQaKY8M0y9WvMhkvtsM3kGzSAkF0KegjQH94JYm1TjaqwOhuEz5RD3bL4krHf9JOh6WfQ233FkbGi9Ni68LxXx7qmoaCVYcChAAzBL6u+WWr1BQ9vecQ= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> <20071218002218.GC741781@eng.sun.com> <65f8f3ad0712171917l69097411kb605897894fbccf4@mail.gmail.com> <20071219012757.GB949816@eng.sun.com> <20071219052118.GO949816@eng.sun.com> <4768BA50.8000507@Sun.COM> Status: RO Content-Length: 3198 On Dec 19, 2007 12:29 AM, Darren Reed wrote: > > Edward Pilatowicz wrote: > > On Tue, Dec 18, 2007 at 11:15:41PM -0600, Shawn Walker wrote: > > > >> On Dec 18, 2007 7:27 PM, Edward Pilatowicz wrote: > >> > >>> On Mon, Dec 17, 2007 at 09:17:55PM -0600, Mike Gerdts wrote: > >>> > >>>> On Dec 17, 2007 6:22 PM, Edward Pilatowicz wrote: > >>>> > >>>>> i really like the suggested manpatch search mechanism. > >>>>> it should make the management of manpath much easier. > >>>>> > >>>>> that said, currently i have some MANPATH entries (ie, > >>>>> entries in my MANPATH environment variable) which aren't > >>>>> associated with any PATH entries. so to switch to this > >>>>> new mechanism i'd have to drop these entries. so what > >>>>> i was wondering is would it be possible to have some > >>>>> new man(1) cli option that would display the current > >>>>> dynamic man search path in the format of a MANPATH variable? > >>>>> this would allow me to do something like the following > >>>>> in my profile: > >>>>> > >>>>> PATH=" > >>>>> unset MANPATH > >>>>> MANPATH=`man --found-dynamic-manpath-search-directories` > >>>>> MANPATH=$MANPATH: > >>>>> export MANPATH > >>>>> > >>>>> thoughts? > >>>>> ed > >>>>> > >>>> Interesting idea. As others have stated, this would also be useful > >>>> for debugging or understanding path to manpath translations. How does > >>>> this usage look? > >>>> > >>>> $ PATH=/usr/gnu/bin:/usr/xpg4/bin:/usr/ucb man -p > >>>> /usr/gnu/share/man:/usr/share/man,1:/usr/share/man,1b:/usr/share/man, >>>> of sections> > >>>> > >>>> > >>> so is there any reason to have the ",
" entries? > >>> couldn't we just set MANPATH without these? (that's how i currently > >>> setup my manpath. > >>> > >> I believe these are to accommodate things like /usr/ucb, etc. > >> > >> > > > > ah. i get it. if /usr/ucb comes earlier in the path then you need > > ",1b" before ",1". right? if so, then ok. leave them in. > > thanks for the enlightenment. > > > > What is the intended behaviour when if I have MANSECTS set in man.cf, > but MANPATH unset, possibly in conflict with the ordering of paths in PATH? > > e.g. $PATH has /usr/ucb:/usr/bin, but MANSECTS in man.cf has 1,1b. > Will this case result in /usr/share/man/man1,1b or /usr/share/man/man1b,1? If there is a translation rule for the PATH element and that translation specifies a section (e.g. /usr/ucb -> /usr/share/man,1b) man.cf is ignored when searching this element. For sake of easy discussion we could say that PATH=/usr/ucb:/usr/bin translates to "/usr/share/man,1b,1:/usr/share/man". That is, search 1b, then 1, then the rest. "The rest" is so that you can find things in sections other than 1* and so that if /usr/share/man doesn't otherwise come into MANPATH you can still find other information that is likely important. For the sake of accuracy, it would translate to: /usr/share/man,1b:/usr/share/man,1,1m,1s,1t,1c,1f:/usr/share/man, -- Mike Gerdts http://mgerdts.blogspot.com/ From mgerdts@gmail.com Wed Dec 19 09:49:31 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJHnUvF027177 for ; Wed, 19 Dec 2007 09:49:30 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBJHnQ5Q005767 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 Dec 2007 17:49:29 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB00H0P5IFZ900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Dec 2007 09:49:28 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB00L0B5IDKA80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Dec 2007 09:49:25 -0800 (PST) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBJHMb7a025369 for ; Wed, 19 Dec 2007 17:49:25 +0000 (GMT) Received: from mms22es.sun.com ([150.143.232.34] [150.143.232.34]) by relay22i.sun.com with ESMTP id BT-MMP-418303 for PSARC-ext@sun.com; Wed, 19 Dec 2007 17:49:25 +0000 (Z) Received: from relay25.sun.com (relay25.sun.com [192.12.251.14]) by mms22es.sun.com with ESMTP id BT-MMP-141236 for PSARC-ext@sun.com; Wed, 19 Dec 2007 17:49:24 +0000 (Z) Received: from el-out-1112.google.com ([209.85.162.177] [209.85.162.177]) by relay25i.sun.com with ESMTP id BT-MMP-10415162 for PSARC-ext@sun.com; Wed, 19 Dec 2007 17:49:24 +0000 (Z) Received: by el-out-1112.google.com with SMTP id v27so706671ele.22 for ; Wed, 19 Dec 2007 09:49:24 -0800 (PST) Received: by 10.142.232.20 with SMTP id e20mr2217964wfh.198.1198086563579; Wed, 19 Dec 2007 09:49:23 -0800 (PST) Received: by 10.142.172.15 with HTTP; Wed, 19 Dec 2007 09:49:23 -0800 (PST) Date: Wed, 19 Dec 2007 11:49:23 -0600 From: Mike Gerdts Subject: Re: manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007] In-reply-to: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> To: John Plocher Cc: PSARC-ext@sun.com Message-id: <65f8f3ad0712190949u6858c16fmb7e5b08e5b89e10d@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+/Qu8kKNhbqEMs6IyY4HUOe9Jjf5U588utMqbe5RFso=; b=EEbJUJsTenicvO+Io3xPjzZTMXYXyLNmGrFY9gvBssVsGTukD2s473GMxOq6fj57WBKhKKwRFgurGRdd81Wt5EFhapS9m7KMwq+VCMNO8HHJWShvq76CuJmWiJGuJHRFJYCSWkDNG948Z/9lAKXAPdl+w7hE/ydE9bQO2GtuBIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Hr16tn1lnqsNeJZCO2h7eKKszZj2n2MvdmSGTHl2ILSpXcZy+BHSLqcceAEADTtxxIlHEI80leMLdJULWs6E5Bq6cYkrAOraKaX44rohGZx8FvMMP3cu2ilvbmayhxHUrPWv3+dqL2SWZ3qzG32h3qvcozOBRUIdu2tioYc2YHs= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <200712130655.lBD6tY3T000089@sac.sfbay.sun.com> Status: RO Content-Length: 13096 On Dec 13, 2007 12:55 AM, John Plocher wrote: > I am ARC-sponsoring this fasttrack from Mike Gerdts, an > OpenSolaris community member. Mike is finding someone else > to be his code/putback sponsor... Based upon feedback to the previous spec that I posted (as well as a couple of my own nits), I have made a final update to the spec. The changes in this update are: - Add -p option to man(1) to display derived MANPATH. (Sect 4.1.2, 4.6.1) - Clarify -M option in man and catman man pages (Sect 4.6.1, 4.6.2) - Add examples 3 & 4 to man(1) (Sect 4.6.1) - Avoid use of word "translate" to avoid i18n confusion - Add reference to profile(4) due to use in example 4 (Sect 4.6.1) - Formatting cleanup 2. Project Summary 2.1. Project Description: When projects such as Indiana or individuals customize PATH, MANPATH is often left unset. This leads to confusion because man(1) will display the manual page for the wrong variant of a command. For example, if /usr/gnu/bin is at the front of the path, the default behavior of man(1) would most appropriately be to display a manual page from /usr/gnu/share/man rather than /usr/share/man. Similar, but slightly more complex, considerations are made for /usr/ucb and for invocations of man(1) that specify the path to the executable for which a man page is sought. 2.2. Risks and Assumptions: Traditional behavior and expectation is that /usr/share/man is the only directory searched in the case that the MANPATH environment variable is undefined. This behavior is documented in the man page for man. To allow behavior that closely resembles the legacy behavior of man(1), setting MANPATH and using name arguments that do not contain the "/" character will not invoke any PATH to MANPATH translations. 4. Technical Description: 4.1. Details: 4.1.1. Transformations The source file man.c will be enhanced to refer to PATH only in the absence of MANPATH. Each element of PATH will be transformed based into the appropriate MANPATH element based upon the following priorities: - Explicit transformation rule. For example, /usr/ucb in PATH transforms to /usr/share/man,1b. See below for details. - The parent directory of the PATH directory with /man appended. For example, /opt/VRTSvcs/bin becomes /opt/VRTSvcs/man, assuming /opt/VRTSvcs/man exists. - The parent directory of the PATH directory with /share/man appended. For example, /usr/gnu/bin becomes /usr/gnu/share/man because /usr/gnu/man does not exist. In addition and higher precedence to the above, if man is invoked referring to particular instance of a command (e.g. "man ./ls" or "man /usr/ucb/ps") the path transformation rules are applied using the directory component of the argument. In all cases where MANPATH is not defined and the path to a command is not specified /usr/share/man will be appended to MANPATH if it is not otherwise included based upon PATH transform rules. This ensures that sections other than 1* are accessible. The PATH to MANPATH transformations are as follows: PATH element MANPATH element ---------------- ------------------------------- /sbin /usr/share/man,1m /usr/sbin /usr/share/man,1m /usr/ucb /usr/share/man,1b /usr/bin /usr/share/man,1,1m,1s,1t,1c,1f /usr/xpg4/bin /usr/share/man,1 /usr/xpg6/bin /usr/share/man,1 Sections within each directory are explicitely set to ensure proper ordering of results for invocations such as "man -l", "man -a", whatis(1), etc. The transformation rules are stored in a data structure within man.c. The use of such a static mapping instead of a configuration file is chosen based upon the following: - The rules to use /man or /share/man directories will accomodate the vast majority of add-on software. - The alternative would be to create a configuration file to store the mappings. History has shown that providers of add-on software do not do a good job of modifying configuration files properly during installation and removal of software. In contrast, add-on software providers can easily create strategically placed symbolic links to trigger the automatic /man or /share/man translation. - Providing a command to update the configuration file would be significant work for a presumably very small number of edge cases. - If demand is shown, a configuration file can be added with very little rework in the future. 4.1.2. New option to print effective MANPATH To facilitate debugging and to provide a means for users to augment the derived MANPATH the -p (mnemonic: print MANPATH) option will be added. When "man -p" is invoked with no name options, the output will be suitable for use as part of a user's MANPATH environment variable. For example a user may choose to have a .profile with the following: PATH=/usr/bin:/usr/gnu/bin:/usr/sbin:/usr/ucb export PATH unset MANPATH MANPATH=`man -p`:$HOME/myman export MANPATH This provides the ability to leverage the derived MANPATH without having to sacrifice the ability to use man directories that have no associated bin directory or would otherwise be missed by standard transformation rules. 4.1.3. Prototype A prototype of this behavior (sans -p option) has been implemented and is available for review at http://cr.opensolaris.org/~mgerdts/manpath-from-path/. 4.3. In Scope: Described above. 4.4. Out of Scope: GNU utilities often times provide only stub man pages and more complete documentation using an alternative format known as "info". While translators from info to man do exist, this project does not seek to bridge this gap. 4.5. Interfaces The interface stability of man(1) is documented as "Standard" ("Comitted", in updated terminology). This project alters the documented "Search Path" behavior when MANPATH is not set. This project also extends the documented interface to man(1) such that "name" arguments that specify a fully qualified or relative path (with at least one '/' character) alter the documented "Search Path" behavior. Corresponding interface changes apply to whatis(1), catman(1M), and apropos(1) which are all hard links to man(1). 4.6. Doc Impact 4.6.1. man(1) manual page The man(1) manual page will be enhanced as follows. OPTIONS The following options are supported: . . . -M path Specifies an alternate search path for . . . one for each section. This option over- rides the MANPATH environment variable and any MANPATH derived from PATH for operands that do not have a '/' character. -p Prints the effective MANPATH. If no name operands are used, the MANPATH used to search for name operands without a '/' character is displayed in a format suitable for use as the MANPATH environment variable. If one or more name operands is used, each name operand and its associated effective MANPATH are printed. One line of output exists for each name operand. . . . OPERANDS The following operand is supported: name The name of a standard utility or a keyword. If the name contains a '/' character, the search path (See "Search Path") is altered to search only the man directory corresponding to the name argument. For example, if name is "/usr/ucb/ps" man will behave as if the MANPATH environment variable is set to /usr/share/man,1b. . . . Search Path Before searching for a given name, man constructs a list of candidate directories and sections. man searches for name in the directories specified by the MANPATH environment vari- able. If this variable is not set and the -M option is not used, a substitute MANPATH is constructed based upon the PATH environment variable. In all cases, except as described above when the name operand has a "/" character, /usr/share/man is searched. For each name operand that contains a "/" character, neither MANPATH nor PATH are used to construct the search path. . . . ENVIRONMENT VARIABLES . . . MANPATH A colon-separated list of directories; each directory can be followed by a comma-separated list of sections. If set, its value overrides the default directory search path, and man.cf as the default section search path. The -M and -s flags, in turn, override these values. The default directory search path is constructed based upon the contents of the PATH environment variable with /usr/share/man appended, as necessary. PATH The search path for commands. If MANPATH is not set, MANPATH is derived from PATH. . . . EXAMPLES . . . Example 3 Displaying the man page for /usr/ucb/ps The following example displays the man page for /usr/ucb/ps, regardless of the values of MANPATH and PATH. man /usr/ucb/ps This is an alternative to using the -l option to find all man pages for ps then selecting the one most likely to correspond to /usr/ucb/ps. Example 4 Setting shell using customized derived MANPATH The following example shows commands that can be added to profile(4) to use the MANPATH derived from PATH in addition to man directories not associated with PATH directories. PATH=/usr/bin:/usr/gnu/bin:/usr/ucb export PATH unset MANPATH MANPATH=`man -p`:$HOME/myman export MANPATH The environment created using this example will derive MANPATH once and subsequent invocations of man(1) will use the value in the MANPATH environment variable. SEE ALSO apropos(1), cat(1), col(1), dpost(1), eqn(1), more(1), nroff(1), refer(1), tbl(1), troff(1), vgrind(1), whatis(1), catman(1M), profile(4), attributes(5), environ(5), eqnchar(5), filesystem(5), man(5), sgml(5), standards(5) NOTES When deriving PATH elements to MANPATH elements, man(1) first attempts to transform /bin or /sbin to /man, as filesystem(5) indicates that add-on software should use /opt/packagename/man for manual pages. In the event that /man does not exist but /share/man does exist, /share/man will be searched. Searching /share/man is intended for legacy compatibility only. 4.6.2. catman(1M) manaul page changes The catman(1M) manual page will change as follows: DESCRIPTION . . . catman also creates the windex database file in the direc- tories specified by the MANPATH, the -M option, or MANPATH derived from PATH. The windex database file is a three . . . OPTIONS . . . -M directory Update manual pages located in the specified directory (see "Search Path" in man(1) for default). If the -M option is specified, the directory argument must not contain a `,' (comma), since a comma is used to delineate section numbers. See man(1). ENVIRONMENT VARIABLES . . . MANPATH A colon-separated list of directories; each directory can be followed by a comma-separated list of sections. If set, its value overrides the default directory search path, and man.cf as the default section search path. The -M and -s flags, in turn, override these values. The default directory search path is constructed based upon the contents of the PATH environment variable with /usr/share/man appended, as necessary. PATH The search path for commands. If MANPATH is not set, MANPATH is derived from PATH. 4.6.3. Related manual pages not changing While the behavior of whatis(1) changes in the event that MANPATH is not set or a relative or absolute command path provided, the whatis(1) man page is sufficiently vague as to not require any changes to remain accurate. whatis(1) indicates that it is equivalent to "the -f option of the man(1) command" and as such refers users to more complete documentation. Similarly, the behavior of apropos(1) changes in the event that MANPATH is not set. However, the man page for apropos(1) is sufficiently vague to as to not require any changes to remain accurate. apropos(1) indicates "apropos is actually just the -k option to the man(1) command" and as such refers users to more complete documentation. -- Mike Gerdts http://mgerdts.blogspot.com/