R started in terminal shell script or ESS steps on LD_LIBRARY_PATH?
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