The shell

[Namit]

Please forgive my ignorance, but I'm getting a strange problem.

When I do echo $SHELL ( or do a ps ) I see a csh, but still the environments set in the '.cshrc' don't work. Then, when I do csh, I can see my environment set ( probably the .cshrc isn't read when I first login, and is read only when I do a csh )

What is going wrong here ?

[Jeff Schussele]

Hi Namit,

Few things to check:

1) Make sure that csh is your defined shell in the passwd file & that the path to csh is correct - /usr/bin/csh

2) Check permissions on your home dir - should be owned by you & the group should be your primary group

3) Check the ownership & perms on the .cshrc file itself - should be 444

HTH,
Jeff

[Ted Ellis_2]

take a look at the password file and see what shell is set for that user... it will be the last item on the line for this user.

is it /usr/bin/csh? or another shell

also check /etc/profile, /.login and .profile and look for any forced entries resetting the SHELL.



If the .login and .profile is clear and /etc/passwd has /usr/bin/csh, you should be ok. Update the passwd file if necessary to show /usr/bin/csh.

Ted

[Darrell Allen]

Hi,

As others say, verify the shell specified for you in /etc/passwd.

If if is csh, check to see if you have something in .cshrc or .login in your home directory that switches you to a different shell. It could be something like:
exec /usr/bin/sh

Darrell

[Leif Halvarsson_2]

Hi
Are you running CDE. If so, try with uncommenting the line:

#DTSOURCEPROFILE=true
in the file <$HOME>/.dtprofile

[Namit]

Thanks for the help guys, but I've checked the .login and .cshrc files, and there's nothing about SHELL. Even the passwd file is fine.

I changed the group to primary, that didn't help.

What I want to know is, if I see csh when I do a ps, doesn't that always mean that I am running a cshell ? SHELL might have been changes, but ps should tell me the current shell running, right ?

[Ted Ellis_2]

running ps will show the processes associated with the current terminal, so csh would indicate that the terminal you are on is running a csh.

Did you note one of the later entries? Are you logging in via CDE? Or xterm/telnet?

[Martin Johnson]

Yes, it should show you the shell you are running but it doesn't necessarily tell you the path of the shell (you may have more than one copy of a shell).

How are you logging into the system? Depending upon how you are logging into the system, .cshrc may or may not be executed. For example, logging in through CDE will not execute .cshrc unless you change .dtprofile.

HTH
Marty

[Ted Ellis_2]

also.. instead of looking for SHELL in the target files mentioned.. just check for csh

curious to see if maybe /usr/bin/csh... possibly with the -f option may be tucked in their somewhere...

Ted

[Namit]

Yeah, in CDE, I've to telnet to that machine. And in fact, I don't see this problem on my own machine.

Can this solve the issue ?

BTW I did try uncommenting, but that didn't help, and $HOME/.dt/startlog also doesn't report any problem ( as suggested in .dtprofile )

[Darrell Allen]

Yes, ps will show the shell you are running. Consider the following:

$ echo $SHELL
/usr/bin/sh
$ csh
% echo $SHELL
/usr/bin/sh
% ps -f
UID PID PPID C STIME TTY TIME COMMAND
darrell 15130 219 0 16:49:07 pts/3 0:00 csh
darrell 219 213 0 Sep 27 pts/3 0:00 -sh
darrell 15131 15130 5 16:49:11 pts/3 0:00 ps -f
% echo $$
15130
%

My login shell is a posix shell. After echo $SHELL, I switched to csh. Notice $SHELL did not change. "ps -f" shows both csh and sh but you can see that sh is the parent process for the csh.

So to answer your question, yes, if you see csh you are running a cshell. It may not be your current shell though. To see which is your current shell, "echo $$" and match it to the ps output. From above, you see the current shell is 15130, the csh process.

Darrell

[Namit]

So Allen, On echo $$ I get 2852 as my PID, which is for csh

[Namit]

And Martin,

I do a telnet or rlogin from my dtterm or xterm ( since this is not my primary machine ). What do I need to do to see if .cshrc is run or not ?

[Ted Ellis_2]

how about inserting a line to maybe read the /etc/motd... insert something that will make it obvious the .cshrc is being parsed... echo a string of some sort...

[Darrell Allen]

Well, it appears your current shell is csh.

Did you try Leif's suggestion? It was to uncomment the line:

#DTSOURCEPROFILE=true
in the file <$HOME>/.dtprofile

I don't remember if you need to close your CDE session and restart it.

Darrell

[Namit]

I mean, I know .cshrc is not run the first time ( unless I do a csh ) since if I echo the PATH, this doesn't include the ones I set in .cshrc, only after a csh do I get to see those paths.

[Darrell Allen]

I think I mis-read your comments above. You run CDE, open a telnet session to a remote system where you experience this problem. If so, I don't believe DTSOURCPROFILE is going to help.

Darrell

[Darrell Allen]

To see if .cshrc is being executed, simply add a line to it that says "echo This is .cshrc".

You can also put a line in .login to see if it's being executed.

Darrell

[Namit]

inondation de l'information
( Flood of information )

... for my little brain today :-)

Anyway, Allen I restarted CDE as well, but in vain :-(

[Namit]

Now you guys would solve this problem I guess. This must be some silly problem now.

I found that actually .cshrc is running the first time also. If I do echo for other variables, or do echo "Hello World" in .cshrc, that works. The problem is only with PATH.

# ClearCase paths
setenv PATH /usr/atria/bin:$PATH

setenv CLEARCASE_BLD_UMASK 2

echo PATH doesn't show me the new path, but echo CLEARCASE... does show me 2 !

[Darrell Allen]

Are you doing "echo PATH"? If you, you should do "echo $PATH".

I didn't know if you had simply made a typo or not.

Darrell

[Namit]

NO :-(

And it's not only about not being able to see the PATH, I can't use that path unless I manually do a csh :-(

[Darrell Allen · Accepted solution]

Do you have .login in your home directory? Does it also set PATH? If so, it will over-ride what is set in .cshrc since it runs afterwards.

Do either .cshrc or .login source other scripts that could be re-setting you PATH?

I'm guessing .login re-sets your PATH or sources something else that does. It is not executed when you run "csh". It only runs when you login.

Darrell

[Ted Ellis_2]

can you post your .cshrc?

[Namit]

Great minds really think alike :-)

This is what I felt when I found that PATH was not getting set the first time only. Now when I set the path in .corprc, I don't have any problem.

Thanks everyone ( specially Allen And Ellis ) ... I can get back to work now.

Just one more question though, since we are not supposed to modify the .login file ( and use .corprc instead ), and .login sets the PATH variable, doesn't that mean that everytime someone sets the PATH, he'd have this problem ? Also, can I do something in .login which doesn't overwrite the previous PATH set in .cshrc ? I tried doing :

set path=( $path /bin /usr/bin /usr/ucb )

in the .login, but that didn't help