Hi,
Should i add paths in $HOME/.bashrc or in /etc/bash.bashrc.local. Just before the last line in $HOME/.bashrc i added the following lines:
if -f ~/.my_bashrc ]; then
. ~/.my_bashrc
fi
(The above 3 lines were copied from my ubuntu 7.10’s .bashrc)
Then i created a file $HOME/.my_bashrc and added all the paths there.
Now i have a problem. Even if i comment a few lines in .my_bashrc, the paths are not forgotten by my bash shells that i open. I also added a few library paths in /etc/ld.so.conf. Is this causing a problem?
What do i do? I am unable to compile a program since the incorrect executables are being invoked.
First, in general there is a difference between parameters you set in your home directory and those you set somewhere inside /etc. The latter in general are mentioned for everybody in th system. The first is only for you when you log in.
I think you can now decide for yourself where you should put things.
Second, the three lines may be a ubunti speciality, but that does not matter. You can always write bash statements in your .bashrc and it simply says: when ther is a file of such name, execute the statments inside that file just here (sort of include).
Now about finding out what is going on, I suggest you add a few statements like
echo "Path before the calling of my_bashrc: $PATH"
at strategical places in files mentioned. Then you e.g. can see what PATH is before and after the invoking of .my_bashrc.
Also telling us what statements you use trying to influence your pathes might be usefull. At this moment we have to guess pretty much.
It is becoming a bit more clear to now, but you still levae some riddles. Wher are the echo $PATH statements I asked for? What do you mean by ‘open my bash shell’? Do you start a new terminal window or what?
What I am trying to find is the point where you are so convinced that it is OK that you not even think about telling me. Because most of the time the problem is just there (Years of experience in letting programmers explain their program, even if I do not know the programn language used, until they say: “Oh, that it is, how stupid”, then they go happily and I still do not know what it is all about!).
I guess i had used incorrect terminologies. I just open a terminal window.
I did not post the results of the echo $PATH command as i was and am still unsure of what you want. But i have added the same
echo "Path before the calling of my_bashrc: $PATH"
in $HOME/.my_bashrc and here is the output on opening a terminal window:
Path before the calling of my_bashrc: /home/samrat/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/gnome/bin:/usr/lib/qt3/bin:/usr/local/bin/matlab_7.3_2006b:/opt/intel/fc/10.1.018/bin:/opt/intel/cc/10.1.018/bin:/opt/intel/idb/10.1.018/bin:/usr/local/flex_2.5.3/bin:/usr/local/flex_2.5.3/include:/usr/local/cdo_1.2.0/bin:/usr/local/hdf_4.2r3/bin:/usr/local/hdf_4.2r3/include:/usr/local/hdf_5-1.8.1/bin:/usr/local/hdf_5-1.8.1/include:/usr/local/hdf-eos_2.14v1/include:/usr/local/jasper_1.900.1/bin:/usr/local/jasper_1.900.1/include:/usr/local/jasper_1.900.1/man:/usr/local/libdap_3.8.2/bin:/usr/local/libdap_3.8.2/include/libdap:/usr/local/libdap_3.8.2/sbin:/usr/local/libdap_3.8.2/share/aclocal:/usr/local/libnc-dap_3.7.3/bin:/usr/local/libnc-dap_3.7.3/include/libnc-dap:/usr/local/libnc-dap_3.7.3/share/aclocal/libnc-dap:/usr/local/netcdf_4.0/bin:/usr/local/netcdf_4.0/include:/usr/local/sed_4.1.5/bin:/usr/local/szip_2.1/include:/usr/local/udunits_1.12.9/bin:/usr/local/udunits_1.12.9/include:/usr/local/vis5d_1.3.0/bin:/usr/local/vis5d_1.3.0/include/vis5d+:/usr/local/bin/matlab_7.3_2006b:/opt/intel/fc/10.1.018/bin:/opt/intel/cc/10.1.018/bin:/opt/intel/idb/10.1.018/bin:/usr/local/flex_2.5.3/bin:/usr/local/flex_2.5.3/include:/usr/local/cdo_1.2.0/bin:/usr/local/hdf_4.2r3/bin:/usr/local/hdf_4.2r3/include:/usr/local/hdf_5-1.8.1/bin:/usr/local/hdf_5-1.8.1/include:/usr/local/hdf-eos_2.14v1/include:/usr/local/jasper_1.900.1/bin:/usr/local/jasper_1.900.1/include:/usr/local/libdap_3.8.2/bin:/usr/local/libdap_3.8.2/include/libdap:/usr/local/libdap_3.8.2/sbin:/usr/local/libdap_3.8.2/share/aclocal:/usr/local/libnc-dap_3.7.3/bin:/usr/local/libnc-dap_3.7.3/include/libnc-dap:/usr/local/libnc-dap_3.7.3/share/aclocal/libnc-dap:/usr/local/netcdf_4.0/bin:/usr/local/netcdf_4.0/include:/usr/local/sed_4.1.5/bin:/usr/local/szip_2.1/include:/usr/local/udunits_1.12.9/bin:/usr/local/udunits_1.12.9/include:/usr/local/vis5d_1.3.0/bin:/usr/local/vis5d_1.3.0/include/vis5d+
These paths remain unchanged even after commenting them.
Sorry for not being clear enough. The echo statements are there for making a sort of trace about what is happening. So the first echo should be in .bashrc before you start calling .my-bashrc and a second thereafter and maybe a third on another strategic place. This would look in .bashrc like:
echo "Path before the calling of my_bashrc: $PATH"
if -f ~/.my_bashrc ]; then
. ~/.my_bashrc
fi
echo "Path after the calling of my_bashrc: $PATH"
So we can see if those directories where already in the PATH before the famous three lines, and what are the results during the famouse three lines.
And reading through your now very long path (and through an earlier post), are you sure the directories with names /include should go in the PATH variable? Are there executables in thos directories?
You hit the nail on the head. Yes i am unsure of adding the paths like …/include. The include paths do not get added and while compiling any package i have to explicitly state the include paths. Could you tell my how to include the headers and libraries (till now i added the library paths by adding them in /etc/ld.so.conf and then running ldconfig, but some libs still do not get added).
Now the required entries in $HOME/.bashrc are:
echo "Path before calling of $HOME/.my_bashrc: $PATH"
if -f ~/.my_bashrc ]; then
. ~/.my_bashrc
fi
echo "Path after calling of $HOME/.my_bashrc: $PATH"
The outputs on opening a terminal window are:
Path before calling of /home/samrat/.my_bashrc: /home/samrat/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/gnome/bin:/usr/lib/qt3/bin:/usr/local/bin/matlab_7.3_2006b:/opt/intel/fc/10.1.018/bin:/opt/intel/cc/10.1.018/bin:/opt/intel/idb/10.1.018/bin:/usr/local/flex_2.5.3/bin:/usr/local/flex_2.5.3/include:/usr/local/cdo_1.2.0/bin:/usr/local/hdf_4.2r3/bin:/usr/local/hdf_4.2r3/include:/usr/local/hdf_5-1.8.1/bin:/usr/local/hdf_5-1.8.1/include:/usr/local/hdf-eos_2.14v1/include:/usr/local/jasper_1.900.1/bin:/usr/local/jasper_1.900.1/include:/usr/local/jasper_1.900.1/man:/usr/local/libdap_3.8.2/bin:/usr/local/libdap_3.8.2/include/libdap:/usr/local/libdap_3.8.2/sbin:/usr/local/libdap_3.8.2/share/aclocal:/usr/local/libnc-dap_3.7.3/bin:/usr/local/libnc-dap_3.7.3/include/libnc-dap:/usr/local/libnc-dap_3.7.3/share/aclocal/libnc-dap:/usr/local/netcdf_4.0/bin:/usr/local/netcdf_4.0/include:/usr/local/sed_4.1.5/bin:/usr/local/szip_2.1/include:/usr/local/udunits_1.12.9/bin:/usr/local/udunits_1.12.9/include:/usr/local/vis5d_1.3.0/bin:/usr/local/vis5d_1.3.0/include/vis5d+
Path after calling of /home/samrat/.sam_bashrc: /home/samrat/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/gnome/bin:/usr/lib/qt3/bin:/usr/local/bin/matlab_7.3_2006b:/opt/intel/fc/10.1.018/bin:/opt/intel/cc/10.1.018/bin:/opt/intel/idb/10.1.018/bin:/usr/local/flex_2.5.3/bin:/usr/local/flex_2.5.3/include:/usr/local/cdo_1.2.0/bin:/usr/local/hdf_4.2r3/bin:/usr/local/hdf_4.2r3/include:/usr/local/hdf_5-1.8.1/bin:/usr/local/hdf_5-1.8.1/include:/usr/local/hdf-eos_2.14v1/include:/usr/local/jasper_1.900.1/bin:/usr/local/jasper_1.900.1/include:/usr/local/jasper_1.900.1/man:/usr/local/libdap_3.8.2/bin:/usr/local/libdap_3.8.2/include/libdap:/usr/local/libdap_3.8.2/sbin:/usr/local/libdap_3.8.2/share/aclocal:/usr/local/libnc-dap_3.7.3/bin:/usr/local/libnc-dap_3.7.3/include/libnc-dap:/usr/local/libnc-dap_3.7.3/share/aclocal/libnc-dap:/usr/local/netcdf_4.0/bin:/usr/local/netcdf_4.0/include:/usr/local/sed_4.1.5/bin:/usr/local/szip_2.1/include:/usr/local/udunits_1.12.9/bin:/usr/local/udunits_1.12.9/include:/usr/local/vis5d_1.3.0/bin:/usr/local/vis5d_1.3.0/include/vis5d+:/usr/local/bin/matlab_7.3_2006b:/opt/intel/fc/10.1.018/bin:/opt/intel/cc/10.1.018/bin:/opt/intel/idb/10.1.018/bin:/usr/local/flex_2.5.3/bin:/usr/local/flex_2.5.3/include:/usr/local/cdo_1.2.0/bin:/usr/local/hdf_4.2r3/bin:/usr/local/hdf_4.2r3/include:/usr/local/hdf_5-1.8.1/bin:/usr/local/hdf_5-1.8.1/include:/usr/local/hdf-eos_2.14v1/include:/usr/local/jasper_1.900.1/bin:/usr/local/jasper_1.900.1/include:/usr/local/libdap_3.8.2/bin:/usr/local/libdap_3.8.2/include/libdap:/usr/local/libdap_3.8.2/sbin:/usr/local/libdap_3.8.2/share/aclocal:/usr/local/libnc-dap_3.7.3/bin:/usr/local/libnc-dap_3.7.3/include/libnc-dap:/usr/local/libnc-dap_3.7.3/share/aclocal/libnc-dap:/usr/local/netcdf_4.0/bin:/usr/local/netcdf_4.0/include:/usr/local/sed_4.1.5/bin:/usr/local/szip_2.1/include:/usr/local/udunits_1.12.9/bin:/usr/local/udunits_1.12.9/include:/usr/local/vis5d_1.3.0/bin:/usr/local/vis5d_1.3.0/include/vis5d+
As you can see (and i now realise) that there are problems of paths added before-hand and subsequent multiple entries.
That is what I was afraid of and what I wanted you to find out for yourself.
As I said earlier, the problem is not there where you think it is after you have stared at that point for such a long time. It is at a different place. Now, as I can not look littaraly over your shoulder, you are on your own again. I will give a few suggestions that I would try myself, one at a time and in no particular order.
Look if there are other files containing the names of the product directories e.g. /usr/local/hdf_5-1.8.1/hdf5_paths, thus:
grep '/usr/local/hdf_5-1.8.1/hdf5_paths' * .*
and inspect what comes out of this.
Put an echo statement (as we did before) in the very beginning of .bashrc. It is quite possible that PATH is already changed at a ‘higher’ level. Or check /etc/bash.bashrc and /etc/bash.bashrc.local. You can put echo statements there, BUT make a copy first, so you can restore after tests. Changing must be done as root of course.
Put echo statements at other strategical places (before and after other source or . statements) in .bashrc. And what about .profile (I am not quite sure when that is used in bash).
BTW: And what about all those ‘include’ directories?
This file .recently-used.xbel is about 22000 lines. I do not understand well what the output means.
I have tcsh installed as well. So on opening a terminal if i type:
tcsh
the behaviour of the terminal correspondingly changes but when i subsequently type:
echo $SHELL
i get the output as:
/bin/bash
And i type the next command as:
echo $PATH
all the paths are repeated twice as though .my_bashrc has been read by the tcsh shell itself. Perhaps as you said, PATH is changed at a higher level, i wonder where.
The …/include paths were added because i thought that in this way i can add the paths to the headers as well. But they do not get added. I do not know which variable to be modified, and yes i will remove them from path.
Hm, the .recently-used.xbel, whatever it may be, does not fumble around with PATH. I think is is innocent in this crime
I now go for dinner but I keep on thinking. In the meantime try to find something in /etc. You could try the grep there also, but sometimes config files are in a lower directory, grep will not search there.
Do you have another user on your system then the one you use now? Then log in as that user and see what PATH is there. No need to log out of the GUI, simply start a terminal and type
This seems right. Since ‘temp’ logged in from a login shell, /etc/profile was read. The same is not true when i open a terminal. I do not know which file is read first because…
In /etc/bash.bashrc, right at the top ie before the 1st executable statement, i added the code
echo $PATH
and viola! all the paths were there. Even though i removed the /include paths from $HOME/.my_bashrc, they were still very much there. So where are the paths being added?
There is a $HOME/.profile for me, but the same is read only if one logs in from a login shell.
The new user does not have a PATH which is already infested. Conclusion: it is not centrally done (in /etc/bashrc or so). Hope we are right here
At the top of .bashrc the PATH is already ‘wrong’. Of course not via .my_bashrc.local because that is reached lower down .bashrc (am I right?).
Next test. Start a terminal and start a new login shell for yourself. That goes the same as the su - temp you did earlier but with your won username instead of temp. I pointed to the - earlier. That - means that it must be a login shell. And again, after login, we want to know what the PATH is.
BTW, when pasting the answer to echo $PATH in your post, could you surround it by CODE] /CODE] tags (either by hand or by selecting that piece of text and then clicking the # button in the upper part of the message field)? With such a long PATH it makes reading more bearable. (When doing by hand, do omit the spaces after the , they are here only for visibility)
And then a loose remark from you saying that .profile is read-only. It should not be (but it does not matter as long as you do not want to change things in there). Can you give the output of
The problem seems to have disappeared by itself. Today when i rebooted my computer, the paths were correctly set ie before calling $HOME/.my_bashrc, the paths were the default openSUSE paths and after the call to $HOME/.my_bashrc, the new paths were added. And so no repetitions. This may be a bug and i wish to report it.
My understanding is that as far as openSUSE is concerned, /etc/profile and $HOME/.profile are read if one uses the bash shell as a login shell (please excuse my incorrect terminologies). If i have used bash interactively, then /etc/bash.bashrc and $HOME/.bashrc are read.
Second, it seems to be gone without we know why and that is a little frustrating.
Three, you terminology is allright. And I add to what malcolmlewis said that there is also a login shell as you realy login into the CLI /terminal as is the case when you ue su - (as we did before) and as you use the real console (logical screen #1) and the other logical screens #2 - #6. Or when you run in a runleven lower then 5, which leaves you with the console only.
Four, the ls -l .profile shows this as being as it should be. You can write and thus change by an editor your own .profile. In fact is has changed 12 november 2008 at 00:06 (your local time).
Five, it will be difficult to file a bug about something that you can not reproduce. I am afraid you can not reproduce because we do not even know how it went away.
Six, you can not file bugs in this forums. We are only a bunch of users that try to help other users. We are not developpers.
Seven, it has been a pleasure for me to try to help you and at least we found some ineterresting things. I hope this thread gave you an idea on how to attack the sort of problems you have.
Do not hesitate to ask for more help in the future in these forum if needs arise.
My belief that the problem has disappeared was premature. It appears and disappears as though it has a life of its own. Though the ~/.profile is being read, as you say, i don’t think that the statements are being executed, since i added
echo $PATH
at strategic locations in ~/.profile and found nothing on my terminal.
Now that i am once again having repetitions of the paths i.e. paths already being present before the call to ~/.my_bashrc, i added
echo $PATH
as the 1st statement in /etc/bash.bashrc and found that if i open a terminal, all the paths are present (i commented the call to ~/.my_bashrc).
On the other hand if i use
su - samrat
, just the default openSUSE paths are present. Something is wrong somewhere. What is the next step?
but I keep on thinking. In the meantime try to find something in /etc. You could try the grep there also, but sometimes config files are in a lower directory, grep will not search there.