jfjr@mitre-bedford.ARPA (Jerome Freedman) (03/24/88)
Excuse my ignorance but this is a chance to nibble away at it. Could someone explain to me, for 4.2 especially the Sun version exactly how and in what order the .login and .cshrc files are read (executed?). How are these files handled when you initiate Suntools? How are they handled if you "su" to another account? How are they handled in an rlogin? How about them Celtics? Thank you Jerry Freedman, Jr "Love is staying up all night jfjr@mitre-bedford.arpa with a sick child, (617)271-4563 or a healthy adult"
aland@infmx.UUCP (alan denney) (03/26/88)
Sorry if this went out before, I had an error flash by in the middle of the post attempt... In article <27717@linus.UUCP>, jfjr@mitre-bedford.ARPA (Jerome Freedman) writes: > > Excuse my ignorance but this is a chance to nibble away at > it. Could someone explain to me, for 4.2 especially the Sun > version exactly how and in what order the .login and .cshrc > files are read (executed?). How are these files handled when > you initiate Suntools? How are they handled if you "su" to > another account? How are they handled in an rlogin? How > about them Celtics? > > Thank you > > Jerry Freedman, Jr "Love is staying up all night > jfjr@mitre-bedford.arpa with a sick child, > (617)271-4563 or a healthy adult" You may have been "RTFM"d for this, but I have seen a lot of people get confused about this, so don't feel too bad. (Public note: the man pages for "su" and "csh" appear to disagree). The .cshrc file is read and executed (if possible) upon every csh fireup, INCLUDING the login shell. The .login is read and executed AFTER the .cshrc. If either file is not owned by the person logging in, it is not executed. (Of course, root can use /usr/5bin/chown to change ownership for a new user.) Of course, things get confusing if the user does something silly, like having a "source .login" command within the .cshrc (which I have seen more than a few times ;-]). > How are these files handled when you initiate Suntools? Sorry, over my lowly head.. > How are they handled if you "su" to another account? When using "su": if the default shell for the user su'd to is csh, that user's .cshrc is executed. If "su - usernm" is used, the .login is also executed (again, AFTER the .cshrc). The man page for "su" states (quoted without permission, please forgive me, Sun): | SYNOPSIS | su [ - ] [ username ] [ -c command ] [ -f ] | | OPTIONS | - The - flag performs a complete login. That is, it | moves to the home directory, reads the .login file, and | reads the .cshrc file for the new user-ID to configure | the new shell. | | Sun Release 3.4 Last change: 17 February 1986 1 This is a good source of confusion; the .cshrc is executed FIRST. I would interpret this passage to claim that the .login goes first. (Any Sun documentation people out there?) > How are they handled in an rlogin? Just the same as a direct login. I believe that "rsh" invokes the .cshrc file (only) of the user on the remote machine. > How about them Celtics? How about them Giants! -- Alan S. Denney | {pyramid|uunet}!infmx!aland Informix Software, Inc. | CAUTION: This terminal makes wide right turns! Disclaimer: These opinions are mine alone. If I am caught or killed, the secretary will disavow any knowledge of my actions.
karish@denali.UUCP (karish) (03/27/88)
In article <111@infmx.UUCP> aland@infmx.UUCP (alan denney) writes: >In article <27717@linus.UUCP>, jfjr@mitre-bedford.ARPA (Jerome Freedman) writes: >> Excuse my ignorance but this is a chance to nibble away at >> it. Could someone explain to me, for 4.2 especially the Sun >> version exactly how and in what order the .login and .cshrc >> files are read (executed?). How are these files handled when >> you initiate Suntools? How are they handled if you "su" to >> another account? > >The .cshrc file is read and executed (if possible) upon every csh >fireup, INCLUDING the login shell. The .login is read and executed >AFTER the .cshrc. If either file is not owned by the person logging >in, it is not executed. (Of course, root can use /usr/5bin/chown to >change ownership for a new user.) > >> How are they handled if you "su" to another account? > >When using "su": if the default shell for the user su'd to is csh, >that user's .cshrc is executed. Csh behaves differently on some SysV systems. AIX doesn't source .cshrc on an su. This causes me no end of annoyance and confusion when I maintain workstations whose users insist on making root's default shell csh (yes, I know how to fix this with an alias). AIX also will refuse a login if the user does not own his/her .cshrc, .login, or .profile. Chuck
gandalf@csli.STANFORD.EDU (Juergen Wagner) (03/27/88)
In article <111@infmx.UUCP> aland@infmx.UUCP (alan denney) writes: >... >You may have been "RTFM"d for this, but I have seen a lot of people get Actually, if you don't have some experience with UNIX it is a case of RTMVC (Read The Manual Very Carefully) :-) :-). >... (Public note: the man >pages for "su" and "csh" appear to disagree). The csh(1) man page says that .cshrc is executed first, then .login if the newly created shell is a login shell. The su(1) man page is inconsistent. The login(1) manpage is correct. The rlogin man page doesn't mention anything about that matter at all. >... >Of course, things get confusing if the user does something silly, >like having a "source .login" command within the .cshrc (which I >have seen more than a few times ;-]). Source'ing .login in .cshrc should not do anything bad if .login is written properly (e.g. make uses of stty/biff/etc. conditional on interactiveness). Yet, it doesn't make any sense, either :-). >> How are these files handled when you initiate Suntools? When you startup Suntools, this is typically handled in the .login. The point is that .cshrc is executed every time a csh starts (e.g. when FranzLISP starts its assembler). Put in this file everything you'd like to have in every csh. Put into .login everything you need in the login shell, and all environment variables not needed in all cshs. Also, terminal setup (tset, stty, biff, ...) should be in .login because in .cshrc it doesn't make sense. So, typically .login runs Suntools. Each cmdtool/vt100tool/ shelltool starts a new csh, i.e. executes .cshrc but *BUT* no .login. >> How are they handled in an rlogin? Exactly same as normal login. The csh starts and reads .cshrc, notices that it is a login shell, and reads .login. All this happens, of course, on the remote machine. rsh (BSD) and remsh (HPUX) invoke only .cshrc. >> How about them Celtics? Sounds interesting. What does it mean? -- Juergen Wagner, gandalf@csli.stanford.edu Center for the Study of Language and Information (CSLI), Stanford CA
gandalf@csli.STANFORD.EDU (Juergen Wagner) (03/27/88)
In article <27@denali.UUCP> crkarish@stanford.edu (Chuck Karish) writes: >... >Csh behaves differently on some SysV systems. AIX doesn't source >.cshrc on an su. Yes, HPUX doesn't read cshrc, either. Or, I should say - it reads your .cshrc, and doesn't care about the new user's .cshrc. It even takes HOME and the other environment variables just from the parent process, so simple "cd" brings you back into *YOUR* home directory, not into the directory of the user to su'ed to. "su - user" does read .cshrc *AND* .login under HPUX. --Juergen -- Juergen Wagner, gandalf@csli.stanford.edu Center for the Study of Language and Information (CSLI), Stanford CA
gore@eecs.nwu.edu (Jacob Gore) (03/28/88)
/ comp.unix.questions / gandalf@csli.STANFORD.EDU (Juergen Wagner) / Mar 27, 1988 / >The point is that .cshrc is executed every time a csh starts ([...]). >Put in this file everything you'd like to have in every csh. Put into >.login everything you need in the login shell, and all environment variables >not needed in all cshs. Also, terminal setup (tset, stty, biff, ...) should >be in .login because in .cshrc it doesn't make sense. I find that this sequence (.cshrc first, then .login) is the opposite of what I want. That is because I want to set up environment variables just once -- in .login, -- and I want them to be usable from .cshrc in each shell I use, including the login shell. So, I just reverse them: .login (abbridged): setenv EDITOR /usr/local/bin/mg unset autologout set prompt="%m"; setenv SHOSTNAME $prompt biff y setenv HAVELOGGEDIN yes source ~/.tcshrc .tcshrc (abbridged): if (${?HAVELOGGEDIN}) then source ~/.customrc set prompt="`whoami`@${SHOSTNAME}> " set history=50 savehist=20 endif This way, when the login shell starts up, .tcshrc skips itself (because HAVELOGGEDIN is not defined), .login is run, and it runs .tcshrc when it's finished. On subsequent shells, just the .tcshrc is run, and it executes normally. Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,gargoyle,ihnp4}!nucsrl!gore
mike@ists (Mike Clarkson) (03/29/88)
In article <3126@csli.STANFORD.EDU>, gandalf@csli.STANFORD.EDU (Juergen Wagner) writes: | In article <27@denali.UUCP| crkarish@stanford.edu (Chuck Karish) writes: | >Csh behaves differently on some SysV systems. AIX doesn't source | >.cshrc on an su. | | Yes, HPUX doesn't read cshrc, either. Or, I should say - it reads your | .cshrc, and doesn't care about the new user's .cshrc. It even takes | HOME and the other environment variables just from the parent process, | so simple "cd" brings you back into *YOUR* home directory, not into | the directory of the user to su'ed to. Same with most SysV's. But and interesting bsd feature (?) is that it will only source the .login if the user logging in owns that file. For example, if I'm logging in as mike, and ~mike/.login is owned by root, the ~mike/.login will not be executed. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science York University, North York, Ontario, CANADA M3J 1P3 (416) 736-5611
joey@tessi.UUCP (Joe Pruett) (03/30/88)
As has been mentioned, rsh does not source your .login file. This is
quite obnoxious when you set your path in your .login (where it belongs
so that each shell isn't hashing your path more than necessary).
"rsh hostname something_in_usr_local_bin" will get you a "Command not
found" message. To get around this problem I've renamed .login to
.mylogin and created a new environ variable that let's my .cshrc know
if my .mylogin has been run, if not then .cshrc sources .mylogin.
In .cshrc:
if ( ! ${?MYLOGIN} ) source ~/.mylogin
.
.
In .mylogin:
set path = ( . . . )
.
.
setenv MYLOGIN ""
This could be cleaned up a little bit (move the env stuff into
.cshrc inside the if MYLOGIN line), but inertia can be quite
overwhelming.
--
Joe Pruett ...!tektronix!tessi!joeyekrell@hector.UUCP (Eduardo Krell) (03/31/88)
Some people are confusing "su" with "su -". According to the man page,
"The - option simulates a full login" (in 4.3 BSD).
The System V man page is less cryptic:
If the first argument to su
is a -, the environment will be changed to what would be
expected if the user actually logged in as the specified
user. This is done by invoking the program used as the
shell with an arg0 value whose first character is -, thus
causing first the system's profile (/etc/profile) and then
the specified user's profile (.profile in the new HOME
directory) to be executed. Otherwise, the environment is
passed along with the possible exception of $PATH, which is
set to /bin:/etc:/usr/bin for root.
Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ
UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell@ulysses.att.comkurt@hi.unm.edu (Kurt Zeilenga) (04/01/88)
In article <453@q7.tessi.UUCP> joey@tessi.UUCP (Joe Pruett) writes: >As has been mentioned, rsh does not source your .login file. This is >quite obnoxious when you set your path in your .login (where it belongs It would really obnoxious if it did source your .login. >so that each shell isn't hashing your path more than necessary). What? I assume you don't want it to be "hasing your path more than necessary" for speed. You need to set your path once per shell to make sure it's right. You don't want to rely on it being correct in the environment. >"rsh hostname something_in_usr_local_bin" will get you a "Command not >found" message. To get around this problem I've renamed .login to >.mylogin and created a new environ variable that let's my .cshrc know >if my .mylogin has been run, if not then .cshrc sources .mylogin. > >In .cshrc: >if ( ! ${?MYLOGIN} ) source ~/.mylogin So you source a script. Now, that makes a lot of sense and I am sure would be much faster than just setting your path .cshrc. If I am doing a rsh, I won't want it to check for mail, news, etc, tset my terminal, etc. Yuk! >This could be cleaned up a little bit (move the env stuff into >.cshrc inside the if MYLOGIN line), but inertia can be quite >overwhelming. >-- >Joe Pruett ...!tektronix!tessi!joey Why don't you put things you want done once per shell in .cshrc and things you want done once per login in .login. If you have stuff that you don't want done when you are doing rsh's (for speed or other reasons) then do a "if ($?prompt) then" or something in your .cshrc. If you want to put something into your .cshrc to do something once per .login, because of some order dependence which you might have, just check for the non-existance of an environment variable you set in your .login (like your MYLOGIN). -- Kurt (zeilenga@hc.dspo.gov)
jerry@oliveb.olivetti.com (Jerry Aguirre) (04/07/88)
In article <453@q7.tessi.UUCP> joey@tessi.UUCP (Joe Pruett) writes: >As has been mentioned, rsh does not source your .login file. This is >quite obnoxious when you set your path in your .login (where it belongs >so that each shell isn't hashing your path more than necessary). I disagree. My path is set in my .cshrc. The setting is conditional on and environment variable so that sub shells don't reset it. It looks like: if (! $?MAIL) then setenv MAIL /usr/spool/mail/jerry set path=(. ~jerry/bin /usr/ucb /bin /usr/bin) endif This is a lot simpler than inventing new files to be sourced. I bet it is faster too. (I don't remember what program wanted a "MAIL" variable, any environment variable not set at login time would do.) People should also be aware that setting the prompt in their .cshrc should also be conditional. They should use something like: if ($?prompt) then set histchars=\\^ set prompt="\> " history=60 mail=(120 /usr/spool/mail/$USER) alias 1 %1 ... endif Anything dealing with prompts, history, or any other "interactive" variable should be executed only for interactive logins. My opinion is that almost all aliases should also be conditional. An alias is used primarily to save typing and that doesn't apply to non-interactive usage.