I will address your posts in the order posted.
1.) I can not get a consistant declaration of LD_LIBRARY_PATH, commands either side of the "Add ISISLIB to LD_LIBRARY_PATH" section of the isispgmdef script seem to take without problem. I can manually set the LD_LIBRARY_PATH to $ISISLIB and export it and qview works. But can't seem to configure the .bash_profile and scripts to retain the variable.
I have found the behavior of the the bash shell when starting interactive and non-interactive shells a bit odd (I am not a Bash shell user, your YMMV). Interactive shells execute .bash_profile, non-interactive do not. Both, however, execute .bashrc. Hence, that is where I suggest you put the ISIS startup commands.
2.) should the IDL_PATH variable end up set as
$ISISIDL is correctly declared, is there some impact if I comment out the <IDL_DEFAULT> assignment, or could it be set it to the IDL install path.
This is exactly how it is set in isispgmdef. Note that you used to have to execute the IDL setup routines first (ex:, . /usr/local/rsi/idl/bin/idl_setup.bash), but I do not believe that is the case any longer. <IDL_DEFAULT>
is critical because that is internallly recognized within IDL and is used to include the IDL intrinsic directories/paths upon execution. If you just set IDL_PATH excluding it, some things cease to function properly (DLMs, for example). As far as I am concerned, that is the proper, (IDL) documented way to initialize IDL_PATH incorporating your own S/W.
3.) Finally, I think there may be a logic flaw in the "Adjust the path variable to include ISIS executables" section. The sh version of the script tests NOT $USERTAEBIN while the csh version has the correct test EXISTS $USERTAEBIN. This results in an incorrect PATH delcaration when the NULL $USERTAEBIN is appended to the PATH. A pair of :: mid path. It disapears when I fix the test.
You are correct. I have fixed this issue and attached a new Bash-compatable isispgmdef
file. It lives in $ISISR/sys/sh.
Now...on to your second post...
But, I think I've corrected the LD_LIBRARY_PATH problem by not using it, Instead creating a /etc/ld.so.cache entry for the $ISISLIB. However, I'm not sure if I'll need to apply same adjustment for TAE, PERL, SPICE, or PICO apps. Doesn't seem like I'd need to since the LD_LIBRARY_PATH was only pointed to $ISISLIB.
I highly discourage the use of the Linux runtime cache for ISIS installations. I generally feel that resource is for system installations only, i.e., root. ISIS is not, and should not, be installed as root for mainly for security reasons. LD_LIBRARY_PATH usage is appropriate and adequate for ISIS installation and use. It is designed to be installed by individual users if need be. Using the runtime loader cache causes ISIS libraries to have system, global scope to users/developers. This is entirely unnecessary and, some would argue, undesireable. It could also lead to problems with ISIS upgrades.
That said, I believe part of your problem is where you put the ISIS startup commands as I mentioned earlier. I have just completed testing on my system and it works just fine with me reproducing only the $USERTAEBIN error.
I would suggest that you create an isis_profile file that contains the pertinent ISIS startup commands, place that in your home directory and use the following logic in your .bashrc:
if [ -f $HOME/isis_profile ]; then
Here is the contents of my isis_profile (note that yours may be totally different and is obviously dependant on your ISIS installation):
# Contents of isis_profile
if [ -f $ISISR/sys/sh/isispgmdef ]; then
if [ -f $TAE/bin/sh/taesetup ]; then
And everything looks good. BUT THE EXPORT does not persist and from another terminal LD_LIBRARY_PATH is again not set. Perhaps it is something with selinux, or just a Fedora quirk.
That could very well be an issue. We do not have Fedora installed locally so we do not routinely test this Linux installation. We cannot say how ISIS, including the initialization and system interaction, will behave on Fedora.
If you are trying it in another terminal and it is invoked as xterm&
or something of that nature, the ISIS commands are not being executed if they are in .bash_profile...it is not a login
shell which executes .bash_profile...non-interactive shells, xterms spawned as a subprocess or child, minimally execute .bashrc.
echo $ISISLIB > usgs-ISIS-i386.conf #any name is fine but it must be a .conf extension
/sbin/ldconfig #lto rebuild cache, log out and back in to clear any processes
That looks to fix things. To be neat I've commented out the ISISLIB to LD_LIBRARY_PATH entry in the isispgmdef script.
Again, I do not recommend this approach. See the above discussion.
For the developers, do you see any gothca's in this approach?
Yes. If you are not getting LD_LIBRARY_PATH exported properly, chances are that you are not getting any other ISIS environment variables exported as well. Many of these and others (e.g., TAE, SPICE, PGPLOT) are critical to ISIS development, if that is what your intent is.
Try these suggestions and let us know how you fair.