On Tuesday, 2011-02-01, Dotan Cohen wrote:
On Tue, Feb 1, 2011 at 21:06, Kevin Krammer kevin.kram...@gmx.at wrote:
On Tuesday, 2011-02-01, Dotan Cohen wrote:
On Tue, Feb 1, 2011 at 18:24, Kevin Krammer kevin.kram...@gmx.at 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
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.
