Re: environment variables

[David T. Pierson]

On Wed, Dec 11, 2013 at 12:06:36PM +0100, Nico Schlömer wrote:
> I would like to execute a program in a shell that needs a custom path
> added to  LD_LIBRARY_PATH. This happens in my .bashrc by default, so
> on the regular non-screen shell I'm getting no problems.
> On a detached screen however, the program will not execute with an
> error message related to an incomplete LD_LIBRARY_PATH. Indeed,
> 
> $ env | grep LD_LIBRARY_PATH
> LD_LIBRARY_PATH=/home/nschloe/Work/FEniCS/lib/:/opt/trilinos/dev/openmpi/1.4.3/gcc/4.6.3/release/shared/lib/:/opt/netcdf/4.2.1.1/lib/:/home/nschloe/Work/FEniCS/lib:
> $ screen -L -d -m sh -c "env | grep LD_LIBRARY_PATH"
> $ cat screenlog.0
> $
> 
> so LD_LIBRARY_PATH doesn't seem to be defined in the detached shell at all.
> It *does* get set in attached shells though.

I think there are 2 main factors contributing to the behavior you are
seeing:

1) Even assuming that 'sh' is a symlink to bash, I don't think the
.bashrc will be read when using 'sh -c'.  See the INVOCATION section of
the bash man page for more information.  BTW, I recommend using 'bash'
instead of 'sh' if you really want bash, because at some point the local
'sh' may not be bash, and also bash's behavior may differ when invoked
as 'sh'.

2) When screen creates a new window (detached or not), the
LD_LIBRARY_PATH variable is somehow dropped.  I'm not sure by what
mechanism this occurs.  Actually this might depend on the version you
are using and what patches have been applied, etc.  This dropping of
LD_LIBRARY_PATH is not normally a problem for you because (presumably)
your .bashrc is getting read for a new interactive shell.

Your best bet is probably to create a new bash script that sets all the
variables it needs before doing its work, and then invoke that via:

  screen -L -d -m bash /path/to/script.bash


David