Part of .bash_profile is not processed at start up

skottish · 2006-10-29 18:33:22

One last breakage to deal with. My system doesn't process part of my .bash_profile script. It sees the PATH directive, but it doesn't deal with LD_LIBRARY_PATH. I have to export it explicitly.

chrismortimore · 2006-11-01 13:28:59

Can you post said part of the .bash_profile to see how you've implimented it?

skottish · 2006-11-01 18:42:26

chrismortimore wrote:

Can you post said part of the .bash_profile to see how you've implimented it?

LD_LIBRARY_PATH=/opt/gimp-2.3/lib

export LD_LIBRARY_PATH

This is the same .bash_profile file I've had since I've built this system. It worked up until a few days ago. The system reads the PATH directive just fine.

chrismortimore · 2006-11-01 22:44:09

As a thought (and a workaround), you could put it into /etc/profile.d/, I have a few exports in /etc/profie.d/local.sh and it works fine.

As for the actual problem, don't have a clue, sorry.

Cerebral · 2006-11-01 22:56:24

What's the value of LD_LIBRARY_PATH after you log in? There may be a script in /etc/profile.d/ that unsets it - I'm not sure of the order of execution of scripts on login.

Can you post your entire .bash_profile?

skottish · 2006-11-02 00:33:12

Easy to debug!

. $HOME/.bashrc


PATH=/opt/gimp-2.3/bin:$PATH
LD_LIBRARY_PATH=/opt/gimp-2.3/lib

export PATH 
export LD_LIBRARY_PATH

The output of 'echo $LD_LIBRARY_PATH' is an empty string. As I said before, the system is picking up on the PATH directive.

I'll take a look at those scripts more closely, but so far I haven't seen anything.

This all happened with the whole DBUS-everything else upgrade, so there are a lot of possibilities.

Snarkout · 2006-11-02 14:56:15

Don't you need $ in front of those two variables for your export statements?

Cerebral · 2006-11-02 15:40:15

Snarkout wrote:

Don't you need $ in front of those two variables for your export statements?

Nope, he's exporting the variables themselves, not their contents.

Nothing wrong I can see with the profile - I wonder why it's not getting set.

Snarkout · 2006-11-02 17:09:58

OK, cool - I generally use the form

export VAR=whatever

so I wasn't sure.

skottish · 2006-11-03 01:56:47

Cerebral wrote:

There may be a script in /etc/profile.d/ that unsets it

Nope, there's no reference to LD_LIBRARY_PATH in any of those scripts.

The mystery continues...

chrismortimore · 2006-11-06 13:17:06

Can you post ~/.bashrc? I'm curious what is in it.
You could also try this:

. $HOME/.bashrc

export PATH=/opt/gimp-2.3/bin:${PATH}
export LD_LIBRARY_PATH=/opt/gimp-2.3/lib

echo ${PATH}
echo ${LD_LIBRARY_PATH}

Never know, it might shed some light...

skottish · 2006-11-08 12:44:13

chrismortimore wrote:

Can you post ~/.bashrc? I'm curious what is in it.
You could also try this:
. $HOME/.bashrc

export PATH=/opt/gimp-2.3/bin:${PATH}
export LD_LIBRARY_PATH=/opt/gimp-2.3/lib

echo ${PATH}
echo ${LD_LIBRARY_PATH}
Never know, it might shed some light...

My .bashrc file looks like this:

alias ls='ls --color=auto'
PS1='[u@h W]$ '

I tried with the brackets, and no information came to light. Something, somewhere, is unsetting this variable and I need to find it.

skottish · 2006-11-11 07:57:21

Sorry to bump...

This is a very significant break in core Linux functionality. Is anyone other than me having this problem?

Mr Green · 2006-11-11 10:08:52

just whacked your code into .bashrc got this come up

/opt/gimp-2.3/bin:/opt/gimp-2.3/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/X11R6/bin:/opt/bin:/opt/gnome/bin:/opt/java/bin:/opt/java/jre/bin:/opt/kde/bin:/opt/mozilla/bin:/opt/qt/bin:/opt/simias/bin:/opt/torcs/bin
/opt/gimp-2.3/lib

does not help you much but only shows that your code is ok ...

smoon · 2006-11-11 12:37:34

skottish wrote:

chrismortimore wrote:
Can you post ~/.bashrc? I'm curious what is in it.
You could also try this:
. $HOME/.bashrc

export PATH=/opt/gimp-2.3/bin:${PATH}
export LD_LIBRARY_PATH=/opt/gimp-2.3/lib

echo ${PATH}
echo ${LD_LIBRARY_PATH}
Never know, it might shed some light...
My .bashrc file looks like this:
alias ls='ls --color=auto'
PS1='[u@h W]$ '
I tried with the brackets, and no information came to light. Something, somewhere, is unsetting this variable and I need to find it.

I don't think something like that is happening. At least it seems impossible with code like

export VAR=foo
echo $VAR

since VAR would've been unsetted inbetween the two lines (and there's nothing (and not much time) to unset it). My guess is that your .bash_profile doesn't get sourced at all.
What happens if you make it look like that:

. $HOME/.bashrc

export PATH=/opt/gimp-2.3/bin:$PATH
export LD_LIBRARY_PATH=/opt/gimp-2.3/lib

echo "we're in"
echo PATH
echo LD_LIBRARY_PATH

Do you see the message "we're in" after logging in (besides, .bash_profile only gets executed after logging in, not after just spawning a new shell. But I think you're aware of that).

skottish · 2006-11-12 16:56:21

There's no doubt that the system is find .bash_profile like normal. The PATH environmental variable is being set:

[skottish@localhost ~]$ echo $PATH
/opt/gimp-2.3/bin:/bin:/usr/bin:...and the rest

I can also run 'source' from the command line it will set LD_LIBRARY_PATH for that session only (of course). It really seems like it's being reset by something, and not being missed at start up.

---------------->>>>>>>>> Edit <<<<<<<<<<--------------

There there is no doubt what-so-ever that it's being unset. I added the test cases to my script that Smoon suggested to see if I missed something, logged into the console instead of KDE, and LD_LIBRARY_PATH is set there. So something is unsetting it when KDE is booting.

smoon · 2006-11-12 17:37:32

skottish wrote:

[...]
There there is no doubt what-so-ever that it's being unset. I added the test cases to my script that Smoon suggested to see if I missed something, logged into the console instead of KDE, and LD_LIBRARY_PATH is set there. So something is unsetting it when KDE is booting.

How do you start KDE? Do you use a display manager for logging in or do you log in on a console and issue `startx'?

skottish · 2006-11-12 18:05:59

KDM boots at start up.

The strange thing about all of this is that it's new. When I created this thread it was the first time it ever happended. It was around the same time with the big DBUS upgrade, and also when I started to bring in 32 bits libraries to run Skype (64 bit Arch of course).

noriko · 2006-11-12 19:51:18

this is a long shot, but have u tried setting the vars in bashrc as opposed to _profile..
i had this issue once, along time ago.. switched to using bashrc instead, and somehow it werked .. don't ask, i'm still confused..

skottish · 2006-11-12 21:03:46

Ooops. I removed this last post because it was useless.

smoon · 2006-11-12 22:00:08

skottish wrote:

KDM boots at start up.
The strange thing about all of this is that it's new. When I created this thread it was the first time it ever happended. It was around the same time with the big DBUS upgrade, and also when I started to bring in 32 bits libraries to run Skype (64 bit Arch of course).

It should not work then since you won't get a login shell (rember, .bash_profile only gets sourced for login shells) at all if you login via KDM (see http://docs.kde.org/development/en/kdeb … #id2560053). You'll need to modify your session script to source .bash_profile manually.
Something like that should work:

...
case $SHELL in
  */bash)
    [ -f /etc/profile ] && . /etc/profile
    if [ -f $HOME/.bash_profile ]; then
      . $HOME/.bash_profile
    elif [ -f $HOME/.bash_login ]; then
      . $HOME/.bash_login
    elif [ -f $HOME/.profile ]; then
      . $HOME/.profile
    fi
    ;;
esac
...

Just using

#!/bin/bash --login

instead of

#!/bin/bash

for the shebang in your session script might work as well.

skottish · 2006-11-12 22:29:30

First off, thanks Smoon for taking so much time. I really appreciate it. Unfortunately the changes didn't help.

I do know for a fact that the file is being sourced at start up like it should be; The PATH from the file is set. Also, when I logged into the console before (when LD_LIBRARY_PATH took), I did it through KDM. I'm fully convinced that something is resetting the variable. Working around this problem was was as simple as editing ld.so.conf, but I would like the default behavior back.

Arch Linux

#1 2006-10-29 18:33:22

Part of .bash_profile is not processed at start up

#2 2006-11-01 13:28:59

Re: Part of .bash_profile is not processed at start up

#3 2006-11-01 18:42:26

Re: Part of .bash_profile is not processed at start up

#4 2006-11-01 22:44:09

Re: Part of .bash_profile is not processed at start up

#5 2006-11-01 22:56:24

Re: Part of .bash_profile is not processed at start up

#6 2006-11-02 00:33:12

Re: Part of .bash_profile is not processed at start up

#7 2006-11-02 14:56:15

Re: Part of .bash_profile is not processed at start up

#8 2006-11-02 15:40:15

Re: Part of .bash_profile is not processed at start up

#9 2006-11-02 17:09:58

Re: Part of .bash_profile is not processed at start up

#10 2006-11-03 01:56:47

Re: Part of .bash_profile is not processed at start up

#11 2006-11-06 13:17:06

Re: Part of .bash_profile is not processed at start up

#12 2006-11-08 12:44:13

Re: Part of .bash_profile is not processed at start up

#13 2006-11-11 07:57:21

Re: Part of .bash_profile is not processed at start up

#14 2006-11-11 10:08:52

Re: Part of .bash_profile is not processed at start up

#15 2006-11-11 12:37:34

Re: Part of .bash_profile is not processed at start up

#16 2006-11-12 16:56:21

Re: Part of .bash_profile is not processed at start up

#17 2006-11-12 17:37:32

Re: Part of .bash_profile is not processed at start up

#18 2006-11-12 18:05:59

Re: Part of .bash_profile is not processed at start up

#19 2006-11-12 19:51:18

Re: Part of .bash_profile is not processed at start up

#20 2006-11-12 21:03:46

Re: Part of .bash_profile is not processed at start up

#21 2006-11-12 22:00:08

Re: Part of .bash_profile is not processed at start up

#22 2006-11-12 22:29:30

Re: Part of .bash_profile is not processed at start up

Board footer