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

[James Richard Tyrer]

Boyd Stephen Smith Jr. wrote:
> 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.
> 
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.

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

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

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

> 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".  Configuration of the system (e.g. setting environment
variables) goes in the ".*_profile" script.  All ".*_profile" files
should do exactly the same thing.  They are just written with different
syntax so that they can be executed by the shell being used.

> 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?  The ".*_profile" script is to
configure the system in is NOT to configure the shell.

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.

> 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.)
> 
Yes, you can screw up a system so that it does not execute the
"/etc/profile" and "$HOME/.*_profile" shells on login, but that is a
seriously broken system.

>>> 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
> 
An interesting Kludge.  I have seen similar stuff before.  But, why not
just do it the correct way.  If you have the system set up correctly,
there is no need to check the PATH.
> 

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