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 _______________________________________________ screen-users mailing list screen-users@gnu.org https://lists.gnu.org/mailman/listinfo/screen-users
