Problem installing external packages
jhargis wrote on Feb 05, 2016
I installed the 64-bit version of IRAF v. 2.16.1 on my Macbook Pro running Yosemite 10.10.5 successfully (I think), but for some reason the external packages will not load.
I followed the instructions to run ./configure from the extern/ directory and then ran "make mscred", for example. I get the following result, as expected:
% make mscred
Setting architecture: 'macintel' ....
Adding dependency 'fitsutil' ....
Installing package 'fitsutil' .... [OK]
Installing package 'mscred' .... [OK]
The .zzsetenv.def file also has entries:
% more .zzsetenv.def
refitsutil =/Users/jhargis/iraf/extern/fitsutil/
remscdb =/Users/jhargis/iraf/extern/mscdb/
remscred =/Users/jhargis/iraf/extern/mscred/
keep
However, when I start IRAF, the packages do not show up. Any ideas what might be causing this problem?
Mike Fitzpatrick wrote on Feb 11, 2016
This was reported by another user just a day after your post and I've been waiting to hear whether it was resolved. In that case, there was an existing Ureka installation on the machine and the suspicion was that some environment definition was confusing the value of the $iraf root directory actually being used. The same might also be true with SciSoft installed on the machine or if you used the 'install_helper' script available in some distributions from STScI. If you've used one of these systems in the past, check your .login/.cshrc or .profile/.bashrc files to see whether they source some environment file, or do a "show iraf" in the CL to verify the iraf root.
Your post does point out an error in the extern$.zzsetenv.def file (now fixed), but it isn't critical in defining the packages. Basically, at CL startup time calls the hlib$extpkg.cl script to scan the iraf$extern directory for packages and then creates the package definition on the fly. I haven't been able to reproduce any problems in package loading, but in the event something went wrong while installing (e.g. the disk filled up) that wasn't caught by the script, you can do a "make init" in the directory and then try reinstalling the packages with a new "./configure" and appropriate make command. Post back if you're still having problems.
jhargis wrote on Feb 11, 2016
Thanks for the quick reply. I did have a previous installation of Ureka, but that does not appear to be the problem. I did a full uninstall of both Ureka and IRAF and reinstalled IRAF from scratch. Unfortunately the problem with the external packages not showing up still persists. I tried doing a "make init" followed by "./configure", but this did not solve the problem.
The paths and environment variables appear to be correct:
$ echo $iraf
/Users/jhargis/iraf64/
ecl> show iraf
/Users/jhargis/iraf64/
$ more .zzsetenv.def
refitsutil =/Users/jhargis/iraf64/extern/fitsutil/
remscdb =/Users/jhargis/iraf64/extern/mscdb/
remscred =/Users/jhargis/iraf64/extern/mscred/
keep
Mike Fitzpatrick wrote on Feb 16, 2016
I never heard back from the other user whether this was resolved. I do notice that your example output uses the ECL which is not the default v2.16 version .... do you use a simple 'cl' command to start IRAF or do you explicitly start the ecl? If just 'cl', what does the command "which cl" return and is this a command link that points to the IRAF version you think you are using?
Also, you can try loading the package definitions manually using:
ecl> cl
jhargis wrote on Feb 16, 2016
I was starting IRAF using the "ecl" command, but this does not appear to make any difference. When I start IRAF with "cl", I get
NOAO/IRAF PC-IRAF Revision 2.16.1 EXPORT Mon Oct 14 21:40:13 MST 2013
This is the EXPORT version of IRAF V2.16 supporting PC systems.
Welcome to IRAF. To list the available commands, type ? or ??. To get
detailed information about a command, type `help <command>'. To run a
command or load a package, type its name. Type `bye' to exit a
package, or `logout' to get out of the CL. Type `news' to find out
what is new in the version of the system you are using.
Visit http://iraf.net if you have questions or to report problems.
*** Checking update status... Your IRAF system is up to date
*** Using global login file: /Users/jhargis/.iraf/login.cl
*** Initializing SAMP .... No Hub Available
The following commands or packages are currently defined:
dataio. language. obsolete. softools. vo.
dbms. lists. plot. system.
images. noao. proto. utilities.
vocl>
The results of "which cl" is:
% which cl
/Users/jhargis/.iraf/bin/cl
This points to
cl -> /Users/jhargis/iraf64/unix/hlib/cl.sh
Mike Fitzpatrick wrote on Feb 16, 2016
And so what happens if you do:
cl
jhargis wrote on Feb 16, 2016
If I type "cl" within IRAF, I get no changes:
*** Checking update status... Your IRAF system is up to date
*** Using global login file: /Users/jhargis/.iraf/login.cl
*** Initializing SAMP .... No Hub Available
The following commands or packages are currently defined:
dataio. language. obsolete. softools. vo.
dbms. lists. plot. system.
images. noao. proto. utilities.
vocl> cl
vocl> ?
dataio. language. obsolete. softools. vo.
dbms. lists. plot. system.
images. noao. proto. utilities.
vocl>
Mike Fitzpatrick wrote on Feb 16, 2016
Sorry, stupid forum text cut off the command:
cl < hlib$extpkg.cl
jhargis wrote on Feb 16, 2016
No problem. Here are the results:
vocl> cl < hlib$extpkg.cl
Duplicate definition of `curdir' ignored.
Duplicate definition of `extdir' ignored.
Duplicate definition of `dpkg' ignored.
vocl> ?
dataio. language. obsolete. softools. vo.
dbms. lists. plot. system.
images. noao. proto. utilities.
As you can see, the packages are still not loaded.
Mike Fitzpatrick wrote on Feb 16, 2016
I still can't reproduce the problem. Some things to try:
You can use the command:
ecl> ?? | match fitsutil STDIN
to see whether the FITSUTIL package is defined in any package (i.e. '??' lists all packages). If not, make sure that the hlib$extpkg.cl file contains a 'keep' statement at the very end, this is the thing that makes any definitions permanent. You can trace the execution of this script using the commands:
ecl> d_trace
ecl> cl < hlib$extpkg.cl
Because this is executed before the login process is complete, it uses a mix of host and CL commands. If you're logged into the CL you should be able to issue commands like
ecl> !pwdto print the current directory. Something funny going on in your .bashrc/.profile/.cshrc/.login file (e.g. are you prompted for input?) might explain why the script failed. Likewise, the command:
ecl> =osfn ("iraf$extern")would reveal problems in path names. The d_trace command will produce a lot of output but you should see the script process all the files found in the iraf$extern directory, if you're not sure how to read the output please post the result.
Last post on Feb 16, 2016