Section 12: PROGRAMMING

What programming languages can I use for IRAF software development?

	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.

Can I install IRAF or layered software without having IRAF permissions?

	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.

Can I call IMFORT procedures from C?

 	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.

Where are the IRAF libraries used by FC or XC for IMFORT tasks?

	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.

Can I build IRAF software without using FC or XC?

	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.

What Fortran compilers are supported?

      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.

Can I call IRAF tasks from Unix C-shell scripts?

	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.

I was wondering if you could provide a bit more info on how to use the new ability of the IRAF cl (#!cl) to act as a shell for Unix scripts.

 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.

Will IRAF work with the Korn shell or tcsh?

	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.