[Rd] R started in terminal shell script or ESS steps on LD_LIBRARY_PATH?

[Marc Schwartz (via MN)]

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