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.
