Matthijs Melchior wrote: > I think this is correct behaviour, systems like Kde and Gnome have their > own session manager to start anything you want.... > [/usr/bin/gnome-session uses ~/.gnomerc for customizations and logs > everything in ~/.gnome-errors. Expect kde to have similar setup] I faced a similar issue with kde recently and this is what my research found. 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 think I understand why they did that. This is my conjecture. As soon as you open up the system kde startup to running user scripts there are now a zillion reasons why kde might not start up all pointing to the user files being buggy. It is very common for a user to have a problem in their .profile. And when that happens, blupt!, you are back to the login screen. CNTL-ALT-F2 and failsafe modes are your friends in that case. Also, those scripts are run with 'set -e' which definitely requires special script handling. I don't know why people love that mode so much but trying to run a user .profile and also trying to run in -e mode is insane. But let's assume you turn that off for running the user scripts. Then you have to handle different shells. Do you run in /bin/sh mode? Makes sense, that is standard. But then bash users can't load /etc/bash_completion for one example. Why should it? It is a bash specific mode not /bin/sh. And how do you handle users with ksh, zsh and other similar shells? So I think they took the road of the system startup only running system scripts by default just so that they could reliably start up always. No complaints from the clueless that it does not start. And truly I think many use it for a simple newbie environment for just the reasons that it is very reliable. And by pushing the problem off to the local admin they avoid the problem of shells and other such trouble entirely. But meanwhile I still am not happy with the fact that it leads to only local, ad-hoc, non-standard solutions to the problem. I still need to deal with the problem on my site. I have dropped a new script in place in Xsession.d/95 that effectively does this. set +e test -f /etc/profile && . /etc/profile test -f $HOME/.Xprofile && . $HOME/.Xprofile And then I deal with users who complain that it is not loading their profiles and then after they try .Xprofile they complain that they can no longer log into the machine because of errors in their files. Sigh. That is when I started to understand at least one reason why it was not done by default. Just my two cents... Bob
Attachment:
pgpDFERSvzkgo.pgp
Description: PGP signature