Welcome to iraf.net Friday, March 29 2024 @ 08:29 AM GMT


 Forum Index > Help Desk > Systems New Topic Post Reply
 Problem installing external packages
   
jhargis
 02/05/2016 09:25PM (Read 3047 times)  
++---
Junior

Status: offline


Registered: 02/19/2007
Posts: 28
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:

PHP Formatted Code

% make mscred
Setting architecture: 'macintel' ....
Adding dependency 'fitsutil' ....
Installing package 'fitsutil' ....  [OK]
Installing package 'mscred' ....  [OK]
 


The .zzsetenv.def file also has entries:

PHP Formatted Code

% 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?

 
Profile Email
 Quote
fitz
 02/11/2016 06:47AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
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.


 
Profile Email
 Quote
jhargis
 02/11/2016 02:18PM  
++---
Junior

Status: offline


Registered: 02/19/2007
Posts: 28
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:

PHP Formatted Code

$ 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
 

 
Profile Email
 Quote
fitz
 02/16/2016 01:35PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
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\$this->_split2($m[0]) cl

 
Profile Email
 Quote
jhargis
 02/16/2016 03:49PM  
++---
Junior

Status: offline


Registered: 02/19/2007
Posts: 28
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

PHP Formatted Code

   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 https://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:

PHP Formatted Code

% which cl
/Users/jhargis/.iraf/bin/cl
 


This points to

PHP Formatted Code

 cl -> /Users/jhargis/iraf64/unix/hlib/cl.sh
 



 
Profile Email
 Quote
fitz
 02/16/2016 03:53PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
And so what happens if you do:

cl

 
Profile Email
 Quote
jhargis
 02/16/2016 03:55PM  
++---
Junior

Status: offline


Registered: 02/19/2007
Posts: 28
If I type "cl" within IRAF, I get no changes:

PHP Formatted Code

 ***  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>
 

 
Profile Email
 Quote
fitz
 02/16/2016 03:56PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
Sorry, stupid forum text cut off the command:

cl < hlib$extpkg.cl

 
Profile Email
 Quote
jhargis
 02/16/2016 04:45PM  
++---
Junior

Status: offline


Registered: 02/19/2007
Posts: 28
No problem. Here are the results:

PHP Formatted Code

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.

 
Profile Email
 Quote
fitz
 02/16/2016 05:19PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
I still can't reproduce the problem. Some things to try:

You can use the command:

ecl\$this->_split2($m[0]) ?? | 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:

PHP Formatted Code

    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

PHP Formatted Code
ecl> !pwd


to 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:

PHP Formatted Code
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.



 
Profile Email
 Quote
   
Content generated in: 0.48 seconds
New Topic Post Reply

Normal Topic Normal Topic
Sticky Topic Sticky Topic
Locked Topic Locked Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Anonymous users can post 
Filtered HTML Allowed 
Censored Content 
dog allergies remedies cialis 20 mg chilblain remedies


Privacy Policy
Terms of Use

User Functions

Login