[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ~/.xsession not read



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: pgpgyNXcMWAUQ.pgp
Description: PGP signature


Reply to: