[3554] in testers
Re: MANPATH in cshrc
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Jun 6 14:17:58 1998
Date: Sat, 6 Jun 1998 14:17:50 -0400
From: Greg Hudson <ghudson@MIT.EDU>
To: Greg Hudson <ghudson@MIT.EDU>
Cc: testers@MIT.EDU, cfields@MIT.EDU, source-reviewers@MIT.EDU
In-Reply-To: "[3507] in testers"
A little while ago in testers, I wrote:
> In 8.1, users could use MANPATH in their .environment files. In
> 8.2, they can't. Someone remind me why this is?
Okay, here's the history of this situation. In 8.1, the way things
worked was this:
* Default cshrc sets athena_manpath
* Default cshrc sets MANPATH to $athena_manpath
* Default cshrc runs .environment
- Any add invocations add paths to both MANPATH and
athena_manpath.
* Default cshrc runs .path, where I guess a user might set
MANPATH to something including $athena_manpath. Otherwise,
MANPATH is left alone and $athena_manpath is never used.
It worked this way largely for historical reasons; for instance, the
add csh script has the following revision entry:
revision 1.24
date: 1995/02/24 06:31:47; author: cfields; state: Exp; lines: +10 -2
I had missed this bit of functionality in the old add - it adds
to MANPATH even in the .environment file. Damn.
In 8.2, we treat MANPATH similarly to PATH, the consequence being that
people can't set up MANPATH in their .environment files. Since there
is no particular value in delaying the setting of MANPATH like there
is with PATH, I would like to make the following changes ASAP to
preserve backward-compatibility as well as general sanity:
* Nuke add -M. add will always add things to MANPATH and
never use athena_manpath.
* In the default cshrc, set up MANPATH where we currently set
athena_manpath.
* Just before sourcing path, set athena_manpath to $MANPATH in
case anyone is using $athena_manpath in their .path files.
