KDE menus (Lancelot, Kmenu, Krunner) not respecting PATH?

[James Richard Tyrer]

Boyd Stephen Smith Jr. wrote:
> In <4A032D67.3080703 at acm.org>, James Richard Tyrer wrote:
>> Boyd Stephen Smith Jr. wrote:
>>> Yes, I think some distributions misguidedly source .bash_profile and/or
>>> .bashrc at odd times.
>> The "Xsession" script needs to source the proper profile script for the
>> shell that you are using (.bash_profile for Bash).  It can do this
>> either explicitly or implicitly by being a login script.
> 
> No, because an Xsession is not a bash login.  It is an X login.  ~/.xprofile 
> and /etc/xprofile would be appropriate, ~/.bash_profile is not.  Just like 
> tcsh and zsh don't read .bash_profile (or bash vice-versa), your Xsession 
> doesn't (necessarily) *have* a login shell (it is the login process and 
> doesn't have to be a shell script) so it should not read your .bash_profile.
> 
In general, the xprofile login shell scripts are to add additional 
things that are used for X sessions that are not used for console sessions.

Perhaps you are being confused by the name of the user login profile 
script.  The reason that it is called ".bash_profile" is that the user 
profile script must be compatible with the shell program that will read 
it.  It is NOT the profile script for a Bash session, but rather the 
user profile script that can be executed by the Bash shell.

>>> Sourcing .bash_profile (or .profile) is a bit dangerous, as they are
>>> allowed to be fully interactive.  On some systems, I have my
>>> .bash_profile prompt me and depending on my response possibly 'exec
>>> screen'.
>> If you read the fine man page for BASH, you will see that
>> ".bash_profile" is the script for login.  It should not be interactive.
> 
> It is sourced for interactive bash logins.  It is allowed to be interactive 
> itself -- even something that using 'exec' to replace the bash process with 
> something else.  But also less outlandish tasks that require a attached 
> working terminal with a human on the other side, for example prompting for a 
> ssh- or gpg-key passphrase.
> 
> Your .bash_profile is allowed to be interactive and any system that assumes 
> it is not is broken.
> 
I suggested that you read the man page.  I guess that you didn't.  It says:

When bash is invoked as an interactive login shell, or as a 
non-interactive shell with the --login option, it first reads and 
executes commands from the file /etc/profile, if that file exists. After 
reading that file, it looks for ~/.bash_profile, ~/.bash_login, and 
~/.profile, in that order, and reads and executes commands from the 
first one that exists and is readable. The --noprofile option may be 
used when the shell is started to inhibit this behavior.

Since the ".bash_profile" script is read by a non-interactive login 
shell, it should NOT be interactive.

Notice how there are two login profile scripts.  One global and one for 
the user.  This is so the user can customize the profile.

>>> Sourcing .bashrc is less dangerous, since (because of historical
>>> problems) it shouldn't consume input or produce output most of the time.
>> But, that isn't relevant since it isn't what is sourced for login.  IAC,
>> that would be wrong.  The environment should be set in the profile
>> script, not the resource script.
> 
> No, because you generally want the environment to affect all interactive 
> bash shells even if they are not bash login shells, like bash started inside 
> an xterm or a shell running from inside mutt/vim.
> 
You appear to be confused about how the execution tree works.  You login 
and then all operations that branch from that login ARE affected by the 
environment that the login has set.  You can not open an interactive 
shell without logging in -- if you can, your system is broken.

> Generally, your .bash_profile should read your .bashrc (the bash man- and 
> info-pages recommend it).  However, .bash_profile can also do things that 
> you would only want to happen once a login.  (e.g. print the MOTD, unlock 
> your keychain, or replace your shell with GNU Screen)
> 
Simple proof of why you don't want to set the environment in .bashrc:

PATH=$HOME/bin:$PATH
export PATH

If you put this in .bashrc, it will be executed once when you login. 
Then if you, for example open a Konsole in KDE and execute "konsole" it 
will have been executed three times and your PATH will three entries. 
And this is why environment settings go in the *_profile script and not 
in the *rc script.

-- 
JRT

Linux (mostly) From Scratch

___________________________________________________
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.