Re: How to capture all the environment variables from shell?
On Wed, 11 Aug 2010 13:08:59 +1000, Cameron Simpson wrote:
The reason .bashrc gets overused for envars, aside from ignorance and
propagated bad habits, is that in a GUI desktop the setup sequence is
often a bit backwards. A conventional terminal/console login means you
get a login shell that sources your .{bash_}profile. And from there one
would start a GUI and all the .profile stuff has been run Once, as it
should be. But when the login itself is a GUI the various terminals get
started _before_ the .profile stuff gets sourced, because the terminal
is started by the desktop manager. Once common fix for this is to
make all new terminals run login shells. Ugh, but it does work.
Er, not really. If you don't source your ~/.profile (etc) from e.g.
~/.xsession, GUI applications don't get to see the environment settings
therein. The environment isn't just for shells.
The reason why ~/.profile is only sourced by login shells is that it's
supposed to be sourced exactly once, by the initial process of a session,
i.e. the one from which all other programs descend. For a terminal-based
login, login (or sshd or whatever) starts the shell as a login shell
(with argv[0][0] == '-'), and the shell sets up the environment.
For a desktop login, there is no login shell, so something else has to set
up the environment. Simple enough; well, simple enough for anyone who
understands Unix, processes, sessions, etc. But apparently too complex for
the people who create desktop environments, who seem to think that the
environment is somehow specific to shells.
So you usually need to manually configure your session script (e.g.
~/.xsession for xdm) to set up the environment before the desktop
environment gets a look-in.
One caveat: if you set LD_LIBRARY_PATH, it will be unset when running a
setuid or setgid program. This is sometimes the case for terminal
emulators[1], in which case you need to have ~/.bashrc reinstate the
setting.
[1] Allocating a BSD-style pty requires root privilege, and writing
utmp/wtmp entries requires write permission on the file. Modern systems
have Unix98 ptys and a setgid helper program to manage the utmp/wtmp
entries, so there shouldn't be any need for xterm etc to be setuid or
setgid nowadays.
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to capture all the environment variables from shell?
On 12Aug2010 01:28, Nobody nob...@nowhere.com wrote:
| On Wed, 11 Aug 2010 13:08:59 +1000, Cameron Simpson wrote:
| The reason .bashrc gets overused for envars, aside from ignorance and
| propagated bad habits, is that in a GUI desktop the setup sequence is
| often a bit backwards. A conventional terminal/console login means you
| get a login shell that sources your .{bash_}profile. And from there one
| would start a GUI and all the .profile stuff has been run Once, as it
| should be. But when the login itself is a GUI the various terminals get
| started _before_ the .profile stuff gets sourced, because the terminal
| is started by the desktop manager. Once common fix for this is to
| make all new terminals run login shells. Ugh, but it does work.
|
| Er, not really. If you don't source your ~/.profile (etc) from e.g.
| ~/.xsession, GUI applications don't get to see the environment settings
| therein. The environment isn't just for shells.
I think we're in violent agreement here. I arrange to do exactly that in
my own desktop setups.
However, the ones that ship with distros generally don't, possibly because a
shell-aborting error in the .profile (or unwanted interaction etc) will abort
the GUI login/desktop-setup.
Cheers,
--
Cameron Simpson c...@zip.com.au DoD#743
http://www.cskk.ezoshosting.com/cs/
The Puritan hated bear-baiting, not because it gave pain to the bear, but
because it gave pleasure to the spectator. - Macaulay, History of England
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to capture all the environment variables from shell?
On 8/2/2010 4:33 AM, Thorsten Kampe wrote: * Tim Chase (Mon, 26 Jul 2010 21:42:24 -0500) On 07/26/10 21:26, Steven W. Orr wrote: Please! Never export anything from your .bashrc unless you really know what you're doing. Almost all exports should be done in your .bash_profile Could you elaborate on your reasoning why (or why-not)? I've found that my .bash_profile doesn't get evaluated when I crank up another terminal window, while my bashrc does. Thus I tend to put my exports in my ~/.bashrc so they actually take effect in my shell... ~/.bash_profile is only evaluated for login shells and ~/.bashrc only for non-login shells. Thus it's recommended to keep ~/.bash_profile empty (except a source statement for .bashrc) and put all your settings, aliases, exports, etc. in .bashrc. Thorsten Sorry. Dead wrong. Please reread the above comment I wrote. If you set your environment variables in the .bashrc then you completely lose the ability of environment variables to be inherited by sub-shells. Again, envvars should be set in the .bash_profile, most everything else should be set in the .bashrc, and the .bashrc should be sourced into the .bash_profile to solve the problem that you thought you were solving. After that, and again, be aware that the .bashrc alone is executed for login shells *which are not interactive*. for example: ssh somemachine 'echo Hello' This command will *not* go through the .bash_profile but it will go through the .bashrc. This means that for cases like this, we want to check to see if the bash process is interactive or not inside the .bashrc and then do the right thing. Inside your .bashrc=== [[ -z $PS1 ]] setPATHHere EOInside your .bashrc=== This is not needed for the above degenerate case, but it is needed if the command in question is kept in a directory that you normally find in a place that is part of your personal login PATH. E.G., If myprog lives in ~/bin then ssh somemachine myprog will fail unless you use the above construct. Hopefully, I'll only have to re-explain this another google times... -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net steve orr -- http://mail.python.org/mailman/listinfo/python-list
Re: How to capture all the environment variables from shell?
On 10Aug2010 10:07, Steven W. Orr ste...@syslang.net wrote:
| On 8/2/2010 4:33 AM, Thorsten Kampe wrote:
| * Tim Chase (Mon, 26 Jul 2010 21:42:24 -0500)
| On 07/26/10 21:26, Steven W. Orr wrote:
| Please! Never export anything from your .bashrc unless you
| really know what you're doing. Almost all exports should be
| done in your .bash_profile
|
| Could you elaborate on your reasoning why (or why-not)? I've
| found that my .bash_profile doesn't get evaluated when I crank up
| another terminal window, while my bashrc does. Thus I tend to
| put my exports in my ~/.bashrc so they actually take effect in my
| shell...
|
| ~/.bash_profile is only evaluated for login shells and ~/.bashrc only
| for non-login shells. Thus it's recommended to keep ~/.bash_profile
| empty (except a source statement for .bashrc) and put all your settings,
| aliases, exports, etc. in .bashrc.
|
| Sorry. Dead wrong. Please reread the above comment I wrote. If you set your
| environment variables in the .bashrc then you completely lose the ability of
| environment variables to be inherited by sub-shells. Again, envvars should be
| set in the .bash_profile, most everything else should be set in the .bashrc,
and
| the .bashrc should be sourced into the .bash_profile to solve the problem that
| you thought you were solving.
|
| After that, and again, be aware that the .bashrc alone is executed for login
| shells *which are not interactive*. for example:
|
| ssh somemachine 'echo Hello'
|
| This command will *not* go through the .bash_profile but it will go through
the
| .bashrc.
No, only interactive shells use the .bashrc.
Still, you're quite right that envvars belong in the .bash_profile.
.bashrc is for trivial setup stuff relevant only to interactive shells
(for example history settings and interactive aliases).
| This means that for cases like this, we want to check to see if the
| bash process is interactive or not inside the .bashrc and then do the right
thing.
|
| Inside your .bashrc===
| [[ -z $PS1 ]] setPATHHere
| EOInside your .bashrc===
This is Very Wrong. (RedHat do this test - it is bogus - if I set $PS1
in my profile it breaks badly.) Instead, test $-:
case $- in *i*) echo INTERACTIVE ;; *) echo BATCH ;; esac
| This is not needed for the above degenerate case, but it is needed if the
| command in question is kept in a directory that you normally find in a place
| that is part of your personal login PATH. E.G., If myprog lives in ~/bin then
|
| ssh somemachine myprog
|
| will fail unless you use the above construct.
|
| Hopefully, I'll only have to re-explain this another google times...
googol, surely?
The reason .bashrc gets overused for envars, aside from ignorance and
propagated bad habits, is that in a GUI desktop the setup sequence is
often a bit backwards. A conventional terminal/console login means you
get a login shell that sources your .{bash_}profile. And from there one
would start a GUI and all the .profile stuff has been run Once, as it
should be. But when the login itself is a GUI the various terminals get
started _before_ the .profile stuff gets sourced, because the terminal
is started by the desktop manager. Once common fix for this is to
make all new terminals run login shells. Ugh, but it does work. But it
they're not login shells, people stuff everything into their .bashrc
because the .profile doesn't get sourced. And so the common awful setup
you're bemoaning.
Cheers,
--
Cameron Simpson c...@zip.com.au DoD#743
http://www.cskk.ezoshosting.com/cs/
For us, Zettai Zetsumei Toshi is an allegory for relations between the sexes,
and it works especially well at this because we don't speak Japanese. She
will say things, and we have no idea what the hell is going on, and then
we'll select from a list of responses, but we have no idea which one is the
right one, and then they're all wrong. It works on a lot of levels.
- Tycho @ _Penny_Arcade_
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to capture all the environment variables from shell?
On 11Aug2010 13:08, I wrote: | On 10Aug2010 10:07, Steven W. Orr ste...@syslang.net wrote: [...] | | After that, and again, be aware that the .bashrc alone is executed for login | | shells *which are not interactive*. for example: | | | | ssh somemachine 'echo Hello' | | | | This command will *not* go through the .bash_profile but it will go through the | | .bashrc. | | No, only interactive shells use the .bashrc. And then I read more closely and saw this in man bash: Bash attempts to determine when it is being run by the remote shell daemon, usually rshd. If bash determines it is being run by rshd, it reads and executes commands from ~/.bashrc, if that file exists and is readable. It will not do this if invoked as sh. The --norc option may be used to inhibit this behavior, and the --rcfile option may be used to force another file to be read, but rshd does not generally invoke the shell with those options or allow them to be specified. Frankly, bash's startup behaviour is so corrupt (well, capricious anway) that I despair of it; I use zsh when possible. It also tries to be all things to all people, but is a bit saner. (And it doesn't hardwire ^W either!) Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ To be positive: To be mistaken at the top of one's voice. Ambrose Bierce (1842-1914), U.S. author. The Devil's Dictionary (1881-1906). -- http://mail.python.org/mailman/listinfo/python-list
Re: How to capture all the environment variables from shell?
* Tim Chase (Mon, 26 Jul 2010 21:42:24 -0500) On 07/26/10 21:26, Steven W. Orr wrote: Please! Never export anything from your .bashrc unless you really know what you're doing. Almost all exports should be done in your .bash_profile Could you elaborate on your reasoning why (or why-not)? I've found that my .bash_profile doesn't get evaluated when I crank up another terminal window, while my bashrc does. Thus I tend to put my exports in my ~/.bashrc so they actually take effect in my shell... ~/.bash_profile is only evaluated for login shells and ~/.bashrc only for non-login shells. Thus it's recommended to keep ~/.bash_profile empty (except a source statement for .bashrc) and put all your settings, aliases, exports, etc. in .bashrc. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: How to capture all the environment variables from shell?
On Mon, 26 Jul 2010 21:42:24 -0500, Tim Chase wrote: Please! Never export anything from your .bashrc unless you really know what you're doing. Almost all exports should be done in your .bash_profile Could you elaborate on your reasoning why (or why-not)? I've found that my .bash_profile doesn't get evaluated when I crank up another terminal window, while my bashrc does. Thus I tend to put my exports in my ~/.bashrc so they actually take effect in my shell... Ideally, whichever program spawns the terminal window should have all of the environment settings from your ~/.profile (although you may have to explicitly source it from e.g. ~/.xsession), so it shouldn't be necessary to export them again. Using ~/.bashrc is a band-aid in case your desktop session doesn't already have your environment settings. But it only works for shells (and only for bash shells, and only for interactive bash shells), while your environment settings should be available to everything, regardless of whether it was spawned from an interactive bash shell or from some other program. Also, if you update environment variables with e.g.: export PATH=$PATH:/usr/local/bin any nested shells end up getting multiple updates. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to capture all the environment variables from shell?
On 07/26/10 22:42, quoth Tim Chase:
On 07/26/10 21:26, Steven W. Orr wrote:
Please! Never export anything from your .bashrc unless you
really know what you're doing. Almost all exports should be
done in your .bash_profile
Could you elaborate on your reasoning why (or why-not)? I've found that
my .bash_profile doesn't get evaluated when I crank up another terminal
window, while my bashrc does. Thus I tend to put my exports in my
~/.bashrc so they actually take effect in my shell...
-tkc
I'm happy to elaborate, but people should feel free to stop me if they're not
interested. The topic is bash:
When you log in you get your .bash_profile and not the .bashrc. Subshells get
the .bashrc and not the .bash_profile. If you set your envvars in your
.bash_profile then you don't need to reset them in subshells because they all
get inherited. (Inheritance of envvars is, after all, the reason that they are
envvars and not just local variables.)
The way you get your .bashrc to happen at login time is that you have to make
it happen yourself. In your .bash_profile, just say this:
. ~/.bashrc
The one time that you should set an envvar in your .bashrc is when you are not
an interactive shell. In that case you can set your PATH var in your .bashrc
by first testing to see if you're interactive: In your .bashrc just say:
[[ -z $PS1 ]] set_PATH_cmds
# Of course, note that set_PATH_cmds is not a subprocess. It has to
# be either a PATH= or function that accomplishes the same thing.
This solves the problem of things like
ssh somemachine cmd
where cmd is something that you would only find on your PATH if you properly
logged in.
As far as X goes, I am starting from the premise that your X session will be
set up to cause your .bash_profile to happen at login time.
One last note: If you say something like
export PATH=$PATH:/usr/local/bin
then re-sourcing your .bash_profile will cause your PATH value to double up.
That's why I set my PATH variable explicitly.
After that, I encourage people to set up their PATH variables so that they are
broken into four distinct sections in the following order. (The idea is to
make your stuff override the system supplied stuff.) (The stuff below is just
an example.)
USERPERSONAL=~/bin:~/share/bin
MACHINESPECIALS=/usr/local/bin:/usr/local/share/bin
OPTIONALADDONS=/opt/Adobe/Reader9/bin:/opt/openoffice.org3/program
VENDORPATHS=/bin:/usr/bin:/usr/X11R6/bin
PATH=${USERPERSONAL}:${MACHINESPECIALS}:${OPTIONALADDONS}:${VENDORPATHS}
--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
signature.asc
Description: OpenPGP digital signature
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to capture all the environment variables from shell?
On Mon, Jul 26, 2010 at 4:36 PM, Peng Yu pengyu...@gmail.com wrote: Hi, R_HOME is set in my shell (bash). But os.environ doesn't have it. I'm not sure what it does when os module is imported. But it seems that os.environ doesn't capture all the environment variable from the shell. Could anybody let me know what is the correct way to inherent all the environment variables form the shell? $ echo $R_HOME /opt/R-2.11.1 $ cat main.py #!/usr/bin/env python import os print os.environ['R_HOME'] $ ./main.py Traceback (most recent call last): File ./main.py, line 5, in module print os.environ['R_HOME'] File /opt/Python-2.6.5/lib/python2.6/UserDict.py, line 22, in __getitem__ raise KeyError(key) KeyError: 'R_HOME' You need to export R_HOME in bash (probably in your .bashrc or .bash_profile). See http://www.ibm.com/developerworks/library/l-bash.html#N10074 Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: How to capture all the environment variables from shell?
On Tue, 27 Jul 2010 00:36:12 +0100, Peng Yu pengyu...@gmail.com wrote: R_HOME is set in my shell (bash). But os.environ doesn't have it. I'm not sure what it does when os module is imported. But it seems that os.environ doesn't capture all the environment variable from the shell. Could anybody let me know what is the correct way to inherent all the environment variables form the shell? os.environ does capture all the environment that the shell passes to it. In this case, you haven't exported R_HOME, so the shell doesn't export it, so os.environ has no chance to capture it. rho...@gnudebst:~$ HELLO=world rho...@gnudebst:~$ echo $HELLO world rho...@gnudebst:~$ export HELLO rho...@gnudebst:~$ python Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. import os os.environ['HELLO'] 'world' -- Rhodri James *-* Wildebeest Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: How to capture all the environment variables from shell?
On 26Jul2010 18:36, Peng Yu pengyu...@gmail.com wrote: | R_HOME is set in my shell (bash). But os.environ doesn't have it. I'm | not sure what it does when os module is imported. But it seems that | os.environ doesn't capture all the environment variable from the | shell. Could anybody let me know what is the correct way to inherent | all the environment variables form the shell? | | $ echo $R_HOME | /opt/R-2.11.1 | $ cat main.py | #!/usr/bin/env python | | import os | | print os.environ['R_HOME'] | $ ./main.py | Traceback (most recent call last): | File ./main.py, line 5, in module | print os.environ['R_HOME'] | File /opt/Python-2.6.5/lib/python2.6/UserDict.py, line 22, in __getitem__ | raise KeyError(key) | KeyError: 'R_HOME' Sounds like R_HOME is not exported. Try these in your shell: set | grep R_HOME export | grep R_HOME Then, presuming it shows only in the first command: export R_HOME and then try your python script again. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ It is an approved maxim in war, never to do what the enemy wishes you to do, for this reason alone, that he desires it. - Napoleon -- http://mail.python.org/mailman/listinfo/python-list
Re: How to capture all the environment variables from shell?
On 07/26/10 20:02, quoth Chris Rebert: On Mon, Jul 26, 2010 at 4:36 PM, Peng Yu pengyu...@gmail.com wrote: You need to export R_HOME in bash (probably in your .bashrc or .bash_profile). See http://www.ibm.com/developerworks/library/l-bash.html#N10074 Please! Never export anything from your .bashrc unless you really know what you're doing. Almost all exports should be done in your .bash_profile -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: How to capture all the environment variables from shell?
On 07/26/10 21:26, Steven W. Orr wrote: Please! Never export anything from your .bashrc unless you really know what you're doing. Almost all exports should be done in your .bash_profile Could you elaborate on your reasoning why (or why-not)? I've found that my .bash_profile doesn't get evaluated when I crank up another terminal window, while my bashrc does. Thus I tend to put my exports in my ~/.bashrc so they actually take effect in my shell... -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: How to capture all the environment variables from shell?
On Mon, 26 Jul 2010 22:26:27 -0400, Steven W. Orr wrote: Please! Never export anything from your .bashrc unless you really know what you're doing. Almost all exports should be done in your .bash_profile Would you like to explain why, or should we just trust you? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
