Request for help with kdm & environment variables

Robert P. Goldman rpgoldman at
Sun Oct 12 20:38:44 BST 2003

>>>>> "JRT" == James Richard Tyrer <tyrerj at> writes:

    JRT> Robert P. Goldman wrote:
    >> I'm trying to figure out how to get my environment variables in effect
    >> in applications that run under KDE (on linux).  I use tcsh as my
    >> shell.

    JRT> I will assume that you are using KDM to start KDE since this problem 
    JRT> doesn't occur when you use: "startx" from a console.


    JRT> The problem is that the shell is NOT doing a login.  I am only familiar 
    JRT> with Bash, but except for the file names, it should be the same.  You have 
    JRT> two files which need to be run at login.  According to the Fine Man page at 
    JRT> login it first executes: "/etc/csh.cshrc" & "/etc/csh.login" & and then 
    JRT> "~/.tcshrc".  A non login should execute: "/etc/csh.cshrc" and then 
    JRT> "~/.tcshrc".  This means that the script: "/etc/csh.login" is the one that 
    JRT> is login specific.  This is different from Bash which also runs a user 
    JRT> login script.  However, it is possible that your system scrip: 
    JRT> "/etc/csh.login" might also source a use script which is run at login.

    JRT> You made a: "~/.xsession" script.  There is an important thing to remember 
    JRT> here.  These scripts are not magic, something must run them.  KDM ONLY 
    JRT> executes the "Xsession" script.  What ever else happens is totally 
    JRT> determined by that script.  If it sources: "~/.xsession" it will run, if 
    JRT> not then it won't.  If it sources your: "/etc/csh.login" it runs otherwise 
    JRT> it isn't.

Thanks.  For lack of a man page for kdm, I've been trying to
generalize from the behavior of xdm.

But, AFAICT, kdm is not executing the Xsession script, either.
Here's my ~/Xsession:


#!/bin/tcsh -l

/bin/date +"%c" >> /home/rpg/Xsession.log

echo "interpreting Xsession file." >> /home/rpg/Xsession.log

source /home/rpg/.tcshrc

echo "done interpreting Xsession file." >> /home/rpg/Xsession.log


It's executable as it's supposed to be:

ls -l ~/Xsession
-rwxr--r--    1 rpg      rpg           212 Oct 12 08:33 /home/rpg/Xsession

But nothing's written to Xsession.log:

ls -l /home/rpg/Xsession.log                       
ls: /home/rpg/Xsession.log: No such file or directory

I have tried just executing the Xsession file from the command line,
and it executes fine, and writes to the log file, so there doesn't
seem to be anything wrong with the script per se.

Note that I'm running Mandrake, so I'm running mdkkdm instead of kdm.
But I've looked at the source, and AFAICT, mdkkdm runs Xsession, too.

    JRT> You didn't say which script is supposed to be setting your environment 
    JRT> variables and when you need them to go into effect.

It's the ~/.tcshrc that should be setting the environment variables.
I want them into effect so that when I invoke a program from the KDE
"K" menu, that program will get the right environment (otherwise, for
example, Crossover Office doesn't work right).  Right now I have to
just avoid the K menu and do everything from the shell.  Since I
touch-type, this isn't a huge practical issue, but it bothers the heck
out of me, aesthetically.

    JRT> With Bash, one solution that usually works is to make the: "Xsession" 
    JRT> script a login script.  To do that for 'tcsh', change the first line to:

    JRT> 	#!/bin/tcsh -

    JRT> or something like that.

    JRT> Note, if you: "Xsession" script is being run by: "/bin/sh" then it isn't 
    JRT> going to run the 'tcsh' scripts, it is going to run the Bash ones.  You 
    JRT> would probably know that since I think you would have needed to write a 
    JRT> new: "Xsession" script to use 'tcsh'.

I think what I show above should be right (BTW, the -l is the
equivalent of - for bash --- makes this a login shell).

If anyone could suggest how to debug this, I'd be very grateful.  I
wish I could convince (mdk)kdm to log somewhere what it's trying to
do, so I could see if it's trying to load my dang file and fails, or

This message is from the kde mailing list.
Account management:
More info:

More information about the kde mailing list