[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: tcsh and KDE?
From:       Cristian Tibirna <ctibirna () total ! net>
Date:       1999-06-03 22:55:58
[Download RAW message or body]


On Thu, 3 Jun 1999, Kurt Granroth wrote:

> Has anybody else had problems running KDE with tcsh as the login shell?

No problems, but proper configs to do.

> Unfortunately, it doesn't *quite* work for two of my co-workers.  There are
> two specific problems:
> 
> 1) The path doesn't seem to get properly propagated.. even when the said path
>    is specified in the user's .tcshrc

use ~/.profile instead. Put both supplemented $PATH and $KDEDIR inthere
(maybe $QTDIR and $LD_LIBRARY_PATH, depends on what you're doing).

However, for whatever reason, this didn't work for me. So, the solution I
found was to put these variables both in ~/.(t)cshrc and ~/.bashrc 

The situation is this because (I think, I didn't check!!!) KProcess and
some other ( system(1) ) are using /bin/sh as the shell of choice (even if
it shouldn't).

Anyways, this worked for me. I needed this when setting up an user for
KDE-2.0 testing. KDE-1.1 and KDE-2.0 clash very heavily otherwise.

>    For instance, the only apps that popup on initial startup are those
>    explicitely specified in 'startkde'.   All session-managed controls

when started at a prompt, 'startkde' will inherit the envir of the shell.
Try to start it from .xinitrc or .xsession (which are, by default, ran
through /bin/sh and are overridings for a console login) and you'll see
the errors.



I think this can be considered a bug (it is impossible to start KDE
without a largely skewed/configured system, a configured shell isn't
enough) but I don't know how this could be solved. I think all system
calls in KDE libs should be passed through user's shell (the one listed in
/etc/passwd)

Thanks

Cristian

[prev in list] [next in list] [prev in thread] [next in thread]