Sam Halliday wrote:
> Bob Proulx wrote:
> > By starting a login shell. Create ~/.xsession with the following:
> >
> > #!/bin/bash --login
> > exec x-session-manager # or gnome-session or whatever.
>
> AAAARG! you can't be serious!! .xsession as a LOGIN shell??
> repeat after me... X windows is not your shell!
Yes, I am very serious. Please tell me why you are so adamantly
opposed to this. (Other than it being poorly documented and
confusing. I completely agree there.)
This is by the design of the KDE folks upstream. Please see this KDE
FAQ entry.
http://www.kde.org/documentation/faq/configure.html#id2913380
9.7. KDE (kdm) does not read my .bash_profile!". The login
managers xdm and kdm do not run a login shell, so .profile,
.bash_profile, etc. are not sourced. When the user logs in,
xdm runs Xstartup as root and then Xsession as user. So the
normal practice is to add statements in Xsession to source the
user profile. Please edit your Xsession and .xsession files.
I don't particularly like the way KDM/KDE is set up in this regard.
But changes should happen upstream in order to change and improve this
situation.
> Simon, the reason you do not get your PATH set correctly is that if
> you login at a console, /etc/profile will be read because it is a
> login shell. starting X from there will inherit all your settings.
Agreed. Also don't forget that bash will read ~/.bash_profile (or
~/.profile) and commands there normally source ~/.bashrc.
> if however, you login via kdm/gdm/xdm, it is NOT a login shell, so
> /etc/profile is not read. there are good reasons for this. if you do
> not agree with these good reasons, then you can simply add the line
> . /etc/profile
> to your ~/.xsession file.
Negative. That won't get your ~/.bash_profile, or .login with csh,
sourced. You will not be getting the user's customizations from the
profile or bashrc or $ENV. You will not have the same effect as if
you logged into the text console and then started X11. Your solution
of loading the /etc/profile in a .xsession script is only half
functional.
Also your vehemence at opposing the .xsession as a login shell, and
then proposing that it simply source the /etc/profile, seems
completely inconsistent to me. Why do you oppose sourcing the file
and then propose sourcing the file! My turn for an, "AAAARG!" :-)
[Darn, I really wish you had suggested sourcing the ~/.bash_profile or
~/.bashrc files in the /etc/Xsession* script. Because that is
definitely wrong and I would have a serious rebuttal. :-) Those
scripts run as /bin/sh, the POSIX shell, and a users's ~/.bash* files
can have non-POSIX, bash specific syntax. (I am really just adding
this for other folks reading along in the discussion.) You can't
source them in the system scripts. It is more clear that does not
work when you think about ~/.login and ~/.cshrc files.]
> doing as Bob suggests and changing your X login to a login shell is
> NOT the way to solve this problem. the only reason his solution
> works is because in the process of making X a login shell,
> /etc/profile will be sourced.
You have not said anything here that indicates any problems or issues.
You have only just ranted. And you have left out that using an
xsession as a login shell also sources the user's environment files,
such as ~/.bash_profile and ~/.bashrc, correctly. Your solution does
not do that and leaves the user environment less than fully configured.
> in his solution you will be seen to be logged in twice.
What are you talking about here? Logged in twice? Please explain.
Because I think you are the one way off base here. I think you are
confused about what it means to be a login shell.
The user is not logged in twice. (What does that even mean in this
context?) The /etc/profile and ~/.bashrc files are not even sourced
twice. The environment files are sourced exactly once by the shell in
this configuration.
Please be specific. What is your complaint?
Here is the process flow using KDM.
init spawns kdm
kdm spawns bash --login ~/.xsession
bash acts upon --login, reads /etc/profile, ~/.bash_profile and
others as appropriate for a login shell. At this time the
environment is configured exactly as if you had logged into
the text console.
bash executes the ~/.xsession script which starts the window manager
The window manager inherits the environment.
window manager continues
All graphical terminal windows started by the window manager
inherit the environment.
Constrast that to the process when you log into the text console and
start X with 'xinit or 'startx.
init spawns getty
getty reads username, exec's /bin/login
/bin/login reads password, exec's user as login shell (leading '-')
'-bash' acts upon - in name and reads /etc/profile, ~/.bash_profile
and others as appropriate for a login shell.
bash from command line runs xinit (or startx which calls xinit)
xinit starts X and window manager
The window manager inherits the environment.
window manager continues
All graphical terminal windows started by the window manager
inherit the environment.
> > P.S. Does it seem like I answer this question about every other week?
>
> i hope you aren't giving this advise to everyone!
Yes. Where have you been? :-)
Bob
Attachment:
pgpXaB2gxavRH.pgp
Description: PGP signature