6

This is related to Why does my LD_LIBRARY_PATH get unset launching terminal?, but a different set of symptoms.

First, /usr/bin/screen is setuid as per the other question. Second, the default shell on this system is /bin/tcsh for various historical reasons, and we're not allowed to chsh to /bin/bash, so I typically run bash manually immediately after login. Third, I almost always use screen, but I want ctrl-a ctrl-c in screen to create a new bash "tab", so I always invoke bash first.

That is:

{~} $ echo $SHELL
/bin/tcsh
{~} $ bash
[~] echo $SHELL
/bin/bash
[~] screen -U
[~]

...and when reconnecting:

{~} $ echo $SHELL
/bin/tcsh
{~} $ screen -dUr
[~] echo $SHELL
/bin/bash
[~] 

However, my $LD_LIBRARY_PATH is there in tcsh, there in bash, but empty once I run screen; it is still present if I just run screen from tcsh, but then I get new tcsh "tabs" when I use ctrl-a ctrl-c in screen.

Any ideas?

1
  • As in my comment to that other question you linked: LD_LIBRARY_PATH is good for debugging / short-term patching binaries, but as a constant addition to your environment, it's a mistake. So I'd recommend that, once you understood why it isn't set in your case, you remove the need for setting it wholesale...
    – DevSolar
    Jul 16, 2012 at 9:49

2 Answers 2

7

Because screen is setuid, it unsets LD_LIBRARY_PATH. When your shell is tcsh, tcsh initialisation (from .tcshrc I suppose, since screen doesn't default to creating login shells) sets LD_LIBRARY_PATH again. If you want LD_LIBRARY_PATH to be set in your bash screen windows, set it from .bashrc.

1
  • THANK you I just combed half the internet and wrote a bunch of bash scripts to figure this out, before getting it confirmed here. I like to set LD_LIBRARY_PATH and LDFLAGS based on the software I'm developing, not globally. At least now I know where things are going wrong for me now.
    – moodboom
    Nov 19, 2015 at 0:49
0

Most people set their $PATH and $LD_LIBRARY_PATH in .bash_profile or .bashrc thinking they are both the same but this is not true. One is for "true shells" and one is for "remote shells" is my understanding of it (I can never remember which is which). Basically, depending on how you login (ssh, desktop terminal, screen, w/e), one is executed or the other. If you have your variables set in one but not the other, consider making one a sym-link to the other or making it a one-liner:

echo "source .bashrc" > .bash_profile

*assuming you use .bashrc now; otherwise:

echo "source .bash_profile" > .bashrc

so that your variables are set no matter how you log in.

3
  • I'm pretty sure this isn't a problem with my bash config, since $LD_LIBRARY_PATH is still inherited from tcsh properly when running bash directly; it's only a problem in the interaction between bash and screen.
    – UltraNurd
    Jun 16, 2010 at 22:06
  • I believe its .bashrc not .bash_rc.
    – Setjmp
    Dec 29, 2010 at 18:17
  • @SetJMP fixed --more characters--
    – jamesbtate
    Dec 31, 2010 at 22:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .