ksh93 not reading $HOME/.profile!!!

[Max_4]

Hi folks!

I am kind of frustrated with this... I just downloaded and installed
the rpm for ksh93 from this link:
http://rpmfind.net//linux/RPM/contrib/libc6/i386/ksh93-2000.10.31.0-1.i386.html

I am running under Red Hat 8.0. and KDE. The thing is that I created a
user
#useradd -s /bin/ksh student

and I created under ~student:

.profile
VISUAL=emacs
export VISUAL

then I logged out and logged back in as user 'student'
and did:

$set | grep VI

and NOTHING was displayed!!!!!

The curious thing is that it works when I do as 'student':

$su - student
...
$set | grep VI
VISUAL=emacs

WHY could this be happening!!! What else do I need to make it work?

Thank you very much in advance!

Max

[Max_4]

Now I think ksh93 is indeed reading .profile, the problem was that the terminal was forking a normal subshell not a
login shell.

I haven't found yet the way of how to fix this for gnome. But I tried
adding --ls to the options for starting 'konsole' and it worked!

What still bothers me is WHY when I log in graphically gdm doesn't
start a login shell like IT SHOULD. I mean when I log in graphically
gdm should know which my login shell is, and read my .profile at that
very first time, so that when I start any subshell I will have my
.profile env variables already set.

The curious thing is that it does indeed read .bash_profile when
logging in graphically, when the login shell is bash not ksh!

I wonder if there's something I can set to make it work correctly.?

Thanks a lot in advance,

Max

[Steven E. Protter]

Red Hat usually defaults to the .bash_profile

Please check /etc/passwd for the users shell and that file. This may explain any unusual behavior.

SEP

[Mark Grant]

Max,

Well, terminals shouldn't be reading .profile when started by gdm and it "is the way of things". If bash does do it for you, it needs a slap on the wrist.

When you get Gnome up, it has arrived courtesy of your login shell, starting a new terminal is starting a sub-shell and hence, no .profile.

A way around this is to edit the xresources file for which ever terminal you use and specify that it should default to a "login" shell in there.

[Max_4]

Mark thanks for the input. As a matter of fact, I agree with you regarding a subshell (subshells do not read .profile).

But GDM, I mean the initial graphical login screen, *should* read .profile if your login shell is /bin/ksh. As I said in the case of having a user with login shell bash, GDM does read .bash_profile at login time. Of course when you fork a terminal it does only read .bashrc, as one would expect it to be.

The situation is quite different when the user's login shell is /bin/ksh. GDM _initial login_ screen does not read .profile NOT even once. I think this is wrong because at initial login time (not subshells) ksh should read .profile.

The issue doesn't have to do with terminals reading .profile, for that _one can add_ --ls in the command that creates the terminal, for example to force it to read .profile or .bash_profile/.profile anytime I span a subshell via a terminal. But this is not good. The issue has to do with the Initial GDM login, that doesn't want to read .profile in case of /bin/ksh.

I don't know, possibly I have to change something in gdm.conf, but I don't know.

Thanks!

[Mark Grant]

Hello Manuel,

I guess there is room for disagreement here but I still think bash is wrong. I don't think a GUI should read through .profile by default. Many people have interactive commands in their .profile which can cause lots of nasty things to happen if a GUI is running it. On HPUX the GUI allows you to specifically set wether to read .profile or not and this, for me, is borderline usage :)

However, on a linux box I guess the distinction is not so clear.

However, if you want to achieve this thing, why not just find your system wide Xsession file (which I assume GDM runs) and get it to source $HOME/.profile in there with ". $HOME/.profile". This is the beauty of unix.