Andreas Metzler wrote:
> Nikita V. Youshchenko <yoush@cs.msu.su> wrote:
> [...]
> > Another thing is replacing "#!/bin/sh" by "#!/bin/bash --login" in
> > /etc/kde3/kdm/Xsession (and other dm's Xsession files). This is the only
> > way I know to make login shell startup files evaluated during X logins.
> > This issue is known for ages, but it seems that people who make decisions
> > don't thing it is necessary. So this isn't likely to be fixed with debconf
> > questions.
That is one of the FAQs on the KDE site.
http://www.kde.org/documentation/faq/configure.html#id2913380
9.7. KDE (kdm) does not read my .bash_profile!".
The login managersxdm 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
This leads one to suggest what Andreas suggested:
> cat <<EOF > /etc/X11/Xsession.d/60local_userenvironment
> if [ -r /etc/profile ] ;then
> . /etc/profile
> fi
> if [ -r $HOME/.profile ] ; then
> . $HOME/.profile
> fi
> EOF
>
> This'll work for all display-managers that use the (Debian-)standard
> /etc/X11/Xsession.d/.
I originally went down this path as well. I thought the same thing
and implemented the same solution. (I put it in 95user_env so that it
was very late in the process.) But there are some problems with doing
this.
1. The Xsession is currently run in 'set -e' mode and any non-zero
return value from a command will stop the shell process. Running
in 'set -e' mode is not a normal mode for running a .profile. Many
users will execute commands which will have a non-zero return code.
This is not an error. This is just by normal script operation.
The effect is that the user cannot log in.
2. Many users will source /etc/bash_completion in their startup file.
That should be fine if they are running bash. But the Xsession
scripts are running as /bin/sh and it will not be happy parsing
bash_completion. The effect is that the user cannot log in.
3. Many users do not use .profile but instead use .bash_profile,
.zprofile, .login, etc. Which means that suddenly Xsession needs
to know about not only the filename of every viable shell but also
the syntax of every viable shell. The effect is that some users do
not get their startup environment set up while others do.
After having gone through the experience of implementing this and
having many users suddenly unable to log in I have new appreciation
for the problems the KDE developers face. If they pull in the user's
environment then problems there will prevent users from being able to
log in. The user won't be happy, even if it is their fault, and the
KDE developers will get a bug report even though it is not their
problem. (Yes I know the user can either console login or failsafe
login and fix their problem. But assumes the user knows it is their
problem. It also assumes that the user wants to add workarounds to
their startup files to control functionality between KDE login and
other logins. I know I don't want to do that myself.)
I did not originally agree with the KDE decision not to source the
user environment. I was dismayed to see that I was not getting my
environment. But I now agree with their choice not to load the user
files by default. Because without loading other files then a user can
select KDE from the login manager and log in and any problems in that
path are solely a KDE problem. If KDE works then they are in. But as
soon as you open it up to loading user files you are opening yourself
up to an unbounded list of perfectly valid user configurations which
cause problems, such as sourcing bash_completion, which will prevent
the user from logging in.
Is there no hope? Yes there is hope. I think there is a middle
ground. The answer I am happy with and have implemented is providing
a user $HOME/.xsession. Here is what I use.
#!/bin/sh
PATH=$HOME/bin:$PATH:.
exec x-session-manager
That is all of the fixup I need but it does provide the hook to do any
customization that is desired. Actually, I personally put /usr/sbin
and /sbin in the PATH too. But I don't default users to that. If
someone knows they can do it easily enough. Additionally since I use
fvwm I start it instead of kde.
#!/bin/sh
PATH=$PATH:/usr/sbin:/sbin
PATH=$HOME/bin:$PATH:.
exec fvwm
With this in place I should give a clarification of the login manager
process. Let me give a typical example. The menu selection will
allow the user to choose default, failsafe, kde. Picking default gets
you the $HOME/.xsession file if one exists. In the example above I
get my selection fvwm. If a user picks kde then the login manager
does NOT run the users's $HOME/.xsession file and instead just starts
up KDE in the way that it does now without sourcing any user
environment. The "default" menu selection is always what you want
when you want to run the $HOME/.xsession file. The "KDE" menu
selection is what you want when you suspect a problem with the user
environment and want to avoid it for debugging or other purposes.
Bob
Attachment:
pgp5DgqOxaIKh.pgp
Description: PGP signature