jms@tardis.Tymnet.COM (Joe Smith) (10/23/90)
In article <FPB.90Oct21120952@ittc.ittc.wec.com> fpb@ittc.wec.com (Frank P. Bresz) writes: >PATH IMHO is something that should be set at login time only. It should > be inherited by all subsequent shells including sunview, xterminals etc. > > Now for the question (flame request) of the day. Do people in >general agree with me that .cshrc ought to not touch the path variable or >the PATH env and just inherit it? I used to agree that setting $PATH in .login was the way to go, until I got bit by having rsh (remote shell) not doing what it was expected to. For instance, while logged in on a BSD system, I type something like "foo -a -b" and csh executes /usr/local/bar/foo. Then I type "delta !!" which is the same as "rsh delta foo -a -b". This fails if delta:.cshrc does not have a suitable "set path" command. The remote shell does not inherit the envronment variables from the invoking machine. I have moved the $path definition to .cshrc for that reason. (I have also moved the "setenv MANPATH" to be adjacent to the "set path" to remind me to change MANPATH if needed when PATH changes.) -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga 3000 speaks for me."
rickert@mp.cs.niu.edu (Neil Rickert) (10/23/90)
In article <1300@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >In article <FPB.90Oct21120952@ittc.ittc.wec.com> fpb@ittc.wec.com (Frank P. Bresz) writes: >>PATH IMHO is something that should be set at login time only. It should >> be inherited by all subsequent shells including sunview, xterminals etc. >> >> Now for the question (flame request) of the day. Do people in >>general agree with me that .cshrc ought to not touch the path variable or >>the PATH env and just inherit it? > >I used to agree that setting $PATH in .login was the way to go, until I got >bit by having rsh (remote shell) not doing what it was expected to. For My approach is to always have $HOME/bin as the first element of $PATH. My .cshrc checks this, and if true leaves the PATH, MANPATH, PAGER, PRINTER and various other environment variables alone. It just sets up any aliases, the preferred prompt, the history, etc. But if the first path item is wrong it does just about everything a good '.login' should do except set the TERM characteristics. The idea is that if I enter the account vi 'su' or some other such means, .cshrc is all there is to make things seem normal. Of course once I do it that way, I can take some of those settings out of .login -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
jik@athena.mit.edu (Jonathan I. Kamens) (10/23/90)
The default Athena .cshrc file checks for the existence of the environment variable ENV_SET. If it exists, then the environment is assumed to have been initialized properly, and no path setting etc. is done. If it doesn't exist, then the .cshrc does the necessary environment initialization. Our users log into X displays the vast majority of the time, and our X login setup doesn't even *look at* .login, so putting the initialization stuff there isn't an option. Putting it in .cshrc, however, makes it work both for X logins and for dialup logins (which do use .login, obviously :-). -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
kenc@madmax.Viewlogic.COM (Kenstir) (10/30/90)
In article <1990Oct23.045911.472@athena.mit.edu>, jik@athena.mit.edu (Jonathan I. Kamens) writes: |> Our users log into X displays the vast majority of the time, and our X login |> setup doesn't even *look at* .login, so putting the initialization stuff there |> isn't an option. Putting it in .cshrc, however, makes it work both for X |> logins and for dialup logins (which do use .login, obviously :-). It certainly is an option. Check out this in the .xsession file: #!/bin/csh # ^^^ don't use -f option # # .xsession xdm display manager startup file # # $Id: .xsession,v 1.3 90/03/27 11:10:14 kenc Exp $ # want to read .cshrc AND .login when starting a session source .login sh ~/.xinitrc This is bordering on the religious, but there is a place for the .login file. For instance: if (-e /usr/games/fortune) /usr/games/fortune doesn't want to be in the .cshrc, and resetting environment variables in the .cshrc which may have been purposefully altered is not a great idea. -- Kenneth H. Cox Viewlogic Systems, Inc. kenstir@viewlogic.com ...!harvard!cg-atla!viewlog!kenstir
perl@step.UUCP (Robert Perlberg) (10/31/90)
The way I've dealt with the problem is to make the setting of all env
variables conditional. I have created an env variable called ENVINIT
whose existence indicates that the env variables have already been
created. I use it like this:
excerpt from .cshrc:
source .envinit
excerpt from .envinit:
if($?ENVINIT != 0) exit
... various setenv's ...
setenv ENVINIT DONE
Robert Perlberg
Dean Witter Reynolds Inc., New York
{murphy | philabs | chuo}!step!perl
-- "I am not a language ... I am a free man!"