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

[Hin-Tak Leung]

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.
=========



Marc Schwartz (via MN) wrote:
> Hi all,
> 
> In follow up to my prior post on this issue, I have found a workaround,
> but have not yet clearly identified the etiology of the problem.
> Whatever it is, it is presumably unique to my system, though if anyone
> can replicate this on another FC4 system...  :-)
> 
> The workaround involves booting to init 3 rather than init 5 and
> starting X manually from the console. I found this after going through
> some of the steps described below regarding my X configuration. In this
> way, LD_LIBRARY_PATH is preserved and RODBC works without issue in both
> ESS and the gnome-terminal shell start up script.
> 
> Dirk was kind enough to send me an offlist e-mail yesterday in reply,
> which sparked some thoughts as I was away from the computer for a few
> hours yesterday afternoon and evening.
> 
> Dirk's e-mail logically queried on any issues with gnome-terminal and/or
> the bash shell itself.
> 
> Since this problem was new (this had all worked previously), I checked
> to see if there had been any recent updates to either gnome-terminal or
> bash in the FC repos. There were none, although there have been of
> course updates to GNOME, GTK and other libs.
> 
> This got me to think about other updates since the last known time this
> process worked properly. So I spent several hours last night and this
> morning reviewing possibilities.
> 
> The last Xorg updates are from last September, so these are not new.
> 
> Other changes that I had made in the recent past include:
> 
> 1. Modifying my xorg.conf to support nVidia TwinView hardware
> acceleration functionality. TwinView is like xinerama mode, spanning
> both displays to give me a virtual 3200x1200 screen, though supporting
> HW acceleration on both displays. Previously I had been using two X
> servers (also using the nVidia driver in non-xinerama mode) to support
> my dual display configuration.  Reverting back to the old configuration
> did not resolve the problem. 
> 
> 2. The last nVidia driver update (8178) was in December and this process
> had worked since then.
> 
> 3. There was an updated Cisco VPN client for Linux (4.8) to support
> recent kernels. The VPN client is installed from source. This normally
> starts up on boot as a service. Disabling the service, thus removing the
> kernel module, did not resolve the problem.
> 
> 4. I had updated the encryption of several of my partitions on my laptop
> to use dm-crypt/LUKS with 256 bit AES from regular dm-crypt to take
> advantage of pending LUKS support updates in HAL and other system
> functions. Disabling the encryption (so the relevant kernel modules did
> not load), logging in as root and running ESS from root's home did not
> resolve the problem.
> 
> 5. Just in case, I also reinstalled kernel version 2.6.15-1.1830
> (running 1833 now) to see if there was any change there. No joy. I
> cannot locate any of the 2.6.14 FC4 kernel versions, as these have been
> removed from the repos, so it leaves open the possibility of something
> in the .14 to .15 rebase change.
> 
> 
> Other than routine system updates via yum, these are the only
> "self-inflicted" changes that I have made recently. If any of the above
> should spark some thoughts, let me know.
> 
> My plans are to live with this for now. FC5 is targeted for release next
> Wednesday, presuming that it stays on schedule. I'll do a clean install
> with that and see if anything is resolved, perhaps indicating some other
> issue that is as yet unidentified.
> 
> Many thanks to Dirk for your assistance.
> 
> Best regards,
> 
> Marc Schwartz
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel