Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!reef.cis.ufl.edu!ruck From: ruck@reef.cis.ufl.edu (John Ruckstuhl) Newsgroups: comp.unix.shell Subject: Make remote-shell csh act as login-shell Message-ID: <25618@uflorida.cis.ufl.EDU> Date: 28 Nov 90 08:04:36 GMT Sender: news@uflorida.cis.ufl.EDU Organization: UF CIS Dept. Lines: 43 I believe that generally speaking, for csh & tcsh, ~/.login should contain commands to set the terminal type and environment variables, and ~/.cshrc should contain commands to set aliases and shell variables. -- with the notable ?exception? that the path should be set in ~/.cshrc because remote-shells aren't login-shells (remote:~/.login isn't sourced). However, the logic of ~/.login being ignored for a remote-shell escapes me. I would want all of my environment variables set properly (not just PATH) and it seems wasteful to put it all in ~/.cshrc and reset everything with each subshell. I am tempted to test at the beginning of ~/.cshrc whether or not an environment variable is set which indicates that ~/.login has been sourced (the environment variable would be set within ~/.login), and if not, source it. Also, I would test at the beginning of ~/.login whether or not ~/.login has already been sourced, and avoid sourcing it again. For example: % head -1 ~/.cshrc if (! $?LOGIN) source ~/.login and % head -2 ~/.login if ($?LOGIN) exit setenv LOGIN Maybe DEPTH would be a better choice of environment variable -- perhaps I would increment it during each ~/.cshrc if I wanted to know how deep in subshells I was. Is this sane? Do others do this? If you think that I am hopelessly confused, so that you cannot easily compose a reply which corrects me, but are willing to explain to me by telephone, please email your telephone number to me. I don't think this is relevant, but we run SunOS 4.1 on SS1+'s. Thank you for your comments, ruck -- John R Ruckstuhl, Jr University of Florida ruck@cis.ufl.edu, uflorida!ruck