Andreas Metzler wrote: > Nikita V. Youshchenko <[EMAIL PROTECTED]> 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
pgpEOHjgbU7WD.pgp
Description: PGP signature
