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

[Boyd Stephen Smith Jr.]

In <4A036DD4.5000702 at acm.org>, James Richard Tyrer wrote:
>Boyd Stephen Smith Jr. wrote:
>> In <4A034073.7000703 at acm.org>, James Richard Tyrer wrote:
>>> Boyd Stephen Smith Jr. wrote:
>>>> 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.
>>>> Your .bash_profile is allowed to be interactive and any system
>>>> that assumes it is not is broken.
>>> 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.
>Perhaps we need to define the term.  IIUC, your meaning of an
>interactive shell script is one which REQUIRES user input.  This is an
>error.  OTOH, it is OK to have a login script where user input is
>optional -- that it will run OK without any user input.

An interactive shell is one that has the ability to get user input.  IME, 
/etc/profile and ~/.*profile both expect an interactive shell and, thus, can 
be written in a way (if the admin/user desires) to require user input.

I've seen it done that way in a number of Unix/Linux shops.

>But do you understand that the purpose of ".bashrc" is to configure the
>Bash shell, NOT the system?

As is .bash_profile.  You don't understand that it was *created* to be a way 
to configure *bash* and nothing else.  Anything other than bash (or a fully-
bash-compatible shell) reading it is wrong.

>> 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.
>
>If I start a process from a console, I expect that it will inherit the
>current environment and system configuration.

It will, but that may be a environment very different from the environment you 
set up in your login script.

>> You CAN open an interactive zsh shell without having a zsh login
>> shell.
>
>Yes, but I don't see your point.  Stuff specific to the shell goes in
>the ".*rc file".

Or, in the shell-specific .*profile, if it only needs to be run when the shell 
is a login process.

>Configuration of the system (e.g. setting environment
>variables) goes in the ".*_profile" script.

No, wrong.  Environment variables (or whatever else) that goes in a .*profile 
is for that specific shell when used as a login process.

>All ".*_profile" files
>should do exactly the same thing.

Only in that they should prepare the login process the way the user wants, 
which may be quite different in a X login vs. a ssh login.

>They are just written with different
>syntax so that they can be executed by the shell being used.

No, they have different names because they are *shell-specific*.  They should 
not affect other login processes.

>> Likewise, you can have an interactive bash shell without
>> .bash_profile being read by any of its parent processes.
>
>And what difference does that make?

My point is that if you want some things set consistently in *all* interactive 
bash processes, you should set it in .bashrc.  You should not count on a 
parent process running .bash_profile.  Your zsh or tcsh or dash login process 
won't.

>The ".*_profile" script is to
>configure the system in is NOT to configure the shell.

Wrong.  It is for *shell-specific* configuration for *login* processes only.

The generic ~/.profile can be read by any sh-compatible shell, but it 
shouldn't be used for non-shell login processes.

>Unless you have a screwed system, a ".*_profile" script will have been
>executed when you logged in, the system profile script (/etc/profile)
>and a user profile script ($HOME/.*_profile) are both run at login.  It
>doesn't matter which shell the user is running at the time.

Depending on the login process, one of the .*profile scripts is generally run, 
and /etc/profile is also generally run.  However, you certainly can't count on 
a *specific* one being run (e.g. ~/.bash_profile).

A KDE login is quite a different beast of a bash login, and it, suitably, 
responds to different files.  ${KDEDIRS}/env and ${KDEDIRS}/Autostart (or 
something like that).

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

(Grumble, had to correct my line breaks there -- I think kmail is too generous 
with f=f.)
-- 
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/1e8bb3d8/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.