maravelias.info

IRAF has become lately available through Debian‘s repositories. So I was curious to see how it works. But I was missing the right moment. About a month ago, I finally found the proper motivation so I went on to install it. As always … there were a few, minor, problems. Thanks to John K. we were able to resolve them! What follows is a small guide of what I faced during the installation (on a Debian 10/Buster).

Instead of previous (relatively) easy solutions to install IRAF now you can just do:

sudo apt-get install iraf

And the magic happens! It is typical to “mkiraf” then to build the necessary login.cl file. And that’s the very first problem as there is no such a thing (try mkiraf and you will get nothing).

Fortunately, mkiraf is not that necessary as the login.cl is just an ascii file with some default parameters set. We can easily copy such a file from another machine and we can put it here (under a proper directory, typically I create one under home, such as /home/user/iraf/). In all cases, what we need to change is the first few lines:
set home = "/home/user/iraf/"
set imdir = "home$images"
set cache = "home$cache"
set uparm = "home$uparm/"
set userid = "user"

where you replace the user with your username (or you put the appropriate path in the first line, and your username in the last one).

Another key feature is the shell used (typically xterm, xgterm, …). The original login.cl file will have already something (as the shell type is asked when IRAF is set with mkiraf), similar to:
# Set the terminal type. We assume the user has defined this correctly
# when issuing the MKIRAF and no longer key off the unix TERM to set a
# default.
if (access (".hushiraf") == no)
print "setting terminal type to 'xterm' ..."
stty xterm

Either you do not need to do anything (if you have xterm installed already) or you place the shell you are using.
Do not edit anything else from the rest of the file as these are the default IRAF parameters.

[NOTE: copy a fresh login.cl after running mkiraf, else you may end up with a version of a file with modified parameters set by the owner – although you should be always careful to ‘unlearn’ the commands and check the parameters used!)

Then you should be ready to use IRAF! Typing the usual “cl” or “ecl” unfortunately doesn’t work¹ (and it is a bit frightening at the beginning). But with this installation you just do “irafcl” and the normal ecl terminal starts immediately (nice!).

However, ecl is not that convenient, so we urgently needPyRAF. This can be easily installed through pip:

pip install pyraf
pip3 install pyraf

(for Python 2 and 3, respectively). Now even though pip instals all files under separate dirs it builds only one binary under ~/.local/bin/pyraf. So if you installed PyRAF for python2 first, you will see it running properly when using python2. If you add also pip3 version then you will notice that only PyRAF for python3 is available. Frustrating? You bet!

After some exploration we figured out that PyRAF creates only one binary so it overwrites the previous one. Although we tried to change the name and see if it can run individually this didn’t work (for whatever reason … probably bound to something else?). So there is no way (I wonder?) that you can have PyRAF for both Python versions. [Before asking why to keep both versions, keep in mind that somebody may want to use scripts from older versions! ]

The (not at all convenient) solution found so far is to:

1. install first PyRAF for Python v2
2. rename the pyraf binary (~/.local/bin/pyraf) to something else (e.g. pyraf-v2, this is only a back up as it doesn’t work even if you call it explicitly)
3. install PyRAF for Python v3
4. keep the pyraf binary as it is (for use with Python 3)
5. change the names accordingly if you want to use the older version

[There is another package python3-pyraf that I didn’t test², as I tend to keep as clean as possible Python’s installations by using pip only.]

However, even after that PyRAF may still not run properly. For example:
user@mymachine:~$ pyraf

Your “iraf” and “IRAFARCH” environment variables are not defined and could not
be determined from /usr/local/bin/cl. These are needed to find IRAF tasks.
Before starting pyraf, define them by doing (for example):

setenv iraf /iraf/iraf/
setenv IRAFARCH linux

at the Unix command line. Actual values will depend on your IRAF installation, and they are set during the IRAF user installation (see iraf.net), or via Ureka installation (see http://ssb.stsci.edu/ureka). Also be sure to run the “mkiraf” command to create a logion.cl (http://www.google.com/search?q=mkiraf).

What is missing now is to define these environment variables properly. You can either type the following lines in the terminal or add them to your .bashrc file, so that PyRAF is available at all times:

export iraf='/usr/lib/iraf/'
export IRAFARCH='linux'

Another working IRAF/PyRAF environment has been deployed!

17/7/2019 Update: Check olebole’s comment below regarding points 1 and 2.

Does it seams that IRAF is getting too much time to start? And if it starts do you see cannot access host 'iraf.noao.edu:80' ?

If yes, then if you also try iraf.noao.edu then you will notice that it does take too much time to open (if…it opens!). So, in this case the server is down and IRAF cannot access it. But why IRAF tries to connect to the website? After all we just need it to run some tasks.

After v2.16 they have included in the login.cl a line which checks for updates. To avoid this the solution is just to comment the line which includes the ‘ckhupdate’ command in the login.cl, e.g.

#============================================================================
# Check for updates to the system
# chkupdate

# Notify the user if we're using the global login.
path (".") | scan (s1)
if ( osfn("home$") != substr (s1, strldx("!",s1)+1, strlen(s1)) ) {
printf (" *** Using global login file: %slogin.cl\n", osfn("home$"))
}
;


Definitely this is not new, but since I have seen this message a couple of times in the past (without looking into any further) and I had performed some installations yesterday, I got a bit worried if something broke. Fortunately not! So, a note of what I changed is a probable useful future tip!

Without login.cl iraf/pyraf does not work properly. Some commands may execute (like zerocombine, ie the binaries) but when the command will need to retrieve some information (like wavelength calibration/plotting, even shell commands like ls ) it will not respond (see error examples below).

IRAF: Select a directory (like user’s home) and “mkiraf” (type it in a terminal) in this. This creates the login.cl and uparm directory. Then you should always start iraf from that directory (one of the main drawbacks).

PyRAF: Make an iraf directory (at user’s home) and inside this “mkiraf”. Then you can start pyraf from any directory (as it will always find the iraf directory previously created to search for parameters and settings). When you first run pyraf it will also create a pyraf directory (including a cache directory)

PyRAF errors (showing that a login.cl file is missing):
--> epar ccdred
...
File "/scisoft/lib/python2.5/site-packages/pyraf/iraffunctions.py", line 3051, in _expand1
(varname, instring))
IrafError: Undefined variable `uparm' in string `uparm$imdccdred.par'

--> ls
Traceback (innermost last):
File "", line 1, in
NameError: name 'ls' is not defined