Re: [kde] KDE menus (Lancelot, Kmenu, Krunner) not respecting PATH?

In <4A036DD4.5000702@xxxxxxx>, James Richard Tyrer wrote:
Boyd Stephen Smith Jr. wrote:
In <4A034073.7000703@xxxxxxx>, 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@xxxxxxxxxxxxxxxxx ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/

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

Relevant Pages

  • Re: [kde] KDE menus (Lancelot, Kmenu, Krunner) not respecting PATH?
    ... for the shell that you are using. ... because an Xsession is not a bash login. ... that the user profile script must be compatible with the shell ...
    (KDE)
  • Re: No sourcing of ~/.profile at login
    ... login process) know your ... won't know about my own whizzy furblyburb shell. ... That implied to me the .profile. ... My preferred login method for years was the terminal console and I ...
    (Debian-User)
  • Re: Running top without a shell -- more questions
    ... > shell. ... I note that there is a login process under root that just sits ... modify /etc/ttys to call your own little buffer program. ...
    (freebsd-questions)
  • Re: ssh
    ... I think I've settled on the one solution using a profile script. ... The users have to deal with the linux "login" prompt but it's not bad. ...
    (comp.databases.pick)
  • RE: SSH Tunneling without console login
    ... > that the command will also login onto PC2. ... > not give a shell prompt, ... I only need SSH ... > tunneling purposes, i login to the remote server ...
    (SSH)