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

[Boyd Stephen Smith Jr.]

In <4A034073.7000703 at acm.org>, James Richard Tyrer wrote:
>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).
>> No, because an Xsession is not a bash login.  It is an X login. 
>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.

No, it is *exactly* the profile script for a bash session.  It is not used 
for a zsh login session or a sh login session or a tcsh login session.  It 
also should not be used for an X login session.

>>>> Sourcing .bash_profile (or .profile) is a bit dangerous, as they are
>>>> allowed to be fully interactive.
>>> 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.
>
>Since the ".bash_profile" script is read by a non-interactive login
>shell, it should NOT be interactive.

Non-interactive login shells are an abomination.  I ignore them on purpose.

My experience (in a Fortune 1 company) indicates that /etc/profile and 
similar (e.g. .bash_profile) are expected to be able to interact with the 
user.

My personal experience also indicates that .bash_profile is the best place 
to unlock keychains, which requires interactivity.

>>>> Sourcing .bashrc is less dangerous, since (because of historical
>>>> problems) it shouldn't consume input or produce output most of the
>>>> time.
>>> 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.

No, I'm not confused about that.  I am clear that .bashrc affects more 
shells than .bash_profile.  I am also clear that environments are inherited 
from parent processes.  I also understand that it is possible to unset parts 
of or the whole environment.  If you want an environment variable set for 
all interactive shells, setting it in your login script is not enough.

You CAN open an interactive zsh shell without having a zsh login shell.  
Likewise, you can have an interactive bash shell without .bash_profile being 
read by any of its parent processes.  You can even have an interactive shell 
without having a login shell.  (You'll still have a login process, but it 
could be a binary not listed in /etc/shells and not reading any sort of 
scripting language.)

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

That just proof that you shouldn't be writing shell scripts.
Here's the way to add ~/bin to your path:
if [ -d ~/bin ]; then
        case ":${PATH}:" in
         *:${HOME}/bin:*)
                ;;
         :?*:) PATH=~/bin:${PATH};;
         *) PATH=~/bin;;
        esac
        export PATH
fi
-- 
Boyd Stephen Smith Jr.           	 ,= ,-_-. =.
bss at iguanasuicide.net            	((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy 	 `-'(. .)`-'
http://iguanasuicide.net/        	     \_/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20090507/b89df075/attachment.sig>
-------------- next 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.