Environment variables

[Lowell T.]

I tried (unsuccessfully) to append a desired file to the end of a stock environment variable in my:

Mandrake 10.1
Linux 2.5.1

i.e, I included this line in my ~/.bashrc file:

export PYTHONSTARTUP=$PYTHONSTARTUP:~/bash_function/mypythonrc.py

but the value of PYTHONSTARTUP did not expand to include my intended file ((mypthonrc.py)

The effort only worked when I modified the assignment as:

export PYTHONSTARTUP=~/bash_function/mypythonrc.py

The end result was that I lost the original value of PYTHONSTARTUP, which is fine (I ended up just taking the lines I needed from /etc/pythonrc.py and including them in my file) but it all misses the point. I don't understand why my original assignment effort failed (yes, I did source as I was working). Here's why I thought it should work--I copied a similar assignment that also exists in my ~/.bashrc file (that does work perfectly) and modified it. Here's that original line:

export PYTHONPATH=$PYTHONPATH:~/usrlowell/Python-2.5.1/Lib/mymodules

Doesn't make sense that one would work and the other not, so I'm moving behind the fact that I was able to get a fix that did what I wanted it to. I also want to know why the first effort failed.

Google's not giving me a lot of help here, and I also couldn't find--in your forums--dialog from anyone else who had suffered a similar failure.

Thanks [in advance] for your kind attention and input.

[Rubberman]

When recursively defining environment variables in bash, you need to enclose the name in {}. Example:

export PYTHONSTARTUP=${PYTHONSTARTUP}:~/bash_function/mypythonrc.py

[nmset]

I have recursive env variables (PATH) in bashrc that do expand without braces {}. So it's quite curious.

It seems that modifications to bashrc are taken into account when a new session is opened only. They are ignored in the same session. Could it be an explanation ? Try and let us know.

It would not explain

The effort only worked when I modified the assignment as:

export PYTHONSTARTUP=~/bash_function/mypythonrc.py

unless the effort worked in a new bash instance.

[Lowell T.]

When recursively defining environment variables in bash, you need to enclose the name in {}. Example:

export PYTHONSTARTUP=${PYTHONSTARTUP}:~/bash_function/mypythonrc.py

Apparently not--anyway, the results are a mixed (mostly failed) bag, eg: here's the [modified] line and the consequences after I re-sourced ~/.bashrc (wherein this line exists):

export PYTHONSTARTUP=${PYTHONSTARTUP}:~/bash_function/mypythonrc.py

and the results:

=> Sun Jan 10:lowell:Coord]:$echo $PYTHONSTARTUP
/etc/pythonrc.py:/home/lowell/bash_function/mypythonrc.py

Now, (as I would correctly expect them to--that part works) both the original value (/etc/pythonrc.py) and my own file (/bash_function/mypythonrc.py) show up as values for $PYTHONSTARTUP. However, the Environment Variable (PYTHONSTARTUP no longer appears to be invoked when I bring up an [interactive] instance of "python" in my terminal:

>>> os.system('ls')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'os' is not defined

Here is the relevant excerpt from my mypythonrc.py file that should be available in the terminal, and that was when I invoked the line formatted as:
export PYTHONSTARTUP=~/bash_function/mypythonrc.py

# ------------- Envrionment variables
2
3 # these are the features that are automatically started when the python
4 # interactive shell is invoked. This file is called by ~/.bashrc with the
5 # line 'export PYTHONSTARTUP=...'
6
7 import csv
8 import math
9 import os
10 import fpformat
11 import sys


Again (going back to my first post) I offered an example that is an active line in my ~/.bashrc that does work as advertised, and that does so without the brackets "{}".

So...where to from here?

[Rubberman]

Whether or not they expand properly depends upon whether you are prepending data or appending data or both to the variable. Using the braces is safe in any conditions, and is advisable whenever you are defining an environment or shell variable in terms of itself.

As for /etc/bashrc and ~/.bashrc, those should be interpreted whenever a new shell is started. /etc/profile and ~/.bash_profile are only interpreted when a login shell is started. FWIW, the shell actually only executes ~/.bashrc and/or ~/.bash_profile. Those scripts typically have a section like this (from ~/.bashrc):

if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

If these lines are removed or commented out of the user's .bashrc file, then /etc/bashrc (and similarly /etc/profile) will not be interpreted. Making system settings and/or behavior dependent on code in /etc/bashrc or /etc/profile is dangerous since any user has the capability to modify their own ~/.bashrc or ~/.bash_profile files, possibly removing the necessary lines that force inclusion of /etc/bashrc or /etc/profile.

[Lowell T.]

If these lines are removed or commented out of the user's .bashrc file, then /etc/bashrc (and similarly /etc/profile) will not be interpreted. Making system settings and/or behavior dependent on code in /etc/bashrc or /etc/profile is dangerous since any user has the capability to modify their own ~/.bashrc or ~/.bash_profile files, possibly removing the necessary lines that force inclusion of /etc/bashrc or /etc/profile.

My ~/.bashrc file is the main environment file in my 'house', as is {I think] pretty much a standard. All my customizations go there; here's a relevant snippet from the ~/.bash_profile:

1 # .bash_profile
2
3 # Get the aliases and functions
4 if [ -f ~/.bashrc ]; then
5 . ~/.bashrc
6 fi

As well as I understand it (and that's a very thin veneer) appending directories to an Environment variable (e.g. $PATH, $CDPATH) is generally accomplished by tacking the desired additions on following a colon; e.g. PATH=$PATH:/mynewdir. That's how I've successfully expanded my PATH; that's how I've successfully expanded my PYTHONPATH. There is no logical reason why a similar approach should not successfully expand my PYTHONSTARTUP. Here, in the Python-2.5.1/main.c file are the references to many of those environment variables, i.e. where they are (I assume) recognized and offered out to the world.

static char *usage_4 = "\
88 arg ...: arguments passed to program in sys.argv[1:]\n\
89 Other environment variables:\n\
90 PYTHONSTARTUP: file executed on interactive startup (no default)\n\
91 PYTHONPATH : '%c'-separated list of directories prefixed to the\n\
92 default module search path. The result is sys.path.\n\
93 PYTHONHOME : alternate <prefix> directory (or <prefix>%c<exec_prefix>).\n\
94 The default module search path uses %s.\n\
95 PYTHONCASEOK : ignore case in 'import' statements (Windows).\n\
96 ";

Bottom line, I'm pretty much leaving here as I came. The needed files are pretty much back as they were, my desired initializations work when I open a Python terminal, and I haven't really gained a bit of insight. I imagine that, by serendipity, some sense of it all [may] just settle in somewhere down the road. Meanwhile, what I need to have working, does.

I appreciate the input.

[Lowell T.]

I have recursive env variables (PATH) in bashrc that do expand without braces {}. So it's quite curious.

It seems that modifications to bashrc are taken into account when a new session is opened only. They are ignored in the same session. Could it be an explanation ? Try and let us know.

It would not explain

unless the effort worked in a new bash instance.

Whatever alterations I make to ~/.bashrc are recognized as soon as I either:

source ~/.bashrc
or, restart my Mandrake [10.1] OS; either has the same effect

But, as I'd mentioned, different applications of the [seemingly] same principle behaved differently, and I've been unable to garner any plausible explanations...it'll come, one day.