I am _not_ an expert on bash. But as far as I know, .bashrc is not read when you have a login session, whereas .bash_profile is. I have never really understood the deep differences between the two - I only have some superficial understanding. But for my purposes I just have a source .bashrc in my .bash_profile script. In that way I set the same variables no matter what kind of session I have (clearly, I only use .bashrc).
There are important differences when you want to run a program at login, but you do not want to run it every time you start up a shell. But simply for setting environment variables, this ought to work. Perhaps this helps? Or perhaps this is something deeper than the simple issue outlined above. /Kasper On Mar 8, 2006, at 1:42 PM, Marc Schwartz (via MN) wrote: > On Wed, 2006-03-08 at 13:54 -0600, Marc Schwartz wrote: >> On Wed, 2006-03-08 at 18:39 +0000, Hin-Tak Leung wrote: >>> This sounds like a shell init issue... and you probably want to hunt >>> down where LD_LIBRARY path is *set*, rather than how it is >>> inherited. >>> >>> When you log in in run-level three, you get a login shell rather >>> than >>> a normal interactive shell, and your startx inherits your login- >>> shell's >>> environment, You get a normal interactive shell(?) inside >>> gnome-terminal/xterm if you start at run-level 5, and finally, >>> you get >>> a non-interactive shell if you run a script, most of the time. >>> The environments in the three cases are all different, and >>> sometimes security related environment variables are not inherited >>> by forked sub-shells, such as LD_LIBRARY_PATH; or more likely, >>> LD_LIBRARY_PATH is set up for the login shell, and other shells >>> simply don't get it. >>> >>> HTL >>> >>> From the INVOCATION part of bash's man page - assuming that's your >>> login shell, otherwise, others. >>> =========== >>> When bash is invoked as an interactive login shell, or as a non- >>> inter- >>> active shell with the --login option, it first reads and >>> executes com- >>> mands 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. The --noprofile option may be used >>> when the >>> shell is started to inhibit this behavior. >>> >>> When a login shell exits, bash reads and executes commands >>> from the >>> file ~/.bash_logout, if it exists. >>> >>> When an interactive shell that is not a login shell is >>> started, bash >>> reads and executes commands from ~/.bashrc, if that file >>> exists. This >>> may be inhibited by using the --norc option. The --rcfile file >>> option >>> will force bash to read and execute commands from file >>> instead of >>> ~/.bashrc. >>> >>> When bash is started non-interactively, to run a shell >>> script, for >>> example, it looks for the variable BASH_ENV in the environment, >>> expands >>> its value if it appears there, and uses the expanded value as >>> the name >>> of a file to read and execute. Bash behaves as if the >>> following com- >>> mand were executed: >>> if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi >>> but the value of the PATH variable is not used to search for >>> the file >>> name. >>> ========= >> > > <SNIP> > > > Many thanks for the reply. Given the subject matter feel free to > respond offlist with any further replies. I can post back should I > figure this out for the sake of closure on the thread. > > LD_LIBRARY_PATH is set in ~/.bashrc and this has worked fine > previously, > so I am still unclear as to what has changed. Though I am readily > willing to accept that something has been screwed up somehow. > Presuming > that a system wide setting has been compromised in some fashion, the > pending clean install of FC 5 may be helpful. > > If not, I may need to consider something in my own user profile > configuration. > > I also logged into a KDE session from init 5, to see if perhaps > whatever > was going on might have been GNOME specific. Unfortunately, the same > behavior is seen in KDE using ESS. > > Two more data points under init 5 in GNOME however: > > 1. If I open a gnome-terminal console and start R from the CLI, things > work. If I exit R and use 'gnome-terminal -x R' within that same > console > to mimic my startup script, it does not work, even though the variable > is clearly set in the console prior to entering the command. > However, if > from the same initial gnome-terminal console session, I use 'xterm -e > R', it works. > > 2. If I use the "Run Application..." dialogue from the GNOME menu, > type > in 'R' and check "Run in terminal", it does not work. > > There is something subtle going on here, that I am just not seeing. > > Thanks again for taking the time to reply. > > Best regards, > > Marc > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
