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