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

[Kasper Daniel Hansen]

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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel