The native IRAF language is SPP (Subset Pre-Processor), a portable pre-processor language which resembles C. Tasks written in SPP will run on all supported IRAF platforms without change. Programming in SPP makes available the full facilities of the IRAF VOS (Virtual Operating System). Users may also program with the IMFORT interface, a library of subroutines for reading and writing OIF format images. IMFORT is written for use with Fortran, but a C language binding is available for Unix. In addition, the CL provides a scripting language which can be used to write high level tasks. Large applications are best written as compiled code for optimization, but scripts allow the user to build tasks upon existing software quickly.
An iraf user account is recommended for installing IRAF. IRAF is distributed with a login directory for "iraf" that includes environment definitions that make the installation go more smoothly. In addition, the iraf account is useful for maintaining the system locally, perhaps by more than one person, and for IRAF site support, should we ever need to log in and sort out a problem. It is not absolutely required that IRAF be installed by "iraf", but it is strongly recommended. Installing layered software for private use can be done by any user who simply declares the package in their loginuser.cl file as e.g.
reset nmisc = /iraf/extern/nmisc/ task nmisc.pkg = nmisc$nmisc.cl
Installing layered software to be used by all IRAF users should be done from the iraf account. It will be necessary to modify hlib$extern.pkg, owned by iraf, and in most cases reconfigure the package architecture, e.g.,
cl> mkpkg -p nmisc sparc
before building the binaries. Software development requires environment def- initions already set up for the default iraf user account.
Yes, a Unix C binding for IMFORT procedures is available from the IRAF network archive in the /iraf/misc directory as 'cbind.c'. To use this binding, compile an object module cbind.o and then link this with your C program. Further information can be found in /iraf/misc/cbind.readme.
The FC command is a foreign task defined in your login.cl that calls the IRAF XC compiler with appropriate flags and libraries, i.e.
task $fc = ("$" // envget("iraf") // "unix/hlib/fc.csh" // " -h $* -limfort -lsys -lvops -los")
The four required IRAF libraries are -limfort -lsys -lvops -los The first three of these libraries are in the bin$ directory, e.g., iraf$bin.ssun. The fourth library, libos.a, is in the hbin$ directory, e.g., iraf$unix/bin.ssun. All four libraries are required to build an IMFORT task successfully, as is the '-h' flag to XC. Platform dependent libraries are linked automatically by the XC task.
Most IRAF packages are written in the native SPP language, using 'mkpkg' files to build the packages. While it's possible to reconstruct the sequence of f77, cc, gcc, or ld commands that XC uses, it is much easier to just use XC. XC knows the IRAF root as well as the IRAF and host libraries that are required to build an executable. It is a bit easier to build an individual IMFORT task without using FC/XC, provided you know the path to the iraf root directory. For example, the XC command to build the example IMFORT task imheader is: % xc -h -o imhead.e imhead.f -limfort -lsys -lvops -los The FC command is a task alias defined in the login.cl that simply uses the above syntax to define the needed libraries. Since host level compilers don't know where to find the libraries, you need to explicitly name the path. For example, a cc command equivalent to the xc command above is: % cc -o imhead.e imhead.o /usr/iraf/bin.sparc/libimfort.a \ /usr/iraf/bin.sparc/libsys.a /usr/iraf/bin.sparc/libvops.a \ /usr/iraf/unix/bin.sparc/libos.a These library paths may also be used in Makefiles to compile tasks, but the user is responsible for including the platform-dependent libraries.
For all supported systems the native Fortran compiler for that system is used by default. For SunOS systems, the V1.3 and V1.4 compilers are currently the only supported versions, support for the V3 and V4 SUNPro compilers is only available under Solaris/IRAF. F2C/GCC is used on PC-IRAF systems only (w/ the F2C executable and library distributed as part of IRAF so no separate installation is required, it is assumed GCC is available on the machine). G77 is not currently supported on any platform, although it may work depending on the platform and software being compiled, contact site support if you have questions.
There are three ways to run an IRAF task outside of the CL, either invoke the executable directly with the correct command line arguments, run the CL with the input redirected to execute the task, or use the host CL scripting capability.
In the first case you must know in which executable the task resides, core IRAF system tasks (e.g. things in the PLOT and IMAGES packages) have their executables in the main $iraf/bin.<arch> directory, NOAO package tasks have the executables in the $iraf/noao/bin.<arch> directory. There is usually a separate executable for each package and you can probably figure out which one goes for each package otherwise just look at the package cl file to find out, for example the PLOT package defines the task in the $iraf/pkg/plot/plot.cl file, if you look in their you'll see that is defines the tasks as (part of the file reads) task contour, surface, hafton, velvect = "plot$x_ncar.e" which means that the CONTOUR, SURFACE, etc tasks are in the "x_ncar.e" exec- utable. Once you find the correct binary, you need to create a file with the task parameters: usually it's easiest to set the parameters and then dump the parameter file with 'dpar', e.g. cl> dpar listpix > listpix.par Then to run the task you would do something like: % $iraf/bin.sparc/x_images.e listpix @listpix.par In this case you must be careful that ALL of the task parameters are defined, this is done by 'dpar' but empty string parameters will be prompted for. In the second case you create a command file and input it to the cl, for example % cl < cl.input >& some_logfile where cl.input contains CL commands such as wfits.scale=no # set a parameter wfits image*.imh mta # call a task logout # logout of the CL You must be careful about making sure you are in the right directory and that parameters are given explicitly if they're like to change, but with this approach you can call any iraf task. In both cases you need to be careful about redirecting any input or output that is required, both text and graphics. You can redirect graphics output either by setting the "device" parameter to e.g. 'stdvdm' or using the '>G' syntax as in cl> surface dev$pix >G surf.plot cl> surface dev$pix dev="stdplot" # to print it out cl> surface dev$pix dev="stdvdm" # save metacode to uparm dir The host CL scripting capability is covered in another part of this FAQ.
Which of these approaches works best for depends depends on the tasks you need and the complexity of the script. Note that by using OS escapes in IRAF scripts it may be simpler to write an IRAF script to do the same thing.
Starting with V2.11.2 IRAF CL scripts have had the capability of being executed as host commands. This is still a primitive feature of the OpenIRAF project in development but is a functional part of the system. This page will evolve with more information as problems and tips are discovered and as this facility becomes a realistic part of programming systems using IRAF. See our web page at /iraf/web/new_stuff/cl_host.html for details and examples.
In general the choice of login shell for users shouldn't matter. All host-level scripts in IRAF are written using the C-shell, these should run as long as a C-shell is available somewhere in the system. Similarly, forked processes are run in the Bourne shell (such as the dispose commands in the dev$graphcap file) which must also be available.