When a bash user logs into the Linux console, environment variables are
set by .bash_profile.  However, when that user invokes startx with
appropriate .xsession file to start KDE, those
environment variables are dropped for what I assume are good reasons.
The older web advice to work around this startx "feature" is to source
..bash_profile from .xsession, before invoking startkde e.g.,

#!/bin/sh
~/.bash_profile
startkde

(For clarity I have dropped other things I do in .xsession such as
run xmodmap since most users won't want to do that.)

That solution has worked for years for me through many Debian and KDE
versions, but quit working with Debian squeeze because dash has become
the default shell, and that chokes on some of the obvious bashisms
that are necessarily part of my .bash_profile script.

None of the modern web advice I found on this issue works for Debian.
For example, I tried replacing

#!/bin/sh by #!/bin/bash (or even #!/bin/sh --login as recommended one
place) to no avail.  I presume those didn't work because the scripts
invoked by startx source the ~/.xsession file rather than executing
it like a shell script with the result that the first bang line is
treated as a comment.

Here is the only solution that appears to work for Debian squeeze.

#!/bin/sh
bash --login startkde

This works because dash can execute "bash --login startkde" because
that command obviously does not have any bashisms, and "bash --login
startkde" automatically sources .bash_profile before running startkde
because of the --login option.

I assume this bash --login trick is given somewhere on the web,
but I never found it so I had to discover this for myself. I
would like to see it strongly propagated to Debian users (at least
through this wishlist bug report, but hopefully also through proper
documentation) because it works perfectly for me and because there is
so much incorrect advice out there on how to solve this issue.

<aside>
For example, the Ubuntu collected wisdom as evidenced in their forums
on this issue is there is no solution so the only alternative is to
abandon use of .bash_profile altogether and set environment variables
in .bashrc. That is really bad advice since all that setting of
environment variables for each shell script called by a previous shell
script slows everything down and also causes very long repeated
results for, e.g., PATH since simple commands like

PATH=whatever:$PATH

in .bashrc eventually gets turned into

PATH=whatever:whatever:whatever:whatever:...:whatever:$PATH

(I actually saw someone achieve PATH overflow by the Bourne shell
equivalent of this mistake in my early Unix days.)
</aside>

Until I found the above trick, I was locked out of KDE for two days
during an upgrade from Lenny to Squeeze which is why I think it
is important to propagate this "bash --login" solution to the issue.

I was also locked out of KDE on a different machine that was set up
as an X-terminal to run KDE clients on the updated machine until
I used the above trick.  So I know the above trick works both
with (direct) startx and for an X-terminal managed by xdm.

Caveats:

I. Although the above trick works fine with xdm, I don't know whether
it also works with kdm or gdm, and I hope somebody tests those display
managers and adds their remarks here.


II. There is some complex interaction with KDE going on here because
the trick is not necessary if you are using e.g., the light-weight
fvwm desktop instead of KDE.  In other words,  if your .xsession reads

#!/bin/sh
fvwm

the xterms you obtain in the fvwm environment automatically have the correct
environment variables set from .bash_profile.

I assume GNOME acts like KDE rather than fvwm so that the "bash
--login" trick will be necessary to start GNOME as well.  But someone with
GNOME installed should comment on that.

Alan W. Irwin