On Tuesday, 2011-02-01, Dotan Cohen wrote: > On Tue, Feb 1, 2011 at 21:06, Kevin Krammer <kevin.krammer@xxxxxx> wrote: > > On Tuesday, 2011-02-01, Dotan Cohen wrote: > >> On Tue, Feb 1, 2011 at 18:24, Kevin Krammer <kevin.krammer@xxxxxx> wrote: > >> > That never worked because e.g. .bash_profile is only read by > >> > interactive shells (see man bash) and the shell running > >> > /usr/bin/startkde is not interactive. > >> > >> Of course, .bash_profile is for bash as the name implies. But what > >> about .profile? Would it not make sense for KDE to respect that? > > > > KDE is started through a script called startkde. > > This is executed by a shell interpreter, whatever /bin/sh points to. > > > > This shell might not read .profile, bash for example only does this for > > interactive login shells. Nothing KDE can do about that. > > This is the whole point. What does KDE read to set the PATH? When a process is created, it gets the current environment of its parent process (well, the parent can pass a modified env if it chooses to). The process itself then reads the environment through system API, e.g. getenv() So if you run any program from within an interactive shell, it basically sees the environment of the shell at that point. If the shell's environment is altered afterwards, this will have no effect on the already running process. So the environment for KDE base processes is the one which they are started in. In case of a KDE workspace session, this is the environment which is present inside the startkde script. Which in turn is also running with the environment which was valid at its start. Now the script's code or the interpreter running the script can alter this environment and any process started after such a change sees the new one (remember any process started before a change sees the old one). The KDE environment extender mechanism uses that by having the startkde script source (include into itself) all files with extension .sh in any of its "env" directories. > For > instance, the path that the Krunner dialogue looks for apps? A combination of paths in $PATH and KDE specific "non-interactive-binaries" paths. See kde4-config --path exec > And why > isn't this configurable in System Settings? Maybe to avoid misunderstanding when such a change only effects KDE programs an no non-KDE programs. You could try a wish list item on bugs.kde.org for making the KDE specific search list configurable. > >> > For KDE one can additional use KDE's environment extender mechanims, > >> > i.e. putting a file (with .sh extension) into $HOME/.kde/env > >> > >> Do you know the syntax? It is not the bash syntax. Thanks. > > > > Somthing like this: > > > > export PATH=$HOME/.bin:$PATH > > Thanks, but that has no effect in, for instance $HOME/.kde/env/path.sh > which has been chmodded +x and the system restart. That should have worked. I've used that myself several times. The files in there are just read, so executable shouldn't be necessary either. Check that your setup is actually using $HOME/.kde/ some distributions patched KDE to make it something different. See kde4-config --localprefix Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
Attachment:
signature.asc
Description: This is a digitally signed message part.
___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
