path: root/doc/cluser.tex

%pagelayout{normal,twoside}
%\textheight 8in \textwidth 6in\topmargin 0.0in
%\documentstyle{article,11pt}

\documentstyle[11pt,twoside]{article}

\setlength{\textheight}{8in}
\setlength{\textwidth}{6in}
\setlength{\topmargin}{0in}
\oddsidemargin 0pt
\evensidemargin 0pt
\hyphenation{pre-sents}
\parskip 4pt

\begin{document}

\font \smcaps=amcsc10
\font \bldcn=ambc12
\font \eighttt=amtt8

\newcommand{\filename}[1]{{\tenrm#1}}
\newcommand{\key}[1]{\fbox{\eighttt#1}}
\newcommand{\emphasize}[1]{{\sl#1\/}}
\newcommand{\irafname}[1]{{\bf#1}}
\newcommand{\taskname}[1]{{\sl#1\/}}
\newcommand{\reference}[1]{{\it#1\/}}
\newcommand{\comptype}[1]{{\tt#1}}
\newcommand{\usertype}[1]{{\bldcn#1}}
\newcommand{\upa}{{\tt \char94}}
\newcommand{\lbox}{{\tt \char91}}
\newcommand{\rbox}{{\tt \char93}}
\newcommand{\bsl}{{\tt \char92}}
\newcommand{\pipe}{{\tt |\ }}
\newcommand{\pluseq}{$+\!=$}
\newcommand{\minuseq}{$-\!=$}
\newcommand{\timeseq}{$*\!=$}
\newcommand{\diveq}{$/\!=$}
\newcommand{\concateq}{$//\!=$}
\newcommand{\ppind}{\hspace*{17pt}}

\begin{titlepage} \vspace*{1.0in}

\begin{center} \huge
DRAFT\\ \vspace*{0.5in} \large \bf

A User's Introduction to the IRAF Command Language \\ \medskip
Version 2.3 \\

\bigskip

\smcaps Peter MB Shames\\
\tenrm Space Telescope Science Institute\\
\medskip
\smcaps Doug Tody\\
\tenrm National Optical Astronomy Observatories\\
\vskip 1cm

Revised  -- \today\\ \vskip 1cm

\bldcn ABSTRACT\\ \medskip
\end{center} \large

\begin{quotation} \noindent
This tutorial introduction to the IRAF Command Language
presents an overview of the use and features of the language.
The discussion is aimed toward the first-time
user and describes the execution of tasks from the Command
Language.  The focus is the Command Language itself;
the many packages and tasks that compose the IRAF system and the 
SDAS packages from STScI are described elsewhere.  The emphasis is
on using the Command Language to run existing programs, although
sections are included that describe the addition of new tasks
of one's own making. A quick guide to language features and facilities
and to the suite of reduction and analysis packages currently available
is provided in the Appendices.
\end{quotation}
\end{titlepage}

\pagestyle{empty}
\newpage
\thispagestyle{empty}

\begin{center} \vspace*{1in}
\large About the Authors
\end{center}
\vskip 1cm
\rm

\noindent
Peter Shames is Chief of the Systems Branch at STScI, and along with Jim Rose
and Ethan Schreier, was one of the key persons responsible for the selection
of IRAF as the command language and operating environment for the STScI
Science Data Analysis System (SDAS) in December of 1983.  Since that time,
Peter has supervised the VMS/IRAF development effort at STScI, overseeing the
implementation of the VMS/IRAF kernel, the initial port of IRAF to VMS,
and the development of version 2.0 of the IRAF command language.
Peter wrote the original CL User's Guide (version 2.0).

\vskip 0.5cm
\noindent
Doug Tody is the originator and designer of the IRAF system (including the CL)
and has been Chief Programmer of the IRAF project since the inception of the
project at KPNO (now NOAO) in the fall of 1981.  As Chief Programmer, Doug has
written virtually all of the IRAF system software with the exception of the
VMS/IRAF kernel and the original CL 1.0 (which was written by Elwood Downey).
Since 1983 Doug has been head of the IRAF group at NOAO, overseeing the
development of the NOAO science applications software while continuing work
on the IRAF systems software, and coordinating the effort with STScI.

\newpage
\thispagestyle{empty}

\begin{center} \vspace*{1in}
\large Acknowledgements
\end{center}
\vskip 1cm
\rm

\noindent
The authors wish to acknowledge the efforts of the many people who have 
contributed so much time, energy, thought and support to the development 
of the IRAF system.  Foremost among these are the members of the IRAF
development group at NOAO (Lindsey Davis, Suzanne Hammond, George Jacoby,
Dyer Lytle, Steve Rooke, Frank Valdes, and Elwood Downey, with help from
Ed Anderson, Jeannette Barnes, and Richard Wolff) and members of the VMS/IRAF
group at STScI (Tom McGlynn, Jim Rose, Fred Romelfanger, Cliff Stoll,
and Jay Travisano).  The sharp editorial eye and sharper pencil of
Chris Biemesderfer have made major contributions to the clarity and style
of this document.

\vskip 0.3cm
\noindent
The continuing patience and understanding of members of the scientific
staff at both institutions has been essential to the progress that has
so far been achieved.  A major software project such as IRAF cannot
be attempted without the cooperation of many individuals, since the
resources required must inevitably place a drain on other activities.
In particular, the support and encouragement of Harvey Butcher,
Garth Illingworth, Buddy Powell, Steve Ridgway and Ethan Schreier has
been invaluable.  Mention should also be made of Don Wells, who started
in motion in the latter part of the last decade the process which eventually
led to the creation of the IRAF system.

\begin{flushright}
Peter Shames \\
Doug Tody 
\end{flushright}

\clearpage 
\pagestyle{myheadings}
\markboth{CL User's Guide (DRAFT)\hspace*{2.1in}}
	 {\hspace*{2.1in}CL User's Guide (DRAFT)}
\pagenumbering{roman}

\tableofcontents

\thispagestyle{empty}
\newpage

\pagestyle{myheadings}
\markboth{CL User's Guide (DRAFT)\hspace*{2.1in}}
	 {\hspace*{2.1in}CL User's Guide (DRAFT)}
\pagenumbering{arabic}

\begin{center} \vspace*{0.5in} \large \bf

A User's Introduction to the IRAF Command Language \\ \medskip
Version 2.3 \\

\bigskip

\smcaps Peter MB Shames\\
\tenrm Space Telescope Science Institute\\
\medskip
\smcaps Douglas Tody\\
\tenrm National Optical Astronomy Observatories\\
\vskip 1cm

\end{center} \rm

\section*{How to use this book}

\ppind
This document is an introduction to the IRAF
Command Language (CL), and is designed to be a tutorial
for the first-time user.  The examples presented in the text can
(and should) be tried at a terminal.  Although this text is
large enough to be a bit daunting at first, it can be tackled
in easy stages, and need not all be read before trying the system.  
A basic knowledge of computer systems is assumed.

The first three chapters form an introductory section
which covers the most basic elements of IRAF.  Reading through these,
preferably while seated near a terminal where the examples may be tried 
out, is the recommended entry into the IRAF world.  The fourth and fifth 
chapters deal with the interface between IRAF and the host system,
and with some of the more advanced uses of IRAF for normal data
analysis activities.  These chapters will be of use once you are familiar
with the basic environment and the examples here are also designed
to be tried out on a live system.  The rest of this document is for the
more adventurous user, who is not happy until he can say \usertype{doit}
and get \irafname{it} done to a turn.  Try some of these last examples
when you are ready to customize IRAF for your own particular uses.

In spite of its size, this document
is not intended to be a complete guide to using and programming 
the IRAF system, but is an introduction to many of the functions
of the CL and a quick guide to other sources of more detailed information.
The CL is described as the user's interactive interface to the system,
and simple commands that use the terminal for starting and controlling tasks
and for customizing the environment are presented.
Development of simple functions in the CL are covered briefly here, but
coverage of all the details of programming in the CL or in the
IRAF environment is beyond the scope of this document.
A reasonable amount of documentation is accessible at the terminal via
the online help facilities, which are described here as well.

More extensive details of the CL may be found in the manual pages for the
\taskname{language} package, in the \reference{CL Programmer's Manual} and
in \reference{The IRAF User's Guide}.
Details of programming in the IRAF system itself are described 
in the \reference{Programmer's Crib Sheet for the IRAF Program Interface}, 
in the \reference{Reference Manual for the IRAF Subset Preprocessor Language}
and in other documents referred to in the last section of this text,
however, these documents are somewhat dated and most of the documentation
planned for the IRAF programming environment remains to be written.
Documentation in the form of manual pages for the suites of applications
packages being developed at both NOAO and STScI are available both online
and in printed form.

\section{Introduction}

\subsection{An Overview of IRAF}

\ppind
The Image Reduction and Analysis Facility (IRAF) has been designed to
provide a convenient, efficient and yet portable system
for the analysis of images and other classes of data.  While the
system has been designed for image data, and for astronomical image data
in particular, it has general facilities that can be applied to many
other classes of data.  Some of the functions that are
provided are quite specialized, dealing as they do with the 
characteristics of specific instruments, but others are generalized
functions for plotting data, computing statistics, processing lists, and
performing other functions that are common to
data processing tasks in many other fields.

The runtime IRAF system consists of four basic pieces:

\begin{itemize}
\item Command Language - which provides the user interface to the system.

\item Applications Packages - that are the real data analysis algorithms.

\item Virtual Operating System (VOS) - which is the heart of the portable
system and provides the foundation for all the higher level functions.

\item Host System Interface (HSI) - the interface between the portable IRAF
system and a particular host system.  At the heart of the HSI is the IRAF
\irafname{kernel}, a library of host dependent primitive subroutines that
connects the system independent VOS routines to the host operating system.
Each host system requires a different kernel, hence we speak of the UNIX/IRAF
kernel, VMS/IRAF kernel, and so on.
\end{itemize}

\noindent
All of these interconnected, yet separable, subsystems
act together to form the IRAF data analysis environment.  In
most cases the user need not be further concerned with this structure,
except to understand that the specific part of this structure that
this tutorial addresses is the Command Language or CL.

IRAF is designed as an open system that can be extended to add
new analysis capabilities, and that can support user customization
of the existing facilities.  There are several levels of customization
available, that range from tailoring task parameters to special needs;
through "re-packaging" existing functions into application specific tasks;
and extending to installation of new compiled code tasks in the
environment.  There are a variety of facilities provided in IRAF
to assist the user in the creation and installation of such new tasks.
It is not  \emphasize{essential}
that all of these functions be performed in the IRAF way, but full
integration of a user task within the IRAF environment can best be 
accomplished by using the facilities that are provided.  However,
even without the use of the IRAF interfaces, other tasks may be
incorporated into the user's operating environment and 
used as if they were part of the distributed system.

The applications packages and the VOS routines are designed to be
rather stable, and have been coded in the IRAF SPP language for
portability.  The kernel layer supports portability across
operating system architectures, and its interface is stable, but
the inner details change as a function of the requirements and
capabilities of the host operating system.  The CL is also 
rather stable, since it forms the user's interface to the system,
but it is also an area where change is anticipated, as the system evolves
to meet the needs of the users.  Because the CL is itself a program
that is supported by the VOS and isolated from the rest of the system
by the VOS, it can be evolved as required without perturbing the other
parts of the system.

\subsection{Function of the Command Language}

\ppind
The basic function of the Command Language is to 
provide a clean, consistent interface between the user and the various
packages of functions that complete the IRAF environment.
The CL provides an interface between the user and all applications
programs, giving the user complete control over the parameters, data, and
system resources (graphics devices, etc.) used by IRAF programs.
Many features have been incorporated into the CL to provide
on-line support for users, whether they are old hands or new to the system. 

The packages of programs that are provided offer
many of the standard functions for data analysis, and they can 
be invoked interactively, one at a time, to perform many common 
operations.  The execution of these functions is controlled
by various parameters, and users may define their
own values for the parameters as required.  IRAF preserves the 
last value used, and presents it as the default value upon next
use.  Furthermore, there are facilities at several levels to allow
users to assemble existing functions into new tasks that perform
the specific operations on their data sets.  This
customization can involve new assemblages of existing functions
or the inclusion of new functions written in the interactive CL
language or in compiled languages.

The CL will primarily be used as a \emphasize{command} language, 
but it is also an interpreted \emphasize{programming} language.
To be a good  \emphasize{command} language, the CL must make
it as easy as possible to enter commands that perform common functions.
To this end the CL provides command menus, minimum-match name abbreviations,
parameter prompting and parameter defaults, tutoring on command parameters
and options, and a concise syntax for simple commands.
There is also a history mechanism that supports recall of previous commands
and easy error correction within them.

A good interactive  \emphasize{programming} language must
be reasonably efficient, be able to evaluate complicated expressions,
to compile and run general procedures, and to offer the user an interpreted
environment for investigating his data and exploring the applicable
range of analysis techniques.  This version of the CL (Version 2.3) includes
all of the command language features of the earlier versions and makes
major strides in the direction of becoming a powerful interactive
programming language as well, although much remains to be done before the
CL provides a reasonably complete and efficient interpreted programming
environment.

This may sound complicated at this point, but examples
presented throughout the body of the text will help
clarify the use of the various features.  We suggest a first reading of
this introductory section and the next chapter, and then a session at
the terminal, trying out the examples as presented.

\subsection{Capabilities of the CL}

\ppind
Besides fulfilling the basic functions of a command language,
the CL is capable of performing as a programmable desk
calculator, evaluating expressions, executing CL script tasks
or external programs, and doing some rather sophisticated
programming functions. These features provide 
a means of connecting tasks to build new high level operators.
The user's interaction with newly created tasks appears the same as 
interactions with the standard tasks and utility packages,
as will become apparent in the discussions on usage and script tasks.

The CL has many features familiar to UNIX users in that
I/O redirection, pipes and filters are provided.
The output of any task may be routed to a file (redirection)
or to another task (pipes), and many functions are provided to
perform standard transformations on a variety of data types (filters).
Be aware, however, that there are many differences between the CL
and the UNIX command interpreters.  
The CL and the IRAF system present the user with a
complete data analysis environment which is independent of the underlying 
operating system.  Users running IRAF under UNIX, VMS, AOS, or some
other operating system have the same analysis environment available
to them and can type exactly the same commands while in the CL.

The CL supports an open environment in which packages of application
specific tasks may be created and run.  Some of these packages
have been prepared by the developers to provide a variety of utility
services, others that deal with specific instruments and analytic 
techniques are being made available, 
and still others can be created by you, to support your
own view of the data analysis process.  Beyond this, mechanisms exist
that allow compiled external programs to be inserted in the system in 
such a way that they appear (and act) as an intrinsic part of IRAF.
It is this open-ended nature that makes IRAF so powerful in its
support of a variety of analysis activities.

\newpage
\section{Getting Started}
\subsection{Setting up the IRAF environment}

\ppind
A visitor wishing to use IRAF does not need to take any special
action to do so.
Computer support personnel will provide an account on one of the analysis 
computers and configure the environment as necessary to run IRAF.  
Staff members and long term visitors will already have established 
themselves with an account and will only need to perform a few simple 
operations before the CL and IRAF can be used. \footnote{ {\bf VMS :} The
command {\eighttt IRAF} must be entered to define system symbolic names.
This command can be entered at the terminal or stored in your VMS LOGIN.COM
file; it must be present in the LOGIN.COM file for queued IRAF background
jobs to startup correctly.}
After this has been done, all of the other
commands referenced within this document will be available.

An interactive IRAF session begins with entry of the command 
\usertype{cl} to run the CL.
When the CL starts up, it looks for a file called \filename{LOGIN.CL} in the
user's current directory.  If this directory does not contain a 
\filename{LOGIN.CL} file, the CL will function for simple things
such as the evaluation of numerical expressions, but will not work 
properly for all functions.  Therefore, you should always run the CL 
from a properly configured IRAF login directory.  
This directory needs to be initialized for IRAF before the
CL is invoked; you can use the \usertype{mkiraf} command to setup the
IRAF environment.  The login directory, once set up, can be used for any number
of sessions, and if you wish, you can set up several independent login
directories and data directories for working with different types of data.

\noindent
Summarizing the steps required to set up the IRAF environment:

\begin{enumerate}
\item Decide on a login directory.
\item Go there.
\item Type \usertype{mkiraf}.
\end{enumerate}

\noindent
That is all that is required.  The \usertype{mkiraf} command performs
several actions, the most important of which are making a
\filename{LOGIN.CL} file which you may wish to edit to change defaults,
and the creation of a \filename{UPARM} subdirectory, which is used
by IRAF to store your customized parameter sets.
The default login file consists mostly of environment declarations
(\usertype{set} statements) that define directories, devices, and so on.
The function of the environment and the significance of the 
standard \irafname{environment variables} are discussed in \S 4.2.

The \usertype{mkiraf} command can be entered at any time to reinitialize
the environment, i.e., create a new \filename{LOGIN.CL} from the system
default and clear the \filename{UPARM} directory.  This is recommended
periodically to pick up any recent changes in the system, and may be
required when a major new release of the system is installed.

\subsection{Starting the CL}

\ppind
After configuring your IRAF directory, type the command \usertype{cl}
to start the command language.  After a bit the welcome message
will appear on your terminal, and the first or root ``menu'' of IRAF will 
be displayed. This menu gives the names of the packages available through
the CL. The \comptype{cl>} prompt will be issued indicating that the
CL is ready to accept commands.

\begin{quotation}
\begin{center}
\comptype{Welcome to the IRAF.}\\
\smallskip
\end{center}
\begin{verbatim}
    dataio    images    lists     noao      sdas      system
    dbms      language  local     plot      softools  utilities
\end{verbatim}
\comptype{cl>}
\end{quotation}

Everything shown in the root menu of IRAF is a \irafname{package} name.
A package is a set of \irafname{tasks} that are logically connected.
For example, the \taskname{plot} package contains an assortment of
general plotting tasks.  You must \emphasize{load} a package before any of the
tasks therein can be run; you can load any package by simply typing its name.

\begin{quotation}\noindent
\comptype{cl>} \usertype{plot}
\end{quotation}

\noindent
would load the plot package and make the tasks in the package known to the CL.
To unload the current package type \taskname{bye}; this frees any system
resources used by the loaded package and restores the CL to state it was in
before the package was loaded.
Note that the system comes up with the \taskname{clpackage, system, language}
and the default \taskname{user} packages already loaded (the \taskname{user}
package allows the user to personalize the system, and is discussed in \S 5.6).

A comment should be made at this point about case sensitivity in IRAF.  
The CL accepts input in both upper 
and lower case, and distinguishes between them, i.e. a \usertype{'Y'} is 
different from a \usertype{'y'}.  All command names are purposely
specified in lower case, which is the default, and all user responses
are expected to be in lower case as well.  Upper case or mixed case
names and commands are possible, but should be used with care.

Once the \comptype{cl>} prompt appears, many tasks will be available and
ready for execution. A list of all loaded packages and the tasks in each
package may be obtained by typing two question marks (\usertype{??}).
This will list the tasks organized by package, starting with the current
package. The packages are listed in the
order in which they are searched when you type a command. Type one question
mark (\usertype{?}) to list only the task names in the current package,
or \usertype{?{\it packagename}} to list the tasks in 
package ``packagename''.

\subsection{Executing commands from the CL}

\ppind
At this point you may want to try executing a few simple commands.
First try the \usertype{help} command.  This will give additional 
information about the tasks in the current package.

\begin{quotation}\noindent
\comptype{cl>} \usertype{help} 
\end{quotation}

For detailed information about a particular package or task, type
\usertype{help} followed by the name of the package or task for which help
documentation is desired.  For example,

\begin{quotation}\noindent
\comptype{cl>} \usertype{help system}
\end{quotation}

\noindent
will print detailed information about the \taskname{system} package, and

\begin{quotation}\noindent
\comptype{cl>} \usertype{help page}
\end{quotation}

\noindent
will print detailed information about the \taskname{page} task which is
in the \taskname{system} package (after each page of text, the \taskname{help}
program will prompt with a list of keystrokes and pause until you type one
of them).

Now let's try running some tasks from the \taskname{system} package, which
is already loaded.  To display the file \filename{LOGIN.CL} on the terminal,
enter the following command:

\begin{quotation}\noindent
\comptype{cl>} \usertype{page login.cl}
\end{quotation}

The \taskname{page} routine, like \taskname{help}, will pause at the end of
each page of text, waiting for you to type a command keystroke, e.g.,
to display the next page of text, quit, return to the start of the file,
go on to the next file if paging a set of files, and so on (typing \key{?}
in response to the \taskname{page} prompt will cause a summary of the
acceptable keystrokes to be printed).  To get a directory listing of the
files in the current directory, type:

\begin{quotation}\noindent
\comptype{cl>} \usertype{dir}
\end{quotation}

\noindent
Observe that all package, task, and parameter names may be abbreviated
while working interactively.  Any abbreviation may be given which contains
sufficient characters to identify the name unambiguously; if the 
abbreviation is not unique, an error message is displayed.  In general
the first two or three characters are enough to identify most commands,
but changes to the operating environment, i.e. loading additional packages,
may require entering more characters or specifying the 
\emphasize{packagename}
as a prefix to unambiguously identify the required command.

To list all your files with the \filename{.CL} extension, you can type:

\begin{quotation}\noindent
\comptype{cl>} \usertype{dir $*$.cl}
\end{quotation}

As you gain familiarity with the CL you may find that you
cannot remember the IRAF command to do something, but do know the
correct command to use in the native operating system.  There is an
\emphasize{escape} mechanism built into IRAF, in that any operating system
specific command may be used by prefixing it with a~\usertype{`!'}.
There are some cautions to be observed that are described in detail
(\S 4.1), but this knowledge may remove one possible source of frustration.
Of course, the CL commands \usertype{`?'} or \usertype{`??'} may also be used
to produce a display of the available package names and functions.

Packages are loaded the same way tasks are run, viz. merely by typing the name
of the package as a command (a package is in fact a special kind of task).
If the desired package is a subpackage of a package, the main package must
be loaded first.  For example, suppose we want to run the \taskname{precess}
task.  To find out what package \taskname{precess} is in we run \taskname{help}
on the task \taskname{precess} and observe that the package path (printed at
the top of the help screen) is "noao.astutil".  This means that the
\taskname{precess} task is in the \taskname{astutil} package which is in the
\taskname{noao} package, which we recognize as a root level package.

We load first the \taskname{noao} package and then the \taskname{astutil}
package by typing:

\begin{quotation}\noindent
\comptype{cl>} \usertype{noao} \\
\comptype{no>} \usertype{astutil} \\
\comptype{as>}
\end{quotation}

\noindent
The set of new tasknames now available to you will be displayed automatically.
Note that the prompt will change from \comptype{cl>} to \comptype{no>}
to \comptype{as>} to let you know you have entered another package.

One of the astronomical utility programs available is the \taskname{precess}
program, which is used to precess lists of astronomical coordinates.
The simplest way to run \taskname{precess} is to type only its name:

\begin{quotation}\noindent
\comptype{as>} \usertype{precess}
\end{quotation}

\noindent
The CL will then prompt you for the parameters it requires to run the program;
in this case, the CL needs the name of an input file containing a list
of coordinates to be precessed and the years over which the
precession is to be computed.  If you do not have the coordinates in a
file, give the filename as \filename{STDIN} (it must be upper case), and 
you can then enter the coordinates interactively from the terminal.
Any number of coordinates (input lines from the special file \filename{STDIN})
may be entered; signal the ``end of file'' for \filename{STDIN} by typing
the EOF key, e.g., \key{CTRL/Z}.
\footnote {\key{CTRL/Z} is the standard EOF (end of file)
sequence on VMS and most UNIX systems.  Similarly, \key{CTRL/C} is the
standard interrupt key on these systems.  For simplicity we use the explicit
control codes to refer to these functions in most of the IRAF documentation,
but the reader should be aware that different control sequences may be used
on the local system and be prepared to make the translations.  For example,
the key \key{CTRL/D} is often used to signal EOF instead of \key{CTRL/Z}.}
Coordinates are entered in pairs (RA and DEC, delimited by spaces) in either
decimal or sexagesimal notation (e.g., 12.5 or 12:30:04.2).  If you have any
problems type \usertype{help precess} for additional information, including
examples.

If you have a long list of coordinates to precess, try entering
them into a file.  The command:

\begin{quotation}\noindent
\comptype{as>} \usertype{edit coord1950.txt}
\end{quotation}

\noindent
will call up the default editor (Vi on UNIX systems; EDT or EMACS on VMS
systems) to edit the file \filename{COORD1950.TXT}.
After creating your coordinate file and exiting the editor in the usual
fashion, you will be back in the CL.  Now try executing the \taskname{precess}
program, using the file \filename{COORD1950.TXT} as input:

\begin{quotation}\noindent
\comptype{as>} \usertype{precess coord1950.txt}
\end{quotation}

\noindent
Of course, the output will still appear on the terminal, and
you may wish to \irafname{redirect} the output into a file as well:

\begin{quotation}\noindent
\comptype{as>} \usertype{precess coord1950.txt $>$ coord1984.txt}
\end{quotation}

If the coordinate list is \emphasize{very} long, you may wish to process
the list as a background job.  To avoid interruptions from parameter 
prompts by the background task (it will inquire at the terminal), be sure to
enter all the necessary parameters on the command line. 
To execute the task \taskname{precess} in the background, type:

\begin{quotation}\noindent
\comptype{as>} \usertype{precess coord1950.txt 1950 1984 $>$ coord1984.txt \& }
\end{quotation}

\noindent
The final `\usertype{\&}' tells the CL to run the task in the background.
The two parameters 1950 and 1984 will be passed to the task; you will
not be prompted for them.
Once the background task is started, the CL will be available for 
further interactive use and you will be
informed when the background job is complete.  The use of background
tasks for batch processing is treated in more detail in \S 5.4.

\subsection{A Comment on Input and Output}

\ppind
The notion of output \irafname{redirection} has already been introduced, and the
topics of input redirection (accepting input from a file rather than
the terminal) and \irafname{pipes} (connecting the output from one task to the 
input of the next) will be dealt with in \S 3.3. The point to be
made at this time is that \emphasize{all} tasks can be thought of as having
three main I/O paths associated with them:

\begin{quotation}\noindent
\begin{tabular}{l l}
\filename{STDIN} & the input path \\
\filename{STDOUT} & the output path \\
\filename{STDERR} & where error messages appear
\end{tabular}
\end{quotation}

%\begin{quotation}\noindent
%\begin{description}
%\item[\filename{STDIN}] the input path
%\item[\filename{STDOUT}] the output path
%\item[\filename{STDERR}] where error messages appear
%\end{description}
%\end{quotation}

\noindent
By default, all of these I/O paths are connected to your terminal 
(referred to as \filename{TTY}) and you may redirect any one or all 
of them using simple command line requests.  The output 
\emphasize{redirection} introduced in the previous example of 
\taskname{precess} is an example of just such an action.  Other 
examples in \S 3.3 will cover this topic in more detail.  

There are other standard output streams as well that depend on the
specifics of the task.  Not surprisingly,  graphics tasks
want to talk to a graphics terminal or other suitable device
(\filename{STDGRAPH}) and image tasks need access to an image display
(\filename{STDIMAGE}). There is a stream for the graphics plotter device as well
(\filename{STDPLOT}). Each of these \emphasize{logical} devices is assigned
to a physical device, either by commands in your \filename{LOGIN.CL} file
or by explicit parameters in the function calls.

\subsection{The Graceful Exit}

\ppind
Now that you are a couple of layers deep into the CL, you may wonder 
how to get back out again. If you type \usertype{bye}, you will exit the current
package and return one level of loaded packages.  You cannot, however, type
\usertype{bye} at the root CL level (\comptype{cl>} prompt).
The command:

\begin{quotation}\noindent
\comptype{cl>} \usertype{logout}
\end{quotation}

\noindent
may be used to exit directly from the CL at any level.  
The \usertype{bye} command or the \key{CTRL/Z} sequence that signals
EOF will exit from any task except the CL itself.  This is to
prevent an unintended \emphasize{logout} from occuring if a series
of EOF's are entered from the terminal.

For a less gentle departure from function execution, the interrupt
sequence \key{CTRL/C} may be used at any level.  
This will usually terminate any task that appears to
be hung or is operating in error, but will normally put you
back in the CL in interactive mode.

\newpage
\section{Basic Usage}

\ppind
The CL can be used as both a command language and a programming language,
but most first-time users (and many experienced ones) will mostly
use the command features of the language.  Commands to the CL may be
entered at the terminal, one at a time, or they may be read in from
a script file; in either case the syntax is the same and abbreviation
of command names and variable names is supported. When the CL is
being used for programming the rules are more restrictive, and
full name specification is required, as is a more formal specification
of task parameters.  During the early sections of this document
only the command forms will be used for simplicity.
Parameters to a task may be specified on the command line for brevity,
and prompting is automatically enabled for any required parameters that
are not specified or that are given values that are out of range.  

\subsection{Command Syntax}

\ppind
The form of a command that calls an IRAF task is the 
\emphasize{task name}, optionally followed by an
\emphasize{argument list}. The argument
list consists of a list of \emphasize{expressions} delimited by spaces. 
Simple filenames or string arguments that appear in the unparenthesized 
argument list need not be quoted, but any string that contains an 
embedded blank or other special characters should be quoted.
\emphasize{Positional} arguments (typically the first few
arguments \emphasize{required} for a function must be given first and 
in order.
All of these may be followed by \emphasize{param = value} keyword assignments, 
\emphasize{param$\pm$} switches, and \emphasize{file} I/O redirection
assignments. These last three types of arguments may appear in any order.
In general, the form is as follows :

\begin{quotation}\noindent
\begin{tabular}{lll}
\comptype{cl>} {\it taskname} [{\it expression} $\ldots$ ] & 
	  [{\it param=value}]	& [$<${\it filename}] \\
	& [{\it param}$\pm$]	& [$>${\it filename}] \\
	&			& [$>>${\it filename}] \\
	&			& [$>\&${\it filename}] 
\end{tabular}
\end{quotation}

\noindent
Any or all of these types of parameters may be present 
and defaults are provided for most parameters.  
In particular, the only parameters that 
\emphasize{must} be set are the \irafname{required parameters}
and if these are not specified on the command line, the CL will prompt
for them.  Other parameters and switch values are defaulted, but may be
overridden if desired. 
The I/O streams typically default to the login terminal, but the
redirection operators may be used to request: input from a file
(\usertype{$<$}); output to a file(\usertype{$>$}); appending to
a file (\usertype{$>>$}); or redirecting the standard output and the 
standard error stream to a file (\usertype{$>$\&}). 

The form of a command line need not be limited to a solitary call to a task.
Several tasks may be called in sequence on a single command 
line, using the semicolon character `;' to delimit each call:

\begin{quotation}\noindent
\comptype{cl>} \usertype{clear; dir}
\end{quotation}

\newpage
\noindent
If the command sequence is too long to fit on a single line, it can be
enclosed in braces:

\begin{quotation}\noindent
\comptype{cl>} \usertype{\{ } \\
\comptype{>>>} \usertype{clear} \\
\comptype{>>>} \usertype{directory} \\
\comptype{>>>} \usertype{beep} \\
\comptype{>>>} \usertype{\} }
\end{quotation}

\noindent
Note that the prompt changes to \comptype{>>>} after the first
line to signal that the CL requires more input before it will execute the
task. (In this particular example, the CL is waiting for a `\}'.)

Such a construct is called a \irafname{compound statement} and may be
used to aggregate several simple commands into a single new command.
Compound statements may be used directly from the terminal (or within
scripts as we shall see later) and will be treated as a single 
entity by the display and editing commands.
An arbitrary number of commands may be entered in a compound statement
and then executed as a single unit.  

Commands may be strung together in another way too, by use of the
pipe notation, which requests that the output of one command
be used as the input to the next.  Creation of the temporary files that
support this, and connection of the task logical I/O paths to these
files is handled automatically by IRAF.

\begin{quotation}\noindent
\comptype{cl>} \usertype{type coord1950.txt \pipe precess 1950 1984}
\end{quotation}

\noindent
The pipe symbol `{\tt |}' directs the CL to feed the output of
one task (\usertype{type}) to the input of the next (\usertype{precess}).

\noindent
If an argument list is too long to fit on one line,
continuation is understood if the last item on a line is a backslash
`$\backslash$', the pipe symbol, or an operator (e.g., `$+$' or `{\tt //}').

\begin{quotation}\noindent
\comptype{pl>} \usertype{graph "pix[*,5],pix[*,10],pix[*,15]" po$+$ 
	marker=circle \bsl } \\
\comptype{>>>} \usertype{xlabel=column ylabel=intensity \bsl  } \\
\comptype{>>>} \usertype{title = "lines 5, 10, and 15"}
\end{quotation}

Quotes \emphasize{may} be used around
any string of characters, but are generally not required on commands
entered at the terminal.  In the previous example quotes are used
around the string value of the \usertype{title} parameter because the
string contains embedded spaces.

To make precise the rules for quoted strings:
a string need not be
quoted provided [1] it appears as an identifier (a name) in an argument
list \emphasize{not} enclosed in parentheses, AND [2] the string does not
contain any blanks or other characters which are special to the CL,
e.g., the i/o redirection symbols, the pipe symbol, semicolon, the begin
comment character (\usertype{\#}) or curly braces.
If the string contains any special characters it must be quoted.

Comments may be freely embedded in a command sequence.
Everything following the comment character on a line is ignored by the parser,
so entire comment lines may be entered by starting the line with a comment:

\begin{quotation}\noindent
\comptype{cl>} \usertype{\# This is a full line comment} \\
\comptype{cl>} \usertype{type login.cl \hfill  \#~Display~the~login~file }
\end{quotation}

\noindent
or by appending a comment to the end of a line as in the last example.

\subsection{Task Parameters}

\ppind
Nearly all tasks have a formally defined set of parameters associated
with them.  The parameters for a task may be listed with the command
\usertype{lparam }{\it taskname}.  For example, to list the parameters for
the task \taskname{delete}, type:

\begin{quotation}\noindent
\comptype{cl>} \usertype{lparam delete}
\end{quotation}

\noindent
The \usertype{lparam} command produces a display of the parameters of the
named task in the order in
which they must be given on the command line; it shows the current values
of the parameters and the prompt strings as well.

After one types \usertype{lparam delete}, the following list will appear,
giving the parameter name, its
current value, and the prompt string associated with it:

\begin{verbatim}
                files =        list of files to be deleted
             go_ahead = yes    delete or not ?
              (verify = no)    verify operation before deleting each file ?
      (default_action = yes)   default delete action for verify query
         (allversions = yes)   delete all versions of a file ?
            (subfiles = yes)   delete any subfiles of a file ?
                (mode = ql)
\end{verbatim}

Notice that there are two types of parameters, those with 
parentheses around the \emphasize{param = value} fields and those without.
The parameters not enclosed in parentheses are called 
\irafname{positional parameters}; they are required parameters
and will be queried for if not given on the command line. Positional
\emphasize{arguments} are the first arguments on the command line (following
the command itself), and they are associated with parameters by their position
on the command line. The first positional parameter will be set by the first
positional argument on the command line, the second positional parameter by
the second positional argument, and so on. 

The parameters enclosed in
parentheses are called \irafname{hidden parameters}, and are the topic of
the next section.  Either type of parameter may be referred to by a
\usertype{param = value} clause, although these parameter references
must \emphasize{follow} the positional arguments.  Such name references
\emphasize{must} be used for the hidden parameters, but may be used for all.

Some of the parameter handling actions in the CL are rather elaborate
and require discussion.  As was just noted, the CL will automatically
prompt for any required parameters that have not been provided in some
way by the user.  Beyond this, the normal action of the CL is to
remember the parameters that you last used, and when that parameter
name is next encountered, to offer the last value used as the new
default value.  This \irafname{learning} of parameters is intended
to reduce user effort and is a means of customizing use of the system.
The learned parameters are saved for you in the \filename{UPARM}
subdirectory, and will be preserved across uses of the system.

\subsubsection{Hidden Parameters}

\ppind
The parameters of the \usertype{delete} task that appeared in 
parentheses are \taskname{hidden parameters} for the task.
The CL does not query for hidden parameters, but automatically
uses the default values.  However, a query will be generated for 
even a hidden parameter if there is no
default value or if the default value is illegal for some reason.
Hidden parameters may be set on the command line, but unlike positional
parameters, the value from the command line will not be learned, i.e., it will
not become the new default value.  The default value of a hidden parameter may
be changed only by an explicit assignment, or by use of the \taskname{eparam}
task (\S 3.2.3), and you should exercise caution in doing this,
because it is easy to forget that hidden parameters have been changed.

Hidden parameters are often used to change the behavior of a task,
achieving considerable flexibility without requiring many arguments on the
command line, and without annoying queries for parameters.  Hidden parameters
make it possible to support functions like \taskname{graph} that
support different display options,  since users can modify
the default behavior of the task to make it behave in the manner they want.
Hidden parameters can also be dangerous if they are used improperly
(e.g., for data dependent parameters in scientific programs).

The \taskname{delete} task is a good example of a task that is useful to
personalize.  The default behavior of \taskname{delete} is simply to delete
the named file or files (provided they are not protected in some way).
File deletion can be hazardous, of course, particularly since a pattern
matching template may be used to delete many files. As many of us are unhappily
aware, inadvertently typing

\begin{quotation}\noindent
\comptype{cl>} \usertype{delete $*$}
\end{quotation}

\noindent
will bring about the swift deletion of \emphasize{all} of the (unprotected)
files in the current default directory.
As IRAF recognizes a number of special pattern matching metacharacters in
addition to `$*$', one could easily free up a lot of disk space if one were
not familiar with the use of pattern matching templates.

To reduce the possibility of such devastating side-effects, you might wish to
change the default behavior of \taskname{delete} to verify each file deletion.
This is done by changing the value of the hidden parameter \taskname{verify},
which defaults to \emphasize{no}.  Hidden parameters that are boolean flags 
(yes/no) may be overridden temporarily on the command line as follows:

\begin{quotation}\noindent
\comptype{cl>} \usertype{delete $*$.dat verify=yes}
\end{quotation}

\noindent
or, equivalently,

\begin{quotation}\noindent
\comptype{cl>} \usertype{delete $*$.dat verify$+$}
\end{quotation}

\noindent
Either of these commands would cause a prompt to be issued naming
each file matching the template and asking if you want to delete
it (this would happen even if the task were running in batch mode).

If you set a hidden parameter on the command line, you override the value
of that parameter only for that command; the default value is not changed.
As indicated before, to change the default value of a hidden parameter,
an explicit assignment is required:

\begin{quotation}\noindent
\comptype{cl>} \usertype{delete.verify = yes}
\end{quotation}

\noindent
which will cause all subsequent file deletions to be verified, unless the
\usertype{delete} command is issued with the argument \usertype{verify=no}
or \usertype{verify$-$} on the command line.  The change may be undone by
another assignment, or by \emphasize{unlearning} the task parameters.  

\subsubsection{Learning and Unlearning parameters}

\ppind
The CL facility called \irafname{learn mode} is designed
to simplify the use of the system.
By default, the CL automatically ``learns'' the value of all task
\irafname{parameters} that are prompted for or explicitly set.  In practice,
this means that once a required parameter (such as the precession epoch in
the \taskname{precess} example)
has been set, it need not be respecified.  The CL will still prompt for
required parameters, but the default value displayed will be the
last value you entered.  Simply hitting \key{RETURN} will cause the CL
to reuse the old value; but a new value may be entered and it will
be preserved as the new default. If the required parameters are
specified on the command line, you will not be prompted for them, and the
value you specify will still be learned.

The parameter-learning mechanism has other ramifications as well.
The most recently used parameter values are automatically preserved
by the CL in \filename{.PAR} files stored in your \filename{UPARM} directory.  
These saved parameter
sets are reloaded when you next start the CL, thus providing a
\emphasize{memory} of the options that you used in a previous session.  
Any command line arguments
that you specify will override these \emphasize{learned} defaults, but they
will be available if you wish to use them.

An explicit command may be used to
\emphasize{reset} the values of parameters,
i.e., to restore the defaults. The \usertype{unlearn} command restores the
system default values of all of the parameters for a single task or for an
entire package.

\begin{quotation}\noindent
\comptype{cl>} \usertype{unlearn delete}
\end{quotation}

\noindent
will restore the parameters of the task \taskname{delete} to their default
values, and

\begin{quotation}\noindent
\comptype{cl>} \usertype{unlearn system}
\end{quotation}

\noindent
will restore the defaults for \emphasize{all} of the tasks in the system
package. If you want to restore the defaults for all the parameters in your
IRAF environment, delete the \filename{.PAR} files from the logical directory
\filename{UPARM} :

\begin{quotation}\noindent
\comptype{cl>} \usertype{delete uparm\$$*$.par}
\end{quotation}

\subsubsection{Specifying Parameters to a Task}

\ppind
The simplest and fastest way to invoke a task is to simply type in the name
of the task followed by the necessary arguments on the command line, as we
have been doing in most of the examples thus far.
In many cases, the arguments for a task will be obvious, either from the context
and the prompts issued by the task, or from the \usertype{lparam} display.
If you are unsure about how to proceed,
you can simply type the task name, and answer the questions.
Each prompt may include minimum and maximum acceptable values,
if such apply, and the current value of the parameter if such exists. 
For parameters that have only a fixed set of allowable values the list of
valid options will be enumerated.

Alternatively, the \usertype{eparam} command may be used to invoke the
parameter \emphasize{editor}.  The \taskname{eparam} task presents the
parameters of a task in a tabular display on the screen and supports the
use of the cursor keys to navigate the options.  It also has commands for
changing entries, or for recalling previous entries for further editing.
The command:

\begin{quotation}\noindent
\comptype{cl>} \usertype{eparam precess}
\end{quotation}

\noindent
will display the parameters for \taskname{precess} (the \taskname{noao} and
\taskname{astutil} packages must first be loaded).  The \key{RETURN}
key will move you down the list or the cursor keys
may be used to move among the parameters, and any entries that you
type will replace the displayed values.  You may exit from
\taskname{eparam} at any time with a \key{CTRL/Z} and the parameters 
for the task will be updated with your newly edited values.
If you wish to exit the editor \emphasize{without} updating the
parameters, use the interrupt request \key{CTRL/C} instead.
Specifying parameters via \usertype{eparam} has the same effect as
does entering them on the command line, they will be remembered by IRAF
and not prompted for when the function is next invoked.  

\usertype{Eparam} and the history editor \usertype{ehistory} both
use the same simple set of editor commands, and they can mimic several 
editors that are common on the currently supported systems.  For any
of these editors the default style supports use of the cursor (arrow keys)
on the terminal and the use of the \key{DELETE} key.  The sections on
editors (\S 5.2-3) describe this in more detail.

If you find that you must invariably run \taskname{eparam} before running
a particular task, e.g., because the task has too many parameters to be
specified on the command line, it is possible to get the CL to run
\taskname{eparam} for you automatically whenever the task is run interactively.
This is called \usertype{menu mode}.  To set menu mode for a task we
set the string value of the \taskname{mode} parameter of the task; all
tasks have such a parameter.  For example,

\begin{quotation}\noindent
\comptype{cl>} \usertype{precess.mode = ``ml''}
\end{quotation}

\noindent
will set both menu and learn mode for the task \taskname{precess}.
The default mode for most tasks is \usertype{ql}, i.e., query (the task
will query for all parameters not set on the command line) plus learn
(old parameter values are learned).

Once you are familiar with the operation of a task, you can
enter the parameter values on the command line in the
order in which they appear in the \usertype{lparam} listing.
Parameters may also be set using the \usertype{param = value} clause on the
command line, but remember that any positional arguments must be given first.
Note that a command line argument may be any general expression, much like
the arguments to a Fortran subroutine.

\begin{quotation} \noindent
\comptype{cl>} \usertype{precess stdepoch= (1984$+$i$*$4)}
\end{quotation}

\noindent
Here an expression is used to compute the value of the
hidden parameter \taskname{stdepoch}. Note that the expression must
be enclosed in parentheses in order to cause it to evaluated, since it
will otherwise be treated like a string and just passed into the task
for it to handle.  The variable \usertype{i} must previously have 
been set to some legal value; otherwise the CL will prompt for it.

\subsection{Pipes and I/O Redirection}

\ppind
We have already seen how tasks can take their input from either the
terminal or from a file, and send the output to either the terminal
or a file.  By default, both the standard input and standard output for a
task are written to the user terminal; the capability to change them
on the command line is called \emphasize{I/O redirection}.  The Appendix of
IRAF commands at the end of this document was created with the 
following simple command:

\begin{quotation}\noindent
\comptype{cl>} \usertype{help {\it pkg} $>$ {\it pkg.txt} }
\end{quotation}

\noindent
where the name of each package was substituted for {\it pkg}.

The pipe syntax is a powerful kind of I/O redirection. A pipe is formed by
connecting the output of one task to the input of another task; an arbitrary
number of tasks may be connected together in this way to form a single command.
UNIX users will already be familiar with the concept and uses of pipes,
but be aware that CL pipes differ from UNIX pipes in that the CL tasks
execute \emphasize{serially} rather than concurrently (i.e., nothing comes out
of the end of the pipe until \emphasize{all} the input has been processed).
Another difference between IRAF and the usual UNIX implementation
is that IRAF pipes are implemented with temporary files which are
managed by the system.
Note also that queries for parameters are not affected by the use of 
I/O redirection or pipes, i.e., required parameters will still be 
prompted for when requested by a task.

A simple example of the use of a pipe is redirecting the output of a command
to the line printer.  This can be done with I/O redirection as follows:

\begin{quotation}\noindent
\comptype{cl>} \usertype{help plot $>$ temp} \\
\comptype{cl>} \usertype{lprint temp} \\
\comptype{cl>} \usertype{delete temp}
\end{quotation}

\noindent
The pipe notation accomplishes the same thing and is more concise:

\begin{quotation}\noindent
\comptype{cl>} \usertype{help plot \pipe lprint}
\end{quotation}

\noindent
For a more sophisticated example of the use of pipes, load the
\usertype{lists} package and try out the following command:

\begin{quotation}\noindent
\comptype{cl>} \usertype{?? \pipe words \pipe match : stop$+$ \pipe
	sort \pipe table}
\end{quotation}

\noindent
This sequence of commands takes the list of menus produced by \usertype{??},
breaks it into a list of words, filters out the lines that contain the colon
character (the package names), sorts the list, and prints a menu listing the
tasks in all loaded packages.

The following example shows the use of a pipe-filter to sort the output
of a long form directory listing of the system library directory \filename{LIB},
sorting the list in reverse numeric order by the size of the file, so that
the largest files come out at the top of the list:

\begin{quotation}\noindent
\comptype{cl>} \usertype{dir lib l$+$ \pipe sort num$+$ rev$+$ col$=$3}
\end{quotation}

\noindent
We can go a bit further and extend the pipe to print only the ten largest
files and page the output:

\begin{quotation}\noindent
\comptype{cl>} \usertype{dir lib l$+$ \pipe sort num$+$ rev$+$ col$=$3 \pipe
	head nlines$=$10 \pipe page}
\end{quotation}

Any or all of the input, output or error logical I/O streams may be
redirected with simple command line requests.  The next example shows
the use of redirected input and output streams:

\begin{quotation}\noindent
\comptype{cl>} \usertype {
	match \upa\usertype{set} $<$ home\$login.cl $>$ names.env }
\end{quotation}

\noindent
This command reads from your \filename{LOGIN.CL} file, created by the
initial \usertype{mkiraf} command, matches all the lines that contain
\usertype{set} environment statements (the metacharacter \upa (up-arrow)
causes \usertype{set} to be matched only at the beginning of a line),
and writes these out into the file \filename{NAMES.ENV}.

The \usertype{$>$} redirection operators will create a new output file.
To append to an existing file we use the \usertype{$>>$} operator instead:

\begin{quotation}\noindent
\comptype{cl>} \usertype{set \pipe match tty $>>$ names.env}
\end{quotation}

\noindent
which will scan for all the environment variables having something to do with
the terminal and append them to the file \filename{NAMES.ENV}.

The operators \usertype{$>$} and \usertype{$>>$} will redirect only the
standard output stream \filename{STDOUT}; error messages will still come
out on the terminal.  To redirect both \filename{STDOUT} and \filename{STDERR}
the operators \usertype{$>$\&} and \usertype{$>>$\&} should be used instead.

The graphics output streams may be redirected (but not piped) much as is
done for the ordinary textual output streams.\footnote{This holds only for
standard IRAF tasks, i.e., tasks which use the IRAF graphics subsystem.
This feature is not currently available for the STScI SDAS tasks since they
do not use the IRAF graphics facilities.}  For example, to redirect the
standard graphics output of the \taskname{surface} task (in the \taskname{plot}
package) to produce a graphics metacode file \filename{SURF.MC}:

\begin{quotation}\noindent
\comptype{cl>} \usertype{ surface dev\$pix $>$G surf.mc}
\end{quotation}

To redirect the \filename{STDIMAGE} stream, substitute the operator
\usertype{$>$I}, and to redirect the \filename{STDPLOT} stream, use the
operator \usertype{$>$P}.  The characters \usertype{GIP} must be uppercase.
The \usertype{$>$} may be doubled to append to an existing file, as for
the standard text streams.  As a special case, a graphics stream (or indeed
any stream) may be redirected to the so-called \emphasize{null} file
\filename{DEV\$NULL} to discard the output.  For example,

\begin{quotation}\noindent
\comptype{cl>} \usertype {prow dev\$pix 100 $>$G dev\$null}
\end{quotation}

\noindent
will plot row 100 of image \filename{DEV\$PIX}, redirecting the graphics output
into the null file.  The null file can be used anywhere a normal file can be
used.

\newpage
\section{Operating System Interface}

\ppind
Although IRAF provides a quite complete environment for data analysis
activities, it must be hosted in some particular operating system whenever
it is being used.  The isolation from the peculiarities of any
specific operating system command syntax is rather complete, but there
are instances where the syntax of the underlying system must be
used (host filenames) or where the user may desire to use familiar
commands from the host system.  IRAF does allow commands to be passed
through to the host operating system, but because IRAF maintains all of
its own environment descriptors, directory structures, and task and
program information, the operating system commands should only be used
to bring information into the IRAF environment, but not to modify it.
In order to change any of the status or control information that
affect IRAF execution, the commands provided by IRAF must be used.

\subsection{Sending Commands to the Host Operating System}

\ppind
IRAF allows access to the underlying operating system, and hence to
other programs that operate within the native operating system
environment.  There are limitations on some of the system facilities that
can be used without regard to side-effects, but, in general, almost any
program can be called from within IRAF.
External programs can be accessed from within the user's environment and will 
operate with a standard interface that is compatible with the
rest of the processing functions that are available.

Any command may be sent to the host operating system by prefixing
the command with the escape character `\usertype{!}'.  The rest of the
command line will be passed on unmodified.  For example, to read your mail
on a UNIX or VMS system:

\begin{quotation}\noindent
\comptype{cl>} \usertype{!mail}
\end{quotation}

\noindent
Upon exiting the mail routine, you will be back in the CL. Almost any
task that is executable in the normal host environment can be invoked
from within IRAF by means of this escape mechanism.  The OS escape
is used to implement some of the standard IRAF commands that request
operating system information, such as \usertype{spy}.
The \usertype{edit} command also uses the escape mechanism, so that
the host supported editors can be used, rather than require that a
completely new editor be learned in order to use IRAF.

Occasional conflicts will arise if these external tasks re-assign
their terminal input and output streams or perform other unnatural acts.
If strange things happen when trying to use such tasks from within
the CL, consult your \irafname{IRAF Guru}.  The other major source of problems
with host system tasks is that they may depend upon system specific
data that have been defined for the OS but are unknown to IRAF.  This
is a particular problem under VMS, which does not pass system environment
parameters to sub-tasks, as does UNIX.  Variables that affect the 
execution of tasks within the environment are controlled by IRAF and
are passed between the executing tasks, as in described next.

\subsection{Environment Variables}

\ppind
The CL maintains a table of environment variables which 
affect the operation of \emphasize{all} IRAF programs.
The environment variables are used to define logical names for directories,
to associate logical device names with a specific physical device, 
and to provide control over the low level functioning of the 
IRAF file I/O system.
The default environment is created by IRAF at login time, i.e., when the
CL is first run.  Part of this initialization uses a standard system-wide,
site dependent file named \filename{HLIB\$ZZSETENV.DEF}.  Additional
initialization of personal environment variables, or redefinition
of standard environment variables, may be done with commands
in your \filename{LOGIN.CL} file. 

One may add new environment variables, or redefine old ones, at any time during
a session with the \usertype{set} command.  \usertype{Set} declarations made
during CL execution, however, may be lost upon exit from a package.  To secure
environment declarations for a full session, make them \emphasize{immediately}
after logging in.  To make environment declarations permanent, place the
relevant \usertype{set} commands in your \filename{LOGIN.CL} file.

The \usertype{set} command is usually used to change the \emphasize{session}
defaults for output devices and such, but all IRAF programs which write to the
line printer or to a graphics device also permit the device to be selected on
the command line.  For example,

\begin{quotation}\noindent
\comptype{cl>} \usertype{set terminal = vt100}
\end{quotation}

\noindent
informs IRAF that the user is using a VT100-type terminal for this session. 
When typed without any arguments, e.g.:

\begin{quotation}\noindent
\comptype{cl>} \usertype{set \pipe page}
\end{quotation}

\noindent
\taskname{set} displays a list of the current values of all of the environment
variables.  Note that abbreviations are \emphasize{not} supported for
environment variable names, they must be spelled out in full.
If a shorter name is used the CL will silently create a new environment
variable for you, which may not be what you desired at all. 

Identifying the kind of terminal you are using, the size of the display
window to be used, and setting other terminal options may most conveniently
be done with the \usertype{stty} command:

\begin{quotation}\noindent
\comptype{cl>} \usertype{stty tek4014 baud$=$1200}
\end{quotation}

\noindent
This command should be used early in the session (if not already present in
the \filename{LOGIN.CL} file) to identify the kind of terminal that you are
using, since the operation of the various editors and of other functions will
be affected by these values.  It is only necessary to set baud rate as in
the example if you are working remotely via modem.  As was the case with
the \usertype{set} command, typing \usertype{stty} with no arguments will
display the current terminal type and settings.

The current value of \emphasize{individual} environment variables may be
displayed with the \usertype{show} command:

\begin{quotation}\noindent
\comptype{cl>} \usertype{show printer}
\end{quotation}

\noindent
A selection of the more important environment variables is shown in the
following table.

\begin{center}
\begin{tabular}{|l|l|l|}
\hline
\multicolumn{3}{|c|}{\bf Selected Environment Variables}\\
\hline
{\it variable}&  {\it sample value}&  {\it usage}\\
\hline
terminal&       ``vt100''&      default terminal device\\
printer&        ``printronix''& default line printer device\\
stdgraph&       ``vt640''&      name of graphics terminal device\\
stdplot&        ``versatec''&  	batch plotter device\\
stdvdm& 	``uparm\$vdm''&	name of graphics metacode file\\
stdimage&       ``iism75''&	image display device\\
clobber&        no&     	clobber (overwrite) output files\\
filewait&       yes&    	wait for busy files to become available\\
\hline
\end{tabular}
\end{center}
\medskip

\noindent
Clearly, the permissible names of devices are site dependent; for a list of
the devices available at a particular site the user should consult their
\irafname{IRAF Guru} (or look in the \filename{TERMCAP} and \filename{GRAPHCAP}
files in the IRAF logical directory \filename{DEV}).

Among the set of environment variables that control the operation of
the CL is a subset of variables that define the user environment.  These
variables describe the user's home and scratch directories, terminal
type, and editor preference.  Because these values describe a user's-eye
view of IRAF, they can be thought of as \emphasize{customization} variables
and can be \usertype{set} in the \filename{LOGIN.CL} file to your 
preferred values.  

\begin{center}
\begin{tabular}{|l|l|l|}
\hline
\multicolumn{3}{|c|}{\bf User Environment Variables}\\
\hline
{\it variable}&  {\it sample value}&  {\it usage}\\
\hline
editor&		``vi'' &	default editor mode\\
home&		``/{\it user}/iraf/'' \footnotemark & user home directory\\
uparm&		``home\$uparm/''&	user scratch directory\\
imdir&  	\emphasize{system-dependent}&directory where bulk data is stored\\
imtype&  	``imh'' & default image type (header file extension)\\
userid&		{\it user}&	user identification name (for output)\\
\hline
\end{tabular}
\end{center}

\footnotetext{ {\bf VMS :} an equivalent VMS example might be 
``DISK\bsl\$1:[USER.IRAF]''.  Note that any dollar sign characters appearing
in host filenames must be escaped in IRAF since the dollar sign is a reserved
character in IRAF filenames.}

\noindent
The \filename{HOME} directory specification, and possibly an 
\filename{IMDIR} declaration should be the \emphasize{only} places in
your \filename{LOGIN.CL} file where any system specific names appear
at all.  All of the IRAF name references (except a single root reference)
are processed by the virtual name mapping algorithms. If this same
mechanism is used for all user files as well, then only IRAF
virtual filenames need to be referenced once the root directory
has been properly specified.

The default \emphasize{uparm} declaration
assumes that a \filename{UPARM}
subdirectory has been set up in your login directory; the \usertype{mkiraf}
command described earlier (\S 2.1) sets this up for you. If a \filename{UPARM}
subdirectory does \emphasize{not} exist, the CL will refuse to update
user parameters and will issue a warning message.

\subsection{File and Directory Names}

\ppind
The IRAF system employs \irafname{virtual file} names so that all file
references will look the same on any computer, and IRAF primitives convert 
virtual filenames into their host operating system equivalents.  In general,
either the IRAF virtual filename or the operating-system-dependent filename
may be used in a command entered by the user, but users should avoid
the use of OS-specific names wherever possible.  Internally IRAF itself 
uses only virtual filenames for reasons of transportability.

Note that filename mapping does not operate automatically for virtual file
names that are passed as parameters to foreign (host system) tasks, but a CL
intrinsic function \taskname{osfn} will perform the mapping if called
explicitly on the command line.  The host task must be declared as an IRAF
\taskname{foreign task} (\S 5.6) for this to work.  There is no provision
for filename mapping when the regular OS escape mechanism (\S 4.1) is used.

The environment variables described in the preceding section play a fundamental
role in the mapping of virtual filenames.  Environment variables define 
the logical directories that are used to create host operating system
specific names from logical names. An example of a virtual filename
is the default logfile, \filename{HOME\$LOGFILE.CL}. 
The \filename{HOME} field, delimited by the `\$' character, is the logical
directory; the file name within that directory is \filename{LOGFILE.CL}.
Successive translations of `\$'-delimited logical names are performed until the
operating system dependent name has been generated.  Names such as 
\filename{HOME\$UPARM/} are \emphasize{directory} references; the trailing `/'
indicates that a filename or sub-directory name may be appended to produce
a legal file or directory pathname.

\subsubsection{File Name Templates and Metacharacters}

\ppind
Although filenames cannot be abbreviated the way commands can,
pattern matching templates can be constructed that 
refer to many files.  You need only type a
short string (the pattern) that serves as a \emphasize{template}, and all
files whose names match the template are selected.  All of the IRAF
functions that process filenames (and this is most of them) use the
same function to expand filename templates into a list of files.
The pattern matching \irafname{metacharacters} are a super-set of those
used in the UNIX and VMS operating systems. To print all files having
the extension \filename{.CL}, type:

\begin{quotation}\noindent
\comptype{cl>} \usertype{lprint $*$.cl}
\end{quotation}

\noindent
To page through all files in the logical directory \filename{FIO} 
with the \filename{.X} extension, type:

\begin{quotation}\noindent
\comptype{cl>} \usertype{page fio\$$*$.x}
\end{quotation}

\noindent
The filenames matched by the file template are passed to the \usertype{page}
task which pages through the set of files.  As each file is accessed, the VOS
filename translation facilities are used internally to generate the host
system filename, which is passed to the kernel to physically open the file.

\begin{center}
\begin{tabular}{|l|l|l|}
\hline
\multicolumn{3}{|c|}{\bf Pattern Matching Metacharacters} \\
\hline
{\it Meta-char}&  {\it Meaning}&  {\it Example}\\
\hline
$*$ &		Match zero or more characters &	$*$.cl \\
\lbox...\rbox &	Any character in class & 	\lbox a-z\rbox \\
\lbox \upa...\rbox &	Any character not in class & 	\lbox \upa A-Z\rbox \\
? &		Match any single character & 	a?c \\
\{...\} &	Ignore case for the enclosed string &	\{Lroff\} \\
@{\it file} &	Read filenames from a list file&	@listfile \\
\hline
\end{tabular}
\end{center}

\noindent
To delete a named list of files, type:

\begin{quotation}\noindent
\comptype{cl>} \usertype{delete file1,file2,file3}
\end{quotation}

\noindent
Note that the list of filenames is separated by commas \usertype{','}
\emphasize{with no intervening blanks}.
This causes the individual filenames to be treated as one list-form 
parameter rather than to be processed as three separate parameters.
A blank is treated as a delimiter by the parser, and thus may not appear
in a list-form parameter unless the list is enclosed in quotes.

The following is equivalent to the previous example, except that no warning
will be issued if any of the three files does not exist, since we are asking
the system to find all files that match the template, rather than naming the
files explicitly:

\begin{quotation}\noindent
\comptype{cl>} \usertype{delete file\lbox123\rbox}
\end{quotation}

\noindent
Consider the following simple command:

\begin{quotation}\noindent
\comptype{cl>} \usertype{delete filex}
\end{quotation}

\noindent
The name ``filex'' given here is actually ambiguous; it could be either the
name of a file (a string constant) or the name of a string parameter
set to the name of the file to delete.  In this simple and common case,
the CL will quietly assume that ``filex'' is the \emphasize{name} of the
file.  If the identifier \usertype{filex} is really the \emphasize{name}
of a variable, it will have to be parenthesized to force it to be evaluated.
Either of the following forms are equivalent to this command and both are
unambiguous requests to delete the file named \filename{FILEX}:

\begin{quotation}\noindent
\comptype{cl>} \usertype{delete 'filex'}\\
\medskip
\comptype{cl>} \usertype{delete ('filex')}
\end{quotation}

\noindent
Note that within parentheses the \emphasize{string} \usertype{'filex'} 
must be typed as shown, with quotes, or the CL will attempt to process
it as a variable name, causing a runtime error if there is no such variable
currently defined within the scope of the \taskname{delete} task.

The following command is also unambiguous, and it specifies that the CL
is to take the name of the file from the \emphasize{parameter} ``filename'':

\begin{quotation}\noindent
\comptype{cl>} \usertype{delete (filename)}
\end{quotation}

Note that in many of these examples, a \emphasize{single} string 
type argument, viz. the file matching template with metacharacters, 
is used to refer to a list of files.
This convention is employed by all IRAF tasks which
operate on lists of files.  Be careful not to confuse a file list template
with the argument list itself.  Thus:

\begin{quotation}\noindent
\comptype{cl>} \usertype{delete file,file2,prog.$*$}
\end{quotation}

\noindent
is perfectly acceptable, and does what the next example does:

\begin{quotation}\noindent
\comptype{cl>} \usertype{delete 'file1, file2, prog.$*$'}
\end{quotation}

\noindent
as long as there are no blanks between elements of the first name list.
If blanks were inadvertently included in the unquoted template string the
CL would interpret the template as several string arguments, probably causing
an error something like ``\comptype{too many positional arguments}''.

The list file approach is useful when it is difficult to specify a template
for the desired set of files, when the same set of files will be operated
upon several times, when a very large number of files are to be operated
upon, or when a list is already available.  The file list may be generated
by the editor, or by a task such as \taskname{files}, e.g.:

\begin{quotation}\noindent
\comptype{cl>} \usertype{files *.im,run[1-4].* $>$ listfile}
\end{quotation}

\noindent
The textfile \filename{LISTFILE} may then be referenced in a filename template
as \usertype{@listfile} to operate upon the listed files.  A variation on
the listfile approach is \usertype{@STDIN} (must be upper case), which
allows the filenames to be typed in when the task begins running.

Some tasks use the filename template mechanism to generate the names of a
\emphasize{new} set of \emphasize{output} files.  The filename template
expansion code provides two operators for generating new filenames from
old ones.  The file template \emphasize{operators}, which are used to
construct new filenames, should not be confused with the pattern matching
\emphasize{metacharacters}, which are used to match a subset of an existing
set of files.

The first and simplest operator is the string concatenation operator
\comptype{//}.  This may be used to concatenate a string suffix to the
\emphasize{root} field of a filename, to concatenate a filename to a string
prefix, to concatenate two filenames, or some combination of the above.
For example,

\begin{quotation}\noindent
\comptype{cl>} \comptype{files lib\$*.com$//$\_o}
\end{quotation}

\noindent
will produce a new list of files by appending the string \comptype{"\_o"} to
the root of each filename matched by the template at the left.

The second and last operator is the string substitution operator
\comptype{\%}.  If a sequence of the form \comptype{\%a\%b\%} is inserted
somewhere in a file template, the string \usertype{a} will participate in
the pattern matching operation, but will be replaced by \usertype{b} in the
generated filename.  Either \usertype{a} or \usertype{b} may be omitted to
insert or delete fields from a filename.  For example,

\begin{quotation}\noindent
\comptype{cl>} \comptype{files lib\$*\%\%\_o\%.com}
\end{quotation}

\noindent
is equivalent to the concatenation operation illustrated in the preceding
example.  The command

\begin{quotation}\noindent
\comptype{cl>} \comptype{files lib\$*.\%com\%dat\%}
\end{quotation}

\noindent
would find all the \filename{.COM} files in the logical directory
\filename{LIB}, generating a new list of files with the extension
\filename{.DAT} substituted for \filename{.COM}.

All IRAF tasks that use pattern matching or template expansion use the same
syntax and metacharacters as in the examples given here for filename templates.
This includes, for example, the use of templates in the \taskname{help} task
to locate manual pages, and the use of pattern matching in the \taskname{match}
task to search text files for lines that match a pattern.

\subsubsection{Directories and Path Names}

\ppind
It is often useful to employ several different directories as an aid to 
organizing your data.  For instance, you may have one directory for M87 data, 
and one for M8 data, or, as was set up for you by the \usertype{mkiraf} command,
a login directory \filename{HOME} and a scratch directory \filename{UPARM}.
New directories may be created with \usertype{mkdir}; use \usertype{chdir}
or \usertype{cd} to change the default directory, and \usertype{back} to
return to the most recent default directory.

For example, to display the pathway through the system to your current
default directory, type:

\begin{quotation}\noindent
\comptype{cl>} \usertype{path}
\end{quotation}

\noindent
To change to a new default directory, type:

\begin{quotation}\noindent
\comptype{cl>} \usertype{chdir }{\it newdir}
\end{quotation}

\noindent
where {\it newdir} may be an IRAF logical directory name defined 
with a \usertype{set} command, an IRAF pathname to the directory,
or a host system directory name (provided any dollar sign characters
therein are escaped).

The \usertype{mkdir} command can be used to create a new sub-directory
of the current directory:

\begin{quotation}\noindent
\comptype{cl>} \usertype{mkdir m87}
\end{quotation}

\noindent
To define a logical directory name (``m87'') for this subdirectory 
of your home directory, use the following set command (note the trailing '/'):

\begin{quotation}\noindent
\comptype{cl>} \usertype{set m87 = 'home\$m87/' }\footnotemark
\end{quotation}

\footnotetext{ {\bf VMS :} IRAF supports logical names for
files and directories that may contain mixed cases and special 
characters.  However, to avoid unpleasant surprises,
we recommend that for root directories you use only names valid 
for the underlying operating system.}

\noindent
Once this logical name mapping has been established, you may type either
of the following commands to change the default
directory to the ``m87'' directory (note \usertype{chdir} may be
abbreviated \usertype{cd}):

\begin{quotation}\noindent
\comptype{cl>} \usertype{chdir m87} \\
\medskip
\comptype{cl>} \usertype{cd home\$m87}\footnotemark
\end{quotation}

\footnotetext{ {\bf VMS :} The characters \comptype{\$} and \comptype{[},
commonly used in VMS device and directory names, will cause a conflict
if VMS file or device names using them are passed to IRAF tasks since these
characters have a special meaning in IRAF filenames and filename templates.
If either of these characters is used in a VMS filename passed to an IRAF
program, the character must be escaped to avoid interpretation as a VOS
metacharacter, e.g., \comptype{page usr\bsl\$0:\bsl[iraf.local]login.cl}.}

\noindent
If you type \usertype{chdir} or \usertype{cd} without any arguments, the
default directory will be set to your ``home'' directory.

Once a logical directory has been defined, the IRAF pathname notation may
be used to reference any file or directory in the vicinity of the new logical
directory.  For example, the following command would page the file CURSOR.KEY
in the subdirectory SCR of the subdirectory LIB of the IRAF root directory
IRAF, a predefined logical directory:

\begin{quotation}\noindent
\comptype{cl>} \usertype{page iraf\$lib/scr/cursor.key}
\end{quotation}

The current directory and the directory one level up from the current
directory may be referenced in pathnames via the synonyms ``\usertype{.}''
and ``\usertype{..}''.  For example, if the current default directory is PKG,
a subdirectory of LIB like SCR in the preceding example, the path to the
CURSOR.KEY file could be entered as follows:

\begin{quotation}\noindent
\comptype{cl>} \usertype{page ../scr/cursor.key}
\end{quotation}

It is not necessary to change the default directory to reference
files located in another directory. Your login directory, for example, has
the logical name \filename{HOME\$} assigned to it.  
The following command would page through the \filename{LOGIN.CL} 
file in your home directory, regardless of the current default directory:

\begin{quotation}\noindent
\comptype{cl>} \usertype{page home\$login.cl}
\end{quotation}

\noindent
The logical directory names (\filename{UPARM} and \filename{IMDIR} are examples
of directories that are normally appended to the \filename{HOME} 
directory, and you may set up other logical directories as required.
The names of all of the standard IRAF system directories are defined 
automatically when the CL starts up, and may be listed with the
\taskname{set} command.

\subsubsection{Virtual Filename Processing}

\ppind
Virtual filenames are used throughout IRAF and the CL in preference
to operating system specific names.  The obvious reason for this is
to isolate OS specific interfaces to a small set of locations, as
a way of ensuring commonality across operating systems and as an
aid to portability.  There is an obvious benefit to the user as well,
in that filename references will look the same within IRAF regardless
of the host environment.  Operating system specific names must
eventually be generated, but the details of these operations are 
best buried in dedicated interface routines.

The only place where OS specific names need appear at the user level is 
in file system directory names and in references to system physical devices.
Even here, the use of OS specific names should be isolated to only
one or two root directory names.
The other place where OS names must appear is calls to operating 
system routines or to external programs that are accessed from within 
IRAF via the OS escape mechanism (\S 4.1).  The \taskname{pathnames} task
and the \taskname{osfn} intrinsic function are used to translate IRAF virtual
filenames into host system filenames.

Either of the following commands will print the fully qualified OS name
for the file \filename{HOME\$LOGIN.CL}.

\begin{quotation}\noindent
\comptype{cl>} \usertype{path home\$login.cl}\\
\medskip
\comptype{cl>} \usertype{= osfn ('home\$login.cl')}\\
\end{quotation}

\noindent
The \taskname{pathnames} task writes the translated filename on its standard
output, while \taskname{osfn} returns the translated filename as the function
value.  The \usertype{pathnames} task will also expand filename templates,
and thus can be used to generate the OS names for a list of files:

\begin{quotation}\noindent
\comptype{cl>} \usertype{path home\$ss433.*\ $>$ ss433files.list}
\end{quotation}

\noindent
will generate a list of all of the files in directory \filename{HOME}
that match the template, and will write the fully qualified OS names
of these files into \filename{SS433FILES.LIST}.  This ASCII file can
be edited as necessary, and used as list-structured input to other
IRAF functions (\S 2.3, \S 6.9, \S 7.3).  

The most common use of the \taskname{pathnames} task is probably to print
the current default directory, which is its function when called with no
arguments on the command line.

\subsection{Image Data}

\ppind
An IRAF \emphasize{image} is an N-dimensional data array with an associated
\emphasize{image header} describing the physical and derived attributes of
the image.  The content of the header tends to be very data or application
specific.  The datatype selected to store the \emphasize{pixels} (data values)
is also application dependent, and a variety of choices are provided.
Images of up to seven dimensions are currently supported, although
in practice most images are either one or two dimensional, and most programs
are written to operate upon one or two dimensional images.  Any IRAF program
can be used to operate upon a \emphasize{section} of lesser dimension
(or extent) than the full image, using the \emphasize{image section} notation
discussed in \S 4.4.3, hence the dimensionality of the algorithm implemented
by a program need not prevent use of the program on images of higher dimension.

\subsubsection{Image Names and Storage Formats}

\ppind
The notation used to refer to images is similar to that used to refer to
files, except that images are more complex objects than files and hence a
somewhat more complex notation is required.  Most of the file, directory,
and pathname notation discussed in \S4.3 carries over to images.
Sets of images are referred to by an \emphasize{image template} notation
which is an extension of the file template notation discussed in \S4.3.1.

In most, but not all, cases, an IRAF image is stored on disk in two separate
files, one containing the image header and the other containing the pixels.
The basic image name is the filename of the header file.  The filename of an
image header file always has an extension specifying the format in which the
image is physically stored on disk. \footnote{In versions of IRAF prior to
V2.3, only one physical image storage format was supported, hence image header
files did not have extensions.}  Two storage formats are currently supported,
the old iraf format (OIF) and the SDAS group data format (STF).  The old IRAF
format images have the extension \filename{IMH}.  The STF images may have any
three character extension ending in \filename{H}, e.g., \filename{HHH}
(the extension \filename{IMH} is reserved for OIF images, of course).
Both types of images may be accessed at any time, with the extension being
used to identify the physical storage format to the IRAF software.

For example, the IRAF system is distributed with a standard OIF format test
image \filename{PIX} stored in the system directory \filename{DEV}.  The full
filename of the header file is \filename{DEV\$PIX.IMH}.  To make a copy of
this image in the current directory we could load the \taskname{images}
package and enter the following command:

\begin{quotation}\noindent
\comptype{cl>} \usertype{imcopy dev\$pix pix}
\end{quotation}

\noindent
or since we don't want to change the image name,

\begin{quotation}\noindent
\comptype{cl>} \usertype{imcopy dev\$pix .}
\end{quotation}

\noindent
Note that we did not have to specify the image type extension in the copy
operation.  The extension is optional whenever a single image is referenced;
in image templates, the template must match the full filename of each image
as it appears in a directory listing, hence the extension is required in
image templates.

Sometimes it is necessary to specify the image type extension to force an
image of a certain type to be created.  For example,

\begin{quotation}\noindent
\comptype{cl>} \usertype{imcopy dev\$pix pix.bah}
\end{quotation}

\noindent
would create an STF format copy of the standard test image in the current
directory.

When making a copy of an existing image, the new image will have the same
format as the old image unless an extension is specified in the output image
name.  When creating a new image from scratch, e.g., when reading a data
tape to disk, the default image type is determined by the value of the CL
environment variable \filename{IMTYPE}, the value of which is the three
character default image type extension.  If \filename{IMTYPE} is not defined,
the default value is \usertype{imh}, i.e., an OIF format image will be
created.  To change the default to be to create an STF format image, add
a command such as

\begin{quotation}\noindent
\comptype{cl>} \usertype{set imtype $=$ hhh}
\end{quotation}

\noindent
to your \filename{LOGIN.CL} file.

\subsubsection{Image Templates}

\ppind
Image templates are equivalent to filename templates except that the character
\comptype{`['}, a pattern matching character in filename templates, has a
different meaning in image templates, as we shall see in the next section.
\footnote {If you really want to perform file template style character class
expansion in an image template, use the operator \comptype{![} instead
of \comptype{[}.  The conventional escape mechanism, i.e., \comptype{\bsl[},
is used to include the \comptype{[} in the \emphasize{filename}, as in a
filename template.}

\noindent
For example, given a directory containing the files

\begin{verbatim}
    irs.log  irs.0030.imh  irs.0031.imh  irs.0032.imh
\end{verbatim}

\noindent
the template \usertype {irs.$*$.imh} would match the three image files,
whereas \usertype{irs.$*$} would match the \filename{LOG} file as well,
causing \taskname{imheader} to complain about an illegal format image in
its input list.

\subsubsection{Image Sections}

\ppind
All IRAF programs which operate upon images may be used to operate on
the entire image (the default) or any section of the image.
A special notation is used to specify \irafname{image sections}.  The section
notation is appended to the name of the image, much like an
array subscript is appended to an array name in a conventional programming
language. Note that array or image section \emphasize{index references} 
are integer only in pixel coordinates, but that the data may be of any valid
type.

\begin{quote}
\begin{tabular}{ll}
{\it section}&   {\it refers to}\\
\\
pix&  whole image\\
pix[]&  whole image\\
pix[i,j]&       the pixel value (scalar) at [i,j]\\
pix[$*$,$*$]&       whole image, two dimensions\\
pix[$*$,-$*$]&      flip y-axis\\
pix[$*$,$*$,b]&     band B of three dimensional image\\
pix[$*$,$*$:s]&     subsample in y by S\\
pix[$*$,l]&       line L of image\\
pix[c,$*$]&       column C of image\\
pix[i1:i2,j1:j2]&       subraster of image\\
pix[i1:i2:sx,j1:j2:sy]& subraster with subsampling
\end{tabular}
\end{quote}

\noindent
A limited set of coordinate transformations may be specified using image
sections, but please observe that transpose is \emphasize{not} one of them.
The ``match all'' (asterisk), flip, subsample, index, and range notations
shown in the table may be combined in just about any way that makes sense.
As a simple example:

\begin{quotation}\noindent
\comptype{cl>} \usertype{graph pix[$*$,10]}
\end{quotation}

\noindent
will graph line 10 of the image \filename{PIX}.
To generate a contour plot of an 800-pixel square image
subsampled by a factor of 16 in both dimensions:

\begin{quotation}\noindent
\comptype{cl>} \usertype{contour pix[$*$:16,$*$:16]}
\end{quotation}

\noindent
To display the fifth $x-z$ plane of a three dimensional image named 
\usertype{cube} on frame 1 of the image display device:

\begin{quotation}\noindent
\comptype{cl>} \usertype{display cube[$*$,5,$*$] 1}
\end{quotation}

\noindent
The image section string is part of the image name and is processed by
the IRAF system software (rather than by each applications program),
hence image sections can be used with all IRAF programs.  A section can
be used to write into a portion of an existing output image, as well as to
read from an input image.

\subsubsection{The OIF Image Format}

\ppind
The old IRAF image format (OIF) is the original IRAF image format,
unchanged since it was first used in the beginning of the project. 
It is called the ``old'' format in anticipation of its eventual replacement
by a new format to be layered upon the planned IRAF database facilities.
The OIF format is the current standard IRAF image format and is the format
used to test the IRAF image processing software at NOAO.

In the OIF format, each image is stored in a distinct pair of files, the
header file (extension \filename{IMH}) and the pixel file (same root name as
the header file, extension \filename{PIX}).  The pixel file need not reside in
the same directory as the header file; by default all pixel files are
created in a user directory on a scratch disk device to permit a different
file quota, file expiration, and backup policy to be employed than is used
for the smaller, more permanent ordinary user files.

The CL environment variable \filename{IMDIR} determines where OIF pixel files
will be created.  \filename{IMDIR} is a required parameter and is normally
defined in the user's \filename{LOGIN.CL} file.  The value of \filename{IMDIR}
is only used when the pixel file is created; if the value of \filename{IMDIR}
is later changed, new pixel files will be created in a different directory,
but the system will still be able to find the pixel files of the older images.

By default, the \taskname{mkiraf} script will create an image storage
directory for the user on a public scratch device and place the host pathname
of the new directory in the user's \filename{LOGIN.CL} file.  For example,
on a UNIX system, a typical set environment statement might be:

\begin{quotation}\noindent
\usertype{set imdir $=$ $/$tmp2$/$iraf$/$user$/$}
\end{quotation}

\noindent
which will cause the pixel files to be created in the named host directory,
regardless of the directory in which the image header file resides.
As an option, we can request that the pixel file be placed in the
\emphasize{same} directory as the header file:

\begin{quotation}\noindent
\usertype{set imdir $=$ HDR\$}
\end{quotation}

\noindent
or in a subdirectory of the header file directory, e.g., subdirectory
\filename{PIXELS}:

\begin{quotation}\noindent
\usertype{set imdir $=$ HDR\$pixels$/$}
\end{quotation}

\noindent
Note that the reserved logical directory name \filename{HDR} must be upper
case, and that a trailing slash is required if the subdirectory option is used.
The subdirectory will be created automatically by the system when the first
pixel file is created, if the directory does not already exist.
The \filename{HDR} option should \emphasize{only} be used if the header file
itself is created in a directory on a scratch device; it should always be used
if the image is created on a remote node in the local network.

\subsubsection{The STF Image Format}

\ppind
The STF image format is the format used by STScI to store Space Telescope
image data.  IRAF provides a dedicated image kernel to read and write this
format so that sites reducing binary ST data do not have to carry out expensive
format conversions to be able to access the data from within IRAF.  SDAS
users should note that the SDAS software can \emphasize{only} access STF
format images, hence the STF format must be used if you plan to make extensive
use of SDAS.  Reductions involving only IRAF programs should not use the STF
format, since the OIF format is simpler and more efficient, and is the format
used to test the IRAF software.

In the STF format, an image or a \emphasize{group} of similar images may be
stored in a pair of files, the image header file (extension \usertype{??H}),
and the associated pixel storage file (extension \usertype{??D}).  If multiple
images are stored in a group format image, all member images share the same
group header.  The group header file is a special VMS format text file which
can be examined by \taskname{page} and \taskname{type}, as well as with
\taskname{imheader}.  Each member image in a group format image also has its
own private binary format header, called the group parameter block.  The STF
image format supports only single precision real pixels, since that is what
SDAS programs require.

IRAF programs consider images to be independent entities, with any associations
between images being left up to the user.  When a member image of an STF
group format image is accessed from an IRAF program, IRAF constructs the image
header of the member image by concatenating the group header to the group
parameter block for the member image; no distinction is made between the two
classes of header parameters once the image has been opened.

To refer to a specific member image of a group format image, the group
subscript must be specified in the image name.  If there is an image section
as well, it comes after the group subscript.  For example, if \filename{WFPC}
is an STF group format image,

\begin{quotation}\noindent
\comptype{cl>} \usertype{implot wfpc[3]}
\end{quotation}

\noindent
would call up the interactive image plotting task \taskname{implot} on group
3 of the group format image.  If no subscript is specified, the default is
group 1.  To plot the same image with the lines flipped end for end, we add
an image section:

\begin{quotation}\noindent
\comptype{cl>} \usertype{implot wfpc[3][$-*,*$]}
\end{quotation}

\noindent
To create a new group format image, we must preallocate space for all the
member images, all of which must be the same dimensionality, size, and
datatype.  For example,

\begin{quotation}\noindent
\comptype{cl>} \usertype{imcopy wfpc wfpc2[1$/$10]}
\end{quotation}

\noindent
would create a new group format image \filename{WFPC2} with the same
dimensionality, size, and group parameter block as the existing STF image
\filename{WFPC}, then copy the pixels from \filename{WFPC} to
\filename{WFPC2[1]}.  The new image would inherit the header of the old
image as well.  Once a new group format image has been created, the remaining
member images may be written into by specifying the group subscript in the
output image name passed to an IRAF program.  The group count
(\usertype{$/$10}) should be omitted, else IRAF will try to create a new
group format image, rather than write into one of the member images of
an existing group.  Note that member images cannot be added or deleted
once a group format image has been created.

\newpage
\section{Advanced Topics in the CL}

\ppind
In addition to the basic facilities already described,
the CL permits user control over many aspects of the environment.
This includes direct control over the CL itself, control over user tasks
and background processes, the job logfile and the command history mechanism.
These features and others will be of use to the more advanced user
and enable user customization of interactions with the system.

\subsection{CL Control Parameters}

\ppind
The CL is itself a task which has a set of parameters that
are used to direct its execution. For example, if you wish to keep
a permanent record of all the commands you enter, the CL will do this
if you set its boolean parameter \taskname{keeplog} to yes. (Boolean
parameters can assume only the values \emphasize{yes} or \emphasize{no}.)
Simply type:

\begin{quotation}\noindent
\comptype{cl>} \usertype{keeplog = yes}
\end{quotation}

\noindent
and all subsequent commands will be written to the log file.
The name of this file is defined by the
string parameter \taskname{logfile} which defaults to the filename
\filename{HOME\$LOGFILE.CL}.  The name of the logfile may be changed
by assigning a new value to the parameter, e.g.:

\begin{quotation}\noindent
\comptype{cl>} \usertype{logfile = "commands.log"}
\end{quotation}

The important CL parameters which you may wish to alter or otherwise
access are described in the table below.

\begin{center}
\begin{tabular}{|l|l|l|}
\hline
\multicolumn{3}{|c|}{\bf CL Parameters}\\
\hline
{\it parameter} & {\it typical value} & {\it function}\\
\hline
echo	& no		& echo CL command input on stderr? \\
ehinit	& (see manpage)	& ehistory options string \\
epinit	& (see manpage)	& eparam options string \\
keeplog	& no		& record all interactive commands in logfile? \\
logfile	& ``home\$logfile.cl''	& name of the logfile \\
logmode	& (see manpage)	& logging control \\
menus	& yes		& display menu when changing packages? \\
mode	& "ql"		& default mode for servicing parameter queries \\
notify	& yes		& send done message when bkgrnd task finishes? \\
szprcache & 3$-$4	& size of the process cache \\
\hline
\end{tabular}
\end{center}
\medskip

\noindent
A full list of CL parameters can be obtained with the \emphasize{lparam}
command, or by typing the command \usertype{help language.cl}.  The latter
provides a brief description of each CL control parameter including references
to \taskname{language} package manual pages containing more detailed
information.

Changes that you make to any of the CL task parameters by assignment during
a session will be lost when you log out of the CL.
This is in contrast to the parameters of a normal task, which are learned
by the CL. If you want the CL to ``remember'' values of CL parameters,
you should initialize them to your personal default values in your
\filename{LOGIN.CL} file and they will be reestablished for you each time
you log in.

\subsection{Setting the Editor Language and Options}

\ppind
The parameter editor (\usertype{eparam}) command and the history
editor (\usertype{ehistory}) both use the same simple set of edit commands
and a choice of editor languages is available.  The command:

\begin{quotation}\noindent
\comptype{cl>} \usertype{set editor = emacs}
\end{quotation}

\noindent
will set the edit mode for both editors to use the Emacs set of keystrokes.
This also changes the editor that is invoked when
you issue the \usertype{edit} command, so that all of the editor interfaces
that are available will appear to operate in the same way. 

Editor choices, with their associated key bindings, are:

\begin{itemize}
\item EDT (the default for VMS devotees) 
\item Vi (ditto for their UNIX counterparts)
\item Emacs (which runs on either system)
\end{itemize}

For convenience, all of these editor choices support
use of the cursor keypad keys and the \key{DELETE} key; the 
ambitious user may define his own personal set of command key bindings. 
The bindings that are available by default in IRAF are shown in an
Appendix (\S A.4).  The default editor language that IRAF will start 
with is as shown above, chosen for compatibility with the host operating
system.  You may, of course, include a \usertype{set} command in 
your \filename{LOGIN.CL} file to establish your own preferred editor.

The edit facilities provided within IRAF are limited in scope, since
they are only intended to facilitate manipulation of user accessible
internal structures, task parameter blocks and history file. IRAF
has not implemented a full scale text editor, so the \usertype{edit}
command invokes the standard system editor which you choose by setting
the \usertype{editor} parameter.
A host system editor must be used for all major text manipulations,
but since it is invoked from within the IRAF environment the continuity
of your session is not lost.

In addition to selecting the editor language to be used, there are a few user
settable options available to control the operation of the \taskname{eparam}
and \taskname{ehistory} tasks.  These options are set by setting the string
values of the CL parameters \taskname{epinit} and \taskname{ehinit}.
For example, setting the \taskname{verify} option for \taskname{ehinit}
will cause the history mechanism to pause waiting for a command to be
edited or inspected, before executing the command.
Read the manual pages for the \taskname{eparam} and \taskname{ehistory} tasks
for a full description of these control options.

\subsection{The History Mechanism}

\ppind
The CL history mechanism keeps a record of the commands you enter and
provides a way of reusing commands to invoke new operations with a minimum of
typing. The history mechanism should not be confused with the logfile;
the history mechanism does not make a permanent record of commands, 
and the logfile cannot be used to save typing 
(except by using the editor on it after the end of the session). 
With the history editor, previous commands can easily
be edited to correct errors, without the need to retype the entire command.

The \usertype{history} command is used to \emphasize{display} command lines.
By default, the last 15 commands entered are printed, each preceded by
the command number.  To show the last \emphasize{n} commands, 
add the argument \usertype{n} to the \usertype{history} command line:

\begin{quotation}\noindent
\comptype{cl>} \usertype{history 3} \\
\comptype{101 urand 200 2 \pipe graph po+ marker=circle szmarker=.03} \\
\comptype{102 help graph \pipe lprint} \\
\comptype{103 history} \\
\comptype{cl>}
\end{quotation}

\noindent
and note that this number (\emphasize{n}) will become the new default. 
If you ask for a negative number of commands (\emphasize{-n}), 
the default will not change.

The \usertype{history} command allows previous command sequences to be
displayed, but a related mechanism must be used to re-execute, or to
edit and execute, commands. You can use the history file \emphasize{editor} 
by issuing the command \usertype{ehistory}. Once you are in the history editor,
the cursor (arrow) keys can be used to move about in the history file. You
may select any command and edit it using the simple edit commands described
previously (\S 3.2.3) for the \taskname{eparam} task. Such functions as
deletions and insertions of words or characters, delete to end of line, and
a simple string search and replace capabilities are provided. 
The Appendix lists the full range of commands that are supported. 
The edited command is executed by hitting
\key{RETURN}. Note that it is a \emphasize{new} command and, as such, it is
appended to the history file. The current contents of the history file
are not changed.

It is possible to recall \emphasize{individual} commands and edit them;
the special character `\upa' or the \usertype{ehistory} command may be
used for this.  Given the history record sequence shown above,
any of the following commands could be used to fetch command 101:

\begin{quotation}\noindent
\begin{tabbing}
\comptype{cl>} \usertype{\upa 101} \hspace{2cm} \= \#~fetch~command~101 \\
\medskip
\comptype{cl>} \usertype{ehist -3}  \> \#~fetch~third~command~previous \\
\medskip
\comptype{cl>} \usertype{\upa ur}  \> \#~fetch~command~starting~with~``ur'' \\
\medskip
\comptype{cl>} \usertype{ehist ?mark?} \> \#~fetch~command~containing~``mark''
\end{tabbing}
\end{quotation}

The history command \usertype{\upa ur} finds the last command
\emphasize{beginning} with the string ``ur'', while the command
\usertype{ehist ?mark?} finds the last command \emphasize{containing} the
string ``mark'' (the trailing `\usertype{?}' is optional if it is the
last character on the line). A single `\upa' fetches the last command
entered.  Successive `\upa' commands 
will fetch the next preceding command lines from the history file.

The selected command is echoed on the screen, with the cursor pointing at it.
At that point, the command can be executed just by typing \key{RETURN},
or it may be edited. The standard set of editor operations also apply
when you edit a command in single line mode. Note that compound statements
(those enclosed in pairs of braces~``\{~$\ldots$~\}'') are treated as a
\emphasize{single} statement by the editor.  Only one command line (which may
be a compound statement) can be edited at a time with the history editor.

Sometimes you will want to reuse the \emphasize{arguments} of a previous
command.  The notation `\upa\upa' refers to the \emphasize{first} argument
of the last command entered, `\upa\$' refers to the \emphasize{last} argument
of the command, `\upa$*$' refers to the whole argument list, `\upa0' refers
to the taskname of the last command, and `\upa$N$' refers to argument
\emphasize{N} of the last command entered.  Thus,

\begin{quotation}\noindent
\comptype{cl>} \usertype{dir lib\$$*$.h,home\$login.cl} \\
\comptype{cl>} \usertype{lprint \upa\upa}
\end{quotation}

\noindent
displays a table of the files specified by the template, and then prints
the same files on the line printer.

One of the most useful features of the history mechanism is the ability to
repeat a command with additional arguments appended.  Any recalled command
may be followed by some extra parameters, which are appended to the command.
For example:

\begin{quotation}\noindent
\comptype{ut>} \usertype{urand 200 2 \pipe graph po$+$} \\
\comptype{ut>} \usertype{\upa\upa  title = '200 random numbers'} \\
\comptype{urand 200 2 \pipe graph po$+$ title = '200 random numbers'}
\end{quotation}

\noindent
in this case, the notation `\upa\upa' refers to the last 
\emphasize{command} entered.
The notation is unambiguous because the `\upa\upa' appears at the start of
the command line.  Do not confuse it with the use of `\upa\upa' to reference
the first argument.

\subsection{Foreign Tasks}

\ppind
The foreign task mechanism provides an alternative to the OS escape mechanism
for sending commands to the host operating system.  The advantage of the
foreign task mechanism is that it allows foreign commands to be made available
within the IRAF environment just as if they were normal IRAF tasks.
Such commands may be abbreviated, their output may be redirected or piped,
the commands may be run in batch mode, and the argument list is parsed and
evaluated by the CL, hence may contain any valid CL expression.  Users should
beware, however, that IRAF virtual filenames appearing in the argument list
of a foreign task are not normally translated to their host equivalents, since
IRAF knows nothing about the argument list of a foreign task
(the \taskname{osfn} intrinsic function may be referenced in the argument
list to explicitly perform the translation, if desired).

To declare several foreign tasks with the same names in IRAF as in the host
environment, use the following form of the \taskname{task} statement:

\begin{quotation}\noindent
\comptype{cl>} \usertype{task \$mail \$grep $=$ \$foreign}
\end{quotation}

\noindent
This declares the new tasks \taskname{mail} and \taskname{grep} in the current
package, whatever that may be.  If the current package is subsequently exited,
the task declarations will be discarded.

To declare a foreign task with a more complex calling sequence, use the
following form of the foreign task declaration:

\begin{quotation}\noindent
\comptype{cl>} \usertype{task \$who $=$ "\$show users"}
\end{quotation}

\noindent
This example would be used on a VMS host to map the IRAF foreign task
\taskname{who} to the VMS command \usertype{show users}.  If there are
any arguments on the command line when the task is called, they will be
converted to strings and appended to the command prefix given.

The \filename{LOGIN.CL} file contains a default \filename{USER} package
containing examples of several foreign task statements which may prove
useful on the local host.  Users should feel free to modify or extend
the \filename{USER} package, since it is provided with that in mind and
provides a convenient structure for personalizing the CL environment.

\subsection{Cursor Mode}

\ppind
Whenever an IRAF program reads the graphics or image display cursor,
the cursor lights up or starts blinking, indicating that the user should
position the cursor and type a key on the terminal to return the cursor
position, keystroke typed, and possibly a character string entered by
the user, to the calling program.  The user may also read the cursor
directly, just as a program would.  For example, the command

\begin{quotation}\noindent
\comptype{cl>} \usertype{$=$gcur}\\
\smallskip
\comptype{345.21 883.13 1 r}
\end{quotation}

\noindent
would read the graphics cursor, printing a cursor value string such as that
shown noting the world coordinates of the cursor, the world coordinate system
(WCS) of reference, the keystroke typed to terminate the cursor read, and
the string entered by the user if the key typed was \usertype{:} (colon).

The CL is said to be in \emphasize{cursor mode} whenever the CL is waiting
for the user to type a key to read a cursor.  Cursor mode reserves the upper
case keystrokes for itself, providing all sorts of useful functions to the
user via the reserved keystrokes.  For example, the graphics display can be
zoomed or panned, a hardcopy of the current screen can be made on a hardcopy
device, or the screen can be saved in or restored from a graphics metafile.
For more information on cursor mode, type \usertype{help cursors} while in
the CL.

\subsection{Background Jobs}

\ppind
The CL provides facilities for manipulating and displaying data and
allows interactive development and use of data analysis functions.  However,
many fully developed image analysis scenarios are very time consuming
and need not be run interactively.  IRAF allows such functions to
be developed interactively and then processed in a batch mode as
a background task, thus freeing the terminal for other interactions
once the background tasks have been started.  Several
background tasks can be running at once, and these may be identical
tasks that are just operating on different data sets.  

Any command, including compound commands that may involve calls to several
tasks, may be executed in the background by appending the ampersand character
`\&' to the end of the command block.  The CL will create a new control
process for the background job, start it, display the job number of the
background job, and return control to the terminal.  
Background job numbers are always small integers in the range 1 to n, 
where n is the maximum permissible number of background jobs (typically 3-6).

\begin{quotation}\noindent
\comptype{pl>} \usertype{contour m92 dev=stdplot \&} \\
\comptype{[1]} \\
\comptype{pl>} 
\end{quotation}

\noindent
If a task runs to completion, and if the CL \irafname{notify} parameter 
is enabled (the default), the message 
``\comptype{[n] done}'' will be printed on your
terminal when the task completes. 

Jobs running in the background may use all of the commands and
perform any of the operations that interactive tasks can, but
extensive user interaction with background jobs is necessarily 
somewhat limited (and not too appropriate).  
Another difference is that background jobs \emphasize{do not} update
parameter \filename{.PAR} files.  This is done to minimize the 
confusion that could occur if a background job asynchronously
updated the parameter set for a task that was running interactively,
or vice versa.  The implication of this is that parameter values that
are to be output by a task running in the background must be explicitly
written into a file if they are to be available outside that job.  
Parameters passed between tasks in the same job are still processed 
correctly.

If the background job writes to the standard
output, and the standard output has not been redirected, the output of
the background job will come out on your terminal mixed in with the output
from whatever else you are doing. Since this is generally not desirable, the
\filename{STDOUT} (and \filename{STDERR})
for the background job should probably be redirected to a
file and perused at a later time.  The following example computes image
statistics and directs these, and any error messages, to the file
\filename{STATS.TXT}: 

\begin{quotation}\noindent
\comptype{im>} \usertype{imstatistics m87 $>$\& stats.txt \&} \\
\comptype{[2]} \\
\comptype{im>} 
\end{quotation}

If during the processing of a background job, the job finds it necessary to
query for a parameter, the message

\begin{quotation}\noindent
\comptype{[1] stopped waiting for parameter input }
\end{quotation}

\noindent
will appear on your terminal.  It is not necessary to respond to such a
request immediately; when a convenient point is reached, respond with:

\begin{quotation}\noindent
\comptype{cl>} \usertype{service 1}
\end{quotation}

\noindent
The prompt string from the background job will be printed, just as if
you were running the job interactively.  Respond to the query and the
background job will continue executing.  If you do not respond to the request
for service from a background job, it will eventually time out and abort.

More control over the disposition of a batch job is possible by appending
optional arguments to the \usertype{\&} at the end of the command line,
when the job is submitted.  The default action if no arguments are appended
is to run the job as a subprocess of the CL, at a priority level one less
than the CL, with output coming to the terminal unless redirected.
To run the job as a subprocess at a specific priority, a numeric string
specifying the \emphasize{host dependent} priority level may be added after
the \usertype{\&}.  For example,

\begin{quotation}\noindent
\comptype{cl>} \usertype{bigjob \&4}
\end{quotation}

\noindent
will submit the job at host priority level 4.  The priority level may also
be specified relative to the CL priority in a machine independent way,
e.g., \usertype{\&-1} will submit the job at a priority level one notch
down from the current CL priority (this is the default).

On systems which support batch queues (e.g., VMS) jobs may also be submitted
to a batch queue.  To submit a job to a batch queue, simply add the name of
the queue after the \usertype{\&}, e.g.:

\begin{quotation}\noindent
\comptype{cl>} \usertype{bigjob \&fast}
\end{quotation}

\noindent
will submit the job to the "fast" queue.  IRAF supports three logical batch
queues, the \usertype{fast} queue, for short jobs to be run at a high priority,
the \usertype{batch} queue, for medium size jobs, and the \usertype{slow}
queue, for big jobs that may run a long time.  The host system name of the
desired queue may also be given.  If a big job is submitted to a high priority
queue it will be killed by the system when it exceeds the maximum quota
permitted for that queue; see your system manager for more information on
the batch queues supported by your system.

Sometimes it is desirable to wait for a background job to complete before
resuming interactive work.  For example, you might reach a point where
you cannot proceed until the background job has finished writing a file.
The \usertype{wait} command is used to wait for currently running
background tasks to complete.

\begin{quotation}\noindent
\comptype{cl>} \usertype{wait 1; beep}
\end{quotation}

\noindent
will halt the interactive session until background job 1 completes. Issuing
a \usertype{wait} command without a job number will cause the interactive
session to wait for \emphasize{all} background jobs to complete.

In order to discover the status of all background jobs that you
have running, the command:

\begin{quotation}\noindent
\comptype{cl>} \usertype{jobs}
\end{quotation}

\noindent
may be used.  The job number will be displayed along with information
about the command that was used to start the job.
The command \usertype{spy v} may also be used.  It will request the host
operating system to display the processor status (in an OS-dependent form),
including information on the status of all processes running on the system.

There are important differences in the behavior of background jobs on different
IRAF host systems.  Under UNIX, the background tasks are independent of
activities that may (or may \emphasize{not}) be going on interactively. 
UNIX users may terminate their IRAF session and even logoff the UNIX system
altogether, and the background jobs will continue merrily along.
In the VMS implementation of IRAF, background jobs may run either as
sub-processes or as regular VMS batch jobs in one of the system wide batch
queues.  The default is to run background jobs as sub-processes, in which
case the jobs will be killed if you log out of VMS (even if you have DETACH
priviledge).  Under \emphasize{both} systems, once the interactive CL session
is terminated, communication with still-running background jobs
\emphasize{cannot} be re-established, even by re-entering the CL.

\subsection{Aborting Tasks}

\ppind
Any interactive task may be aborted by typing the interrupt sequence 
\key{CTRL/C}.
Control will return to the point at which the last interactive command was
entered.  When an IRAF program run from the CL is interrupted, it will
usually perform some cleanup functions, deleting partially written files and
so on.  If an error (or another interrupt) should occur during error recovery,
IRAF will issue the following message:

\begin{quotation}\noindent
\comptype{PANIC: Error recursion during error recovery}
\end{quotation}

\noindent
A panic abort is usually harmless, but may result in some half-written
dregs of files being left behind.  A more serious problem occurs when
a subprocess becomes hung (uninterruptable).  Repeatedly interrupting the
CL when this occurs will eventually cause the CL to give up and shut down,
necessitating a restart.  A quicker solution might be to use the host system
facilities to forcibly kill the subprocess.

The \usertype{kill} command may be used to abort a background job. The 
argument is the logical job number printed by the CL when the background 
job was spawned. (It may also be a list of jobs to be killed.)

\begin{quotation}\noindent
\comptype{cl>} \usertype{kill 1} \\
\medskip
\comptype{cl>} \usertype{kill 1 3}
\end{quotation}

In systems that support batch queues as well as sub-processes,
the \usertype{kill} command may be used to control these as well.

%#########################
\newpage
\thispagestyle{empty}

\begin{center} \vspace*{1in}
\large NOTE
\end{center}
\vskip 1cm
\rm

The remainder of this document is from the original draft and has not yet
been brought up to date and may contain minor inaccuracies or omissions.

\newpage
\section{The CL as a Programming Language}

All of the examples that have been presented thus far treat the use
of the CL as a \emphasize{command language} for running existing tasks.
The CL can also be used as a high-powered desk calculator, one that
can operate on and display arrays of data as well as scalars;
and that can be fully programmed.
The following sections introduce the programming oriented functions
that are provided in the CL as background for understanding
the creation of new user tasks.  

Extensive use of the CL as a programming language has not been heavily
emphasized, because there are substantial performance penalties 
associated with the use of interpreted languages, especially when
dealing with large amounts of data.  At the same time, the availability
of an interactive environment that allows easy exploration of
alternative analysis scenarios is very attractive, since it largely
does away with the typical development cycles of edit; compile; link;
test; edit; compile; $\ldots~$.  Interactive development provides 
immediate, possibly visual, feedback about the effect of the various 
analytical tools upon your data. 

Before delving into the details of the language however, a comment is in
order regarding the distinction made in the CL between 
\irafname{command mode} and \irafname{program mode}. 
\emphasize{Modes} in user interfaces are not in vogue
because of the potential source of confusion, the  "How does that command
work now?" problem.  IRAF is a little schizoid in this regard because of the 
desire for convenient user commands on the one hand: (to minimize 
the need for specific command parameter delimiters,
quotes around character strings and special handling of 
file names and meta-characters); and the desire for
a familiar language syntax for programming type activities on the other.

To resolve this dilemma, the CL has two modes: \irafname{command mode} -
which is the default and is used for most terminal interactions; and
\irafname{program mode} - which is:

\begin{itemize}
\item Entered within the body of a procedure.
\item Entered within parenthesized expressions.
\item Entered on the right-hand side of an equal sign ('=').
\end{itemize}

\noindent
The syntax of the CL2 programming language was chosen to be as 
compatible as possible with SPP, the portable language in which 
most of IRAF is written.

Aspects of the command/program dichotomy have
already crept into the discussions of identifiers, which are treated 
as character strings in command mode (\S 4.3.1), but which will be
evaluated as a parameter name if thay are enclosed in parentheses.
In the same vein, when inserted in a parenthesized expression, 
an identifier that is handled as a character string
in command mode will be treated as a variable name unless it is quoted.  

In program mode there is a simple disambiguating rule that can be safely 
used: always quote character strings and always parenthesize expressions.  
While this resolves the ambiguity it is not likely to be too popular
with most users, who typically choose a minimum entropy approach.
In the following sections, where programming issues come under
discussion, programming mode will be assumed as the default.

\subsection{Expressions in the CL}

The CL has a conventional modern expression syntax (borrowed heavily
from C and Ratfor) which should feel familiar to most
users.  The following operators are provided, presented in order of 
precedence:

\begin{tabular}{ll}
{\it Operator}  &   {\it Action} \\

$**$              &  exponentiation \\
$*, /$    &  the usual arithmetic operators \\
$+, -$	  &  and the rest of them in precedence order \\
$//$              &  string concatenation \\\
\&,  {\tt ||}    &  and, or \\ 
!                 &  not \\
$<$,   $<=$        &  less than, less than or equals \\
$>$,   $>=$        &  greater than, greater than or equals \\
$!=$,   $ ==$        &  not equal, equal (2 equal signs) 

\end{tabular}

\noindent
Parentheses may be used to alter the default order of evaluation of an
expression.  Quotes are not optional in expressions or anywhere inside
parentheses; identifiers are assumed to be the names of parameters and
strings \emphasize{must} expressly be quoted using either single 
or double quotes.

The data types supported by the CL
are \emphasize{boolean, integer, real, char}, and several exotic types
(\emphasize{imcur, gcur,} and \emphasize{file}) that are touched upon 
later in this section.   Observe that although the CL has \emphasize{no}
complex datatype, operations on complex data is supported in the rest
of the IRAF system, including the \irafname{SPP} language and
interface libraries.
Arrays of the regular data types of up to seven dimensions are supported.
Explicit type conversion is implemented with the intrinsic functions
\emphasize{int, real}, and \emphasize{str}, 
the last converting an argument of any data type into a string.
Mixed-mode expressions involving integers and reals are permitted,
the data type of the result is promoted to the type of the target
of the assignment operator.

The CL provides a special statement, called the \emphasize{immediate}
statement, for evaluating expressions
and printing the value at the terminal.  The form of the statement
is an expression preceded by an equals sign:

\begin{quotation}\noindent
= {\it expression}
\end{quotation}

\noindent
or, if you prefer, the more conventional and more general \usertype{print}
command can be used with the same results:

\begin{quotation}\noindent
\comptype{cl>} \usertype{print (}{\it expression} [, {\it expression},
       $\ldots$ ] \usertype{)}
\end{quotation}

\subsection{CL Statements and Simple Scripts}

This is not a language reference manual; nonetheless, 
you will find it helpful to understand a few of the more useful 
types of statements provided in the CL.
We will not attempt to present a
complete definition of the syntax of the command language,
a compendium of basic statement types is listed in the Appendix.
The preceding section introduced two statements,
the \emphasize{immediate} statement and the \emphasize{print} statement.
The \emphasize{assignment} statement should also be familiar from
previous examples.

Often we do not want simply to assign a value to a parameter,
but rather we want to increment, decrement, or scale one.
These operations can all be performed with assignment statements
in the CL, using the assignment operators \pluseq, \minuseq, \timeseq,
\diveq, and \concateq. For example, to increment the 
value of a parameter, we could use the \pluseq~ assignment statement:

\begin{quotation}\noindent
\comptype{cl>} \usertype{y \pluseq {} (x $**$ 2)}
\end{quotation}

This statement increments the CL parameter \usertype{y}
by the value of the expression \usertype{(x$**$2)}.  The same 
operation could also be done with the next statement, but with some
small increase in typing effort.

\begin{quotation}\noindent
\comptype{cl>} \usertype{y = y $+$ (x $**$ 2)}
\end{quotation}

\noindent
The advantage of having a shorthand notation becomes obvious
when you contemplate doing arithmetic on a fully specified
parameter name as in the next examples.

\subsubsection{Assigning Values to Task Parameters}

The assignment statement may be used to set the value of a parameter
or a variable.
Most parameters are local to some task, and a ``dot'' notation may
be used to unambiguously name both the task and the parameter.
Thus, the statement:

\begin{quotation}\noindent
\comptype{cl>} \usertype{delete.verify = yes}
\end{quotation}

\noindent
may be used to set the value of the \taskname{verify} parameter 
belonging to the task \taskname{delete}.  Since verify is a hidden
parameter, direct assignment is the only way to permanently change
this option setting.

The task \taskname{delete} belongs to the \taskname{system} package.
Since IRAF permits several packages to be loaded at the same time,
if there happened to be another task named \taskname{delete} in the
search-path, we would have to specify the package name as well to make
the assignment unambiguous:

\begin{quotation}\noindent
\comptype{cl>} \usertype{system.delete.verify = yes}
\end{quotation}

\noindent
In the unfortunate situation of two tasks with the same name in different
packages, we would also have to specify the package name explicitly
just to be able to \emphasize{run} the task:

\begin{quotation}\noindent
\comptype{cl>} \usertype{system.delete {\it files}}
\end{quotation}

\noindent
In most cases such name collisions will not occur.  

The ability to have
the same task names in more than one package has some very positive
benefits however, in that a new package of tasks that has the 
same calling conventions as a standard one may be readily inserted 
in the search path.  This allows new algorithms to be tested without
impacting the standard system, and also provides the hooks whereby
alternate implementations of existing functions (using an array processor
for instance) can be dynamically linked into the system.

\subsubsection{Control Statements in a Script Task}

The CL provides \emphasize{if, if else, while, for, next}, and
\emphasize{break} statements for controlling the flow 
of execution in a command sequence.  These statements
are quite useful for writing control loops at the command
level.  Other control statements (\emphasize{case, switch,} and
\emphasize{default}), which may be familiar from C or RATFOR,
are also provided to ease the programming effort.
By way of example, to print the values of the first ten powers
of two the following statements can be used:

\begin{quotation}\noindent\comptype{
cl> i=1; j=2\\
cl> while (i $<=$ 10) \{\\
>>>     print (j)\\
>>>     j \timeseq {} 2\\
>>>     i \pluseq {} 1\\
>>> \}}
\end{quotation}

\noindent
The second of these two statements is a compound statement;
note that the prompt has changed to \comptype{>>>} to indicate this.

Consider the parenthesized argument list in the \usertype{print}
command in the above loop.  
If the parameter (\usertype{j} in this example) were not enclosed in 
parentheses, the CL would interpret it as a string rather than a parameter,
and would erroneously print ``\comptype{j}'' each time through the loop.
Remember that the CL will interpret identifiers as a string if found
outside parentheses, but as the name of a valid parameter or variable
inside parentheses.  If the CL cannot find the identifier in its
dictionary an error message will be issued.
To avoid nasty surprises like this, one should \emphasize{always}
parenthesize argument lists in loops and within script tasks, and
make a habit of explicitly quoting items that are to be treated as
strings.

The example uses the built-in CL variables \usertype{i}
and \usertype{j}.  A number of variables are provided in the CL for
interactive use; the integer variables provided with the CL
are \usertype{i,j,k}; the real variables are \usertype{x,y,z};
the string variables are \usertype{s1,s2,s3}; the booleans are 
\usertype{b1,b2,b3}; and a list-structure pointer called 
\usertype{list} is also provided.
The CL also has the ability to define new variables interactively;
which is discussed in section \S 6.4.

\subsection{Intrinsic and Builtin Functions}

The usual Fortran intrinsic functions 
(with the exception of the hyperbolic and complex functions)
are provided in the CL,  along with some others specific to IRAF.  
The other intrinsic and builtin functions are those like
\usertype{set}, \usertype{if}, \usertype{while}, \usertype{case}; 
the data declaration and initialization statements; and the
task and I/O control statements that are described throughout 
the body of this document, and are listed in Appendix A.   The intrinsic
functions \emphasize{must} be used in a statement where the returned
value is explicitly assigned or output in some way. 
To compute (and display) the value of \usertype{sin(x)}:

\begin{quotation}\noindent
\comptype{cl>} \usertype{= sin(x)}
\end{quotation}

\noindent
must be entered, just typing \usertype{sin(x)} by itself is an error.
The names of intrinsic functions may be used in other contexts, e.g. as
parameter names, but care is needed to avoid confusion.

\begin{tabular}{lll}
{\it Function}  &   {\it Action} 		& {\it Example} \\
    abs &	absolute value			& z = abs(x) \\
    atan2 &	arctangent  			& r = atan2(y, x) \\
    cos &	cosine 				& x = cos(r**2) \\
    exp &	exponentiation 			& z = exp(3) \\
    frac &	fractional part of a number 	& i = frac(y) \\
    int &	convert input to integer 	& j = int(z*3) \\
    log &	natural logarithm of a number 	& x = log(z) \\
    log10 &	base 10 logarithm of a number 	& y = log10(x) \\
    max &	maximum value from input 	& x = min(1,17.4,43) \\
    min &	minimum value from input	& y = max(47,11,92.3) \\
    mod &	modulus 			& z = mod(x, {\it base}) \\
    radix &	radix to any base 		& y = radix(x, {\it base}) \\
    real &	convert input to real 		& x = real(i) \\
    sin &	sine 				& y = sin(3*r) \\
    sqrt &	square root 			& z = sqrt(x**2 + y**2) \\
    str &	convert input to a string 	& s1 = str(num) \\
    stridx &	index of character in string 	& i = stridx(s1, 'abc') \\
    substr &	select substring from string 	& s1 = substr(s2, 3, 7) \\
    tan &	tangent 			& x = tan(2*theta)
\end{tabular}

As examples of the use of these functions, try entering the following 
expressions and see if you can predict the results 
(the next sections have the clues):

\begin{quotation}\noindent
\comptype{cl>} \usertype{= (sin(.5)$**$2 + cos(.5)$**$2)} \\
\smallskip
\comptype{cl>} \usertype{= 2 / 3.} \\
\smallskip
\comptype{cl>} \usertype{= (mod (int(4.9), 2) $==$ 0)} \\
\smallskip
\comptype{cl>} \usertype{= 'map' // radix (512, 8)} \\
\smallskip
\comptype{cl>} \usertype{= delete.verify}
\end{quotation}

\noindent
You may have been surprised that the result of the last example was
\comptype{no}.  This is because \usertype{verify} is a boolean 
parameter which can only take on the values \emphasize{yes} and 
\emphasize{no}.

\irafname{CL++} \\
All of the intrinsic functions in IRAF return a value, the builtin
tasks currently do not.  With the completion of changes to the CL
that are now in progress, intrinsics and builtin tasks, and any user defined
functions or tasks may return an optional value.  Tasks can thus be
called either in the FORTRAN 'subroutine' style or in the 'function'
style, where a value is expected.  If a task returns a value that is
not assigned to a variable it will be silently ignored.

\subsection{Defining New Variables and Parameters}

The CL provides a default set of variables that can be used for scratch
computations, and you may declare other variables as needed.
Each task that is invoked, whether it is a CL script task
or an external executable task, may have input or output parameters
associated with it, and these may be defined within the package for the 
task or as part of the task itself. Data declarations
for variables contain the item name and type information,
and may also contain an optional initialization clause.  Declarations
for function parameters are identical to those for variables, but they 
may contain optional fields to specify prompt strings, to define a valid 
data range, or to enumerate a list of valid values.

The simplest data declarations define local or global variables. 
The statement:

\begin{quotation}\noindent
\comptype{cl>} \usertype{int int\_var}
\end{quotation}

\noindent
defines a simple integer variable. If this command is entered at the root
(\comptype{cl>} prompt) level, it will define a variable that is globally
accessible to any other task that is executed.  When the same statement
is incorporated into the body of a script task (after the \usertype{begin}
statement), it will define a local variable visible only to that script task or
to any other task that is called by that script task. Variables declared within
the body of a package definition are globally available to all tasks
within that package, but will be removed from the set of
addressable variables when that package is unloaded.

User-defined variables may be used just like any standard IRAF
variables: in expressions, passed as parameters to
other tasks, or displayed in a variety of ways.  In addition,
these variables may be initialized when they are declared:

\begin{quotation}\noindent
\comptype{cl>} \usertype{real e = 2.71828183 }
\end{quotation}

\noindent
establishes a real variable and assigns it an initial value.
This variable may be treated like a constant (as in this case) 
or may be re-assigned another value during the course of computations.

The formal \taskname{parameters} for a task must be defined if the CL
is to provide any of the range checking or input prompting activities.
In the absence of a declaration, or if one is provided that
does not define these optional fields, only the name of the parameter
will be used for prompting and no range checking can be performed.
The simplest case of a \emphasize{parameter} declaration looks just like the
simple variable declaration shown above; but it must
occur within a task body \emphasize{before} the \usertype{begin} statement,
or define a parameter that is named in the calling list for a task.

The syntax of a data declaration statement is:

\begin{quotation}\noindent
\begin{tabular}{lll}
\comptype{cl>} {\it type} & [{\it = initializer} [,{\it initializer}] $\ldots$ ] \\ 
	& \{ \\
	& [{\it initializer} [,{\it initializer}] $\ldots$ ] \\
	& [{\it opt\_field=value} [,{\it opt\_field=value}] $\ldots$ ] \\
	& & \}
\end{tabular}
\end{quotation}

\noindent
where the valid data types for these declaration statements are shown in
the following table:

\begin{tabular}{ll}
{\it Data Type}  &   {\it Explanation} \\
int &		integer (scalar and array) \\
real &		double precision floating point (scalar and array) \\
char &		character strings (scalar and array) \\
bool &		boolean, yes/no (scalar and array) \\
file &		file name \\
struct &	special form of mutli-token string \\
gcur &		graphics cursor struct \\
imcur &		image cursor struct 	
\end{tabular}

Most of these data types should be familiar to you, but the IRAF
\irafname{struct} is a special class of data element that is used to
hold multi-token strings, mostly for input.  It will be referred to again
in the section on I/O facilities in the CL (\S 6.8).  \irafname{Gcur}
and \irafname{imcur} are both structs that return a multi-token result,
namely a string with RA, DEC and a data value.  List structured parameters,
which are described in section \S 6.9 are typically declared as
structs.

The optional fields in a data declaration are used to define the data
ranges for checking, prompt strings, special file type information,
or a list of enumerated items.  
Syntactically, the specification of these optional fields is treated 
like a special form of initialization; the valid field names are 
described in the following table.

\begin{tabular}{ll}
{\it Field Name}  &   {\it Explanation} \\
mode &		auto, query, hidden processing modes \\
min &		minimum value for range checking \\
max &		maximum value for range checking \\
enum &		enumerated list of valid responses (mutex with min/max) \\
prompt &	prompt string for undefined values \\
filetype &	r, rw, w, x file type specification
\end{tabular}

\noindent
All of these fields are optional, the \irafname{mode} defaults to
\irafname{auto}; \irafname{min/max} range checking defaults to NULL;
and \irafname{filetype}, which is valid only for files, defaults to
read only (\irafname{'r'}).  The enumerated type (\irafname{enum}),
which names the specific responses that are acceptable, is
mutually exclusive with range checking, which defines a continuum
of values that will be accepted.

To declare an integer parameter, enable range checking for positive
values and provide a prompt string, use:

\begin{quotation}\noindent
\comptype{cl>} \usertype{int new\_parm \{ min=0, prompt='Positive integer' \} }
\end{quotation}

\noindent
and as an example of an
enumerated list of valid input values, consider:

\begin{quotation}\noindent
\comptype{cl>} \usertype{char color \{enum = 'red \pipe green \pipe blue'\} }
\end{quotation}

\noindent
which defines a default length character string that is initially undefined
and that has an enumerated list of three valid input values.
If  you  attempt to use the variable \usertype{color} before a value has 
been assigned to it, you will be prompted for a value.
If you try to assign it a value other than one of those that 
are enumerated, an error is reported.

\subsection{Declaring Array and Image Data}

Variables and task parameters may be defined as arrays of any of the 
data types: int, real, char or bool.  Arrays may have up to seven dimensions.
Array and image data will be referenced identically in the future, 
but for now there
are some differences that are worth noting.  Images are treated
as large arrays of data that are stored on disk, 
and it is the amount of data to be
processed that determines the choice of storage mechanism.  Images
will typically be quite bulky; it is not unusual for a single image
scene to involve five to ten megabytes of data.  For this reason, image data
are most efficiently stored in disk files, and operations upon the
data are performed by buffering it into memory as needed.  The
\emphasize{main difference} between an array of data and an image is that
the image will be buffered on disk.

IRAF provides a default \filename{IMDIR} directory that may be used for
bulk image file storage by all users, but it also has facilities that
manage the storing, copying, and accessing of such data sets for users who
wish to store this sort of data in their own directories.
The logical directory \filename{IMDIR} is where the IRAF system will store
your image data \emphasize{by default}. IRAF images will appear to be created
in your local user directory, but in fact it is only the \irafname{image
header file} which goes there. The bulk pixel data are 
put in a second file that is part of a temporary files
system, configured and managed with large datasets in mind. Such
\irafname{pixel storage files} are transparent to the user, but if you have a 
great deal of data, you may find it more efficient to set up your own directory
on a temporary files system, and to redefine \filename{IMDIR} accordingly.
If one has a personal \filename{IMDIR}, it is also convenient to save data on
tape and later restore it to disk; the header files are usually small
enough so that they need not be archived if the data is going to be restored
within a week or two.

To declare an integer array of length 100, type:

\begin{quotation}\noindent
\comptype{cl>} \usertype{int iarray[100] = 100(0)}
\end{quotation}

\noindent
which also initializes the array \usertype{iarray} to zero.  A two dimensional 
array with data range checking can be specified by:

\begin{quotation}\noindent
\comptype{cl>} \usertype{real rarray[50, 50] \{ min=0, max=100 \} }
\end{quotation}

\noindent
This array could be defined as an image by using the following declaration
to indicate the different \emphasize{storage class} of the data:

\begin{quotation}\noindent
\comptype{cl>} \usertype{real image rarray[50, 50] \{ min=0, max=100 \} }
\end{quotation}

\noindent
where the data in this example would be stored on disk.

The choice of whether data is to be stored
in an array which is stored entirely in memory,
or as an image on disk is up to the user.
The choice should be predicated upon the
amount of data that is to be manipulated, since speed and efficiency
of operation will be better using the image mode for data arrays
much larger than a few hundred items.  At present, the
statements that manipulate these two data forms are somewhat different,
as is explained in the following section.

During the development of IRAF, the handling of images has
been a prime concern, representing as it does the major computational
and I/O load that must be accomodated. Image files currently
may be created on disk, and there are image processing functions that 
know how to process this class of data. The IRAF packages 
\taskname{images, imred}, and \taskname{plot} currently 
handle image data.
The specification of this processing is similar, but
not identical to, the operations performed on array data.
The next section discusses use of image data and arrays within the CL.

\irafname{CL++} \\
At the present time the \irafname{IMIO and DBIO} subroutine libraries
are still undergoing design and enhancement.  As a result of this effort,
the processing of image type data is not yet in final form.  Existing IRAF
packages do support image processing and display
functions and these will appear to be functionally the same after the
development has been completed.  The SDAS packages also support image
processing and display functions, but at this point in time the disk 
format of these two types of data is vastly different, 
and on this interim system, data from these two packages
cannot easily be mixed.  This incompatibility is to be rectified when
the completed \irafname{IMIO and DBIO} libraries are available.

\subsection{Processing of Image Sections}

All IRAF programs which operate upon images may be used to operate on
the entire image (the default) or any section of the image.
A special notation is used to specify \irafname{image sections}.  The section
notation is appended to the name of the image, much like an
array subscript is appended to an array name in a conventional programming
language. Note that array or image section \emphasize{index references} 
are integer only, but that the data may be of any valid type.

\begin{quote}
\begin{tabular}{ll}
{\it section}&   {\it refers to}\\
\\
pix&  whole image\\
pix[]&  whole image\\
pix[i,j]&       the pixel value (scalar) at [i,j]\\
pix[$*$,$*$]&       whole image, two dimensions\\
pix[$*$,-$*$]&      flip y-axis\\
pix[$*$,$*$,b]&     band B of three dimensional image\\
pix[$*$,$*$:s]&     subsample in y by S\\
pix[$*$,l]&       line L of image\\
pix[c,$*$]&       column C of image\\
pix[i1:i2,j1:j2]&       subraster of image\\
pix[i1:i2:sx,j1:j2:sy]& subraster with subsampling
\end{tabular}
\end{quote}

\noindent
In the following examples, please note that the references to image
sections are all enclosed in quotes.  These are \emphasize{required}
by the present language syntax.  As the note at the end of this
section indicates, this rule is to be relaxed in future.

A limited set of coordinate transformations may be specified using image
sections, but please observe that transpose is \emphasize{not} one of them.
The ``match all'' (asterisk), flip, subsample, index, and range notations
shown in the table may be combined in just about any way that makes sense.
As a simple example:

\begin{quotation}\noindent
\comptype{pl>} \usertype{graph 'pix[$*$,10]'}
\end{quotation}

\noindent
will graph line 10 of the image \usertype{pix}.
To generate a contour plot of an 800-pixel square image
subsampled by a factor of 16 in both dimensions:

\begin{quotation}\noindent
\comptype{pl>} \usertype{contour 'pix[$*$:16,$*$:16]'}
\end{quotation}

\noindent
To display the fifth $x-z$ plane of a three dimensional image named 
\usertype{cube}:

\begin{quotation}\noindent
\comptype{im>} \usertype{display 'cube[$*$,5,$*$]', 1}
\end{quotation}

\noindent
on frame 1 of the image display device.

\irafname{CL++} \\
The image processing sections of IRAF are undergoing further development,
as was noted in the previous section.  Currently only image data
can be processed as shown in the previous examples.  Future developments
will remove the need for quoting the section specifications that identify
the image portion to be operated upon.  The functional specifications
will not change substantially, nor will the syntax itself be changed
in any important way, but the need to remember to quote image section
references will be removed.  Image data will continue to be
stored on disk and passed among tasks by passing the \emphasize{name}
of the file rather than passing the data itself, as a matter of efficiency.

\subsection{Array Processing in the CL}

The processing of \emphasize{array} data is handled directly in the CL, 
and data arrays may also be passed to script tasks and external tasks.  The
entire array will be passed, since the CL cannot yet handle passing of 
sub-arrays to other tasks.  The operations on arrays are handled via
implicit looping over the array expressions, and only some of the
operations described in the previous section on image data are valid
for array data.  References to array data sections need not be quoted
however, and the syntax is otherwise identical to that supported for
images.

Given the declaration:

\begin{quotation}\noindent
\comptype{cl>} \usertype{real a[10], b[20], c[10,20], d[10,20,30], e[10,10]
}
\end{quotation}

\noindent
the following expressions are legal:

\begin{quotation}\noindent
\comptype{cl>} \usertype{c = 10} \hfill \#~sets~all~elements~of~c~to~10 \\
\comptype{cl>} \usertype{a = c[*,1]} \hfill \#~copies~row~1~of~c~into~a \\
\comptype{cl>} \usertype{= b} \hfill \#~prints~all~values~of~b \\
\comptype{cl>} \usertype{a = b[1:10] } \hfill \#~copies~subrange~of~b~into~a \\
\comptype{cl>} \usertype{c = d[*,*,1] }
\end{quotation}

\noindent
and the following expressions are illegal:


\begin{quotation}\noindent
\comptype{cl>} \usertype{a = c} \hfill \#~different~dimensionalities \\
\comptype{cl>} \usertype{a = c[1,*]} \hfill \#~different~limits~on~assign \\
\comptype{cl>} \usertype{a = b[11:20]} \hfill \#~different~limits  
\end{quotation}

In general, for an expression to be a legal array expression in the
CL, all array references must either be completely specified
(i.e. \usertype{d[1,2,3]}), or they must loop over the same set of indices
(i.e. \usertype{a = b[1:10]}).  Indices may be 
specified as just the identifier (\usertype{a} or with an
asterisk as the index (\usertype{b[*]}), indicating the entire array;
or as a subrange specified by  \emphasize{integer constants} separated
by a colon (\usertype{c[3:5]}).  

\irafname{CL++} \\
Future developments in the CL will eliminate most of the restrictions
on array operation in the CL and will bring the syntax for operations 
on images and arrays into complete alignment.

\subsection{Input and Output within the CL}

The CL provides I/O processing for parameters, cursor input and graphics
output, and controls communications to external tasks.  The communications
that appear at the terminal in the form of prompts for parameters, 
error messages, data range checking queries, and much of the other I/O
is performed in ASCII for portability considerations.  The data items that 
a user can input in response to a prompt may be:
integer values; floating point numbers, with or without exponent; 
yes/no responses for boolean data; or character strings as appropriate.

Image data and other bulk data forms that are processed by the various
functions are typically \emphasize{not} passed through
the CL itself, instead the names of the files are passed about, and
temporary files are dynamically created as needed to hold intermediate
results of computations.  Cursor input from graphics and image devices
are passed directly through the CL however, in order that they may be 
re-directed to a file like any other I/O stream.  The \irafname{imcur} and
\irafname{gcur} structs are used to handle this type of data.

As was mentioned in \S 2.4 and in the section on I/O and pipes (\S 3.3)
the CL communicates via its standard input and output,
which are ASCII streams normally connected to the terminal.  The
CL functions that manipulate these streams can also be used on
data in a file, just as the CL itself can be driven with commands 
from a file.  The control files are all ASCII
data streams, with no implied structure, and thus are easy to construct
and to edit, should that be necessary.

The \irafname{scan} and \irafname{fscan} functions are provided 
in the CL to process ASCII input streams; 
the only distinction between them is that \usertype{scan} operates
on the terminal input stream (or its re-directed source) and
\usertype{fscan} specifically operates on an file.  \usertype{Scan} reads
from the terminal (there is no prompt) and returns the first token it
finds in its input stream; where a token is understood to be any string
of alphanumeric characters delimited by a blank.  Quotes are ignored 
and no other punctuation has any special meaning.  If a \key{CTRL/Z}
is entered EOF is signalled and the following 
print statement will not be executed.

\begin{verbatim}
cl> if (scan (s1) != EOF)
>>>     print (s1)
>>> else
>>>     return
\end{verbatim}

The \usertype{print} command takes whatever is passed it as a parameter
and displays it on the terminal, so the previous example does a simple
one-line \emphasize{echo} function of input to output.  The argument to
\usertype{scan} in this example is the character variable \usertype{s1}, 
but it could as easily be an integer:

\begin{verbatim}
cl> while (scan (i) != EOF)
>>>     print ("Input was a ", i)
\end{verbatim}

\noindent
This in-line script will continue looping, reading from the input and
echoing to the output, until EOF is signalled.  All valid numeric inputs
will be accepted; real input values will be truncated to integers; 
character constants (single characters) will be processed as though
\usertype{int} had been called; and any invalid input values will
be silently ignored.  \usertype{Print} shows another of its features,
that string constants may be directly inserted into the output stream
and that \emphasize{no format} specifications need be made.

The I/O functions can be used to process more than one data element
at a time, with no need for explicit formatting.  If more data is
presented than there are identifiers in the list, the extra data
is silently ignored; and if there are more data elements in the 
parameter list than there is data, 
the remaining data elements retain their old values.

The output or input for these functions can be explicitly redirected,
via the usual mechanisms, or the \irafname{fscan} and \irafname{fprint}
functions can be used instead.  The commands:

\begin{verbatim}
cl> list = 'infile'
cl> while (fscan (list, s1) != EOF)
>>>     fprint ('junque', 'The next input line = ', s1)
\end{verbatim}

\noindent
perform exactly the same function as:

\begin{verbatim}
cl> list = 'infile'
cl> while (scan (s1, $<$list) != EOF)
>>>     print ('The next input line = ', s1, $>>$ 'junque')
\end{verbatim}

\noindent
where the list structured variable \usertype{list} has been set to the 
name of the file to be used for input (\filename{INFILE}) and the 
output is being directed to file \filename{JUNQUE}.  
These examples are hardly exhaustive, but 
will serve as background information for the discussion of list
structured parameters that follows.

\subsection{List Structured Parameters}

For certain data analysis tasks, the ability to define a \emphasize{list}
of data files for batch processing can be especially useful.  IRAF 
supports \irafname{list structured parameters} for specifying a list
of items to be input to a function.  Many, but not all, functions
will accept this form of input.  List structured parameters are
associated with a file and have their own peculiar, but useful,
semantics.

Suppose we want to make a series of contour plots on the standard plotter
device of a set of data files.  This can be done interactively by
entering a command to produce each plot, but this is tedious. A better 
approach would be to prepare a list of image sections (see \S 6.6) to 
be plotted, naming one section per line in a text file (which we choose 
to call \filename{SECTIONS}). The following command could then be used
to generate the plots in the background:

\begin{verbatim}
pl> list = 'sections'
pl> while (fscan (list, s1) != EOF)
>>>     contour (s1, device = 'stdplot') \&
\end{verbatim}

In this example, the assignment of \usertype{'sections'} to the 
parameter \usertype{list}
has two actions, it associates the name of the file \filename{SECTIONS}
with the list structured parameter, and it causes a \emphasize{logical}
open of the file.  The actual file open takes place the
first time that \usertype{fscan} is called.  Successive calls to 
\usertype{fscan} return successive lines from the file into the
string \usertype{s1}.  When the end of file (EOF) is encountered
the \usertype{while} loop terminates.  If additional calls are made to 
\usertype{fscan} EOF will continue to be returned.  A logical
reset to the top of the file can be performed by reassignment
of the same file name
to the parameter \usertype{list}, or another file name can be
associated with this parameter.

A user can declare other list structured data elements besides the
ones that are provided.  The statement:

\begin{verbatim}
cl> struct *input = uparm\$inlist
\end{verbatim}

\noindent
declares a list structured variable named input that is bound
to the list named \filename{UPARM\$INLIST}.  This file may
contain several records that define image section specifications
or the names of other files to be processed.  Once the declaration is
made, lines may be scanned from the file, as in previous examples, 
or the records may be fetched by use of a simple assignment operator:

\begin{quotation}\noindent
\comptype{cl>} \usertype{= input} \hfill \# displays the next record from
	file \\
\comptype{cl>} \usertype{s1 = input} \hfill \# sets s1 to the next record  
\end{quotation}

\noindent
Successive references to the identifier \usertype{input} will result
in successive records being read from the file it is bound to.  If
an EOF is detected it is silently ignored, and the last value
read will continue to be returned.  List-structured identifiers may be
integer, real, or character as well as struct type data.
The binding to a filename is the same regardless of type,
and the only difference is that data conversion is
performed on the input record to match the type of the identifier.

If you expect to write commands much more complicated than these
examples, it is time to learn about \irafname{script tasks}. This topic
is covered in \S 7 of this document and more detailed information
is given in the \reference{CL Programmer's Guide}.

\newpage
\section{Rolling Your Own}

The true power of the CL and the whole IRAF analysis 
environment lies in its ability to tailor analysis functions to the 
users' data.  This power comes from the ability to define new
functions in the CL, and from the capability to extend the
basic IRAF system by the addition of new analysis packages. 
These new routines can be developed incrementally, a line at a time,
and then defined as a new task once the function operates as desired.
User defined functions and analysis packages look just like any of the standard
functions that are provided with the system, and are called in the same way.
All of the same parameter passing, range checking, and prompting operations
of IRAF are available for user defined functions.  

Beyond the ability of the CL to \emphasize{learn} the value of parameters
that you have entered, or the creation of "one-liners",
little user customization has been presented so far. 
However, all of the programming and extensibility features of the CL
that have been used in the creation of the standard packages are also 
available to the intrepid user, enabling the creation of a personalized 
data analysis environment, one's own set of \taskname{doit} functions.  
This section introduces the creation of new user script tasks, 
user executable tasks, and packages of such tasks.

Examination of one of the \filename{.CL} script tasks that
defines a standard package will reveal that it
contains several \usertype{set} commands to establish 
logical directory names; and then defines the set of 
tasks that compose the package.  Examine the script task 
for the \irafname{system} package of functions:

\begin{quotation}\noindent
\comptype{cl>} \usertype{page system\$system.cl}
\end{quotation}

\noindent
to reveal the mysteries of these basic functions.  
The task names that appear 
in this package description contain a \irafname{logical directory}
portion (as in \usertype{system\$}) and a filename portion 
(\usertype{system.cl}).  The logical directory name is separated from 
the rest of the file name by a dollar sign \usertype{'\$'}, 
as was discussed in
the section on virtual file names (\S 4.3).  Use of a logical directory
specification in public packages, and even in those for your own private
use, is highly recommended, since it provides an unambiguous 
specification of where to find the package and tasks.

Note that tasks need not be defined as part of a package; individual tasks 
can be created and defined at any time, but a package is a convenient
way of grouping related tasks together. Many package have already been
provided in IRAF, and should be browsed by anyone who is searching
for clues about how the CL language can be used for programming.

\subsection{Creating Script Tasks}

All of the IRAF commands can be used within a
script task and will operate the same way in that environment as they
do when entered interactively.  A script task need be nothing more than
a text file that contains normal CL statements or commands.
Commands may be entered in a script just as they would from a terminal
in \irafname{command mode}, or \irafname{program mode} 
may be used, in which case slightly different rules apply (c.f. \S 6.0).  
For simple process control scripts command mode is likely
to be satisfactory, but program mode is the obvious choice if more
complicated tasks are undertaken.  The main distinction
is that task names must be entered in full and 
the standard rules should be followed for variable names and character 
string references.  Program mode will be used in the following
examples, since it is most likely to be used in any complicated
script tasks that you might wish to develop.

In order to create a script task one has merely to invoke the editor

\begin{quotation}\noindent
\comptype{cl>} \usertype{edit {\it taskname}.cl}
\end{quotation}

\noindent
and enter the CL statements that describe the actions you wish to
have performed.  When you have created the new script task 
(or modified an existing one), exit the editor in the normal way, 
so that the file is written in your current directory.  

A script task for demo purposes might look like:

\begin{quotation}\noindent
\usertype{ \{ } \\ 
\usertype{ print(' Hello, world !! ') } \\
\usertype{ \} } 
\end{quotation}

\noindent
In order to make this new task available to the CL, you will have to identify
it and indicate where the script task is to be found:

\begin{quotation}\noindent
\comptype{cl>} \usertype{task \$my\_new\_task = {\it taskname}.cl}
\end{quotation}

\noindent
Note that the name by which you refer to the new task
need not be the same as the name of the file, although the use of the same
name is conventional.
The `\usertype{\$}' in the \usertype{task} statement is optional and
tells IRAF not to search for a parameter (\filename{.PAR}) file for the task.

Once the task has been created and declared it may be directly invoked:

\begin{quotation}\noindent
\comptype{cl>} \usertype{my\_new\_task}
\end{quotation}

\noindent
will cause the script task file to be parsed and executed by the CL.
You may change the body of a script task
without redefining it with another \usertype{task} statement.

While tesing new script tasks, such
as this one, you may find it useful to turn on echoing:

\begin{quotation}\noindent
\comptype{cl>} \usertype{echo = yes}
\end{quotation}

\noindent
which will cause the CL to echo the commands on the terminal 
as they are read from the script.

Since all of the commands that you have entered at the terminal are 
logged a the history file, it is possible to edit all or part 
of this command log to create a new script task.  You will first have 
to output part of the history log to a file and then edit it:

\begin{quotation}\noindent
\comptype{cl>} \usertype{history 30, $>$ temp } \\
\comptype{cl>} \usertype{edit temp }
\end{quotation}

\noindent
which lets you change history (not a bad trick).  Once you have edited
the file, the commands needed to turn it into 
a CL script task are the same as those described above.

\subsection{Passing Parameters to Script Tasks}

Parameters are used to control the operation of tasks by defining input 
and output files, indicating execution options, etc. Script tasks that a user
defines may have parameters that operate in exactly the same fashion 
as standard tasks.  
In fact, the same prompting, learning, and limit checking mechanisms
that operate for standard tasks are available by default for user script tasks,
as well as for external user tasks (about which more in \S 7.5).

CL parameters and other variables that are defined external to a new 
script task may be referenced from within the task with no special action
being taken on your part. Global variables and variables passed 
from higher level tasks
are also accessible to a task. However, named parameters for the task, 
or variables that are local to the task (and thus protected from 
external actions), must be declared within the script task itself.
Parameters are identified by being defined
in the formal parameter list of the procedure or before the \usertype{begin}
statement, while local variables are declared only \emphasize{after}
the \usertype{begin} statement.  N.B. the \usertype{begin} and 
\usertype{end} statements must appear all by themselves on the line, 
and anything that appears \emphasize{after} the \usertype{end} will
be ignored.

The following simple script task description will serve to illustrate 
many of the salient points:

\begin{verbatim}

procedure doit (inparm, groups, region, outparm)

file    inparm {prompt = 'Input file name:'}
int     groups {prompt = 'Groups to process (0 for all):'}
int     region[] {0, mode=hidden}
file    outparm {prompt = 'Output file name:'}

begin
        file    cal_file = 'calib$wfpc'         # Wide Field Camera
        int     n_group, ngp

        n_group = groups                        # get the users group request
        if (n_group == 0)
            n_group = 9999

        for (ngp=1;  ngp <= n_groups;  ngp=ngp+1) {
            calib (inparm, ngp, cal_file) |     # note use of pipe
                clean() |
                clip (region= region, >> outparm)
        }
end 
\end{verbatim}

\noindent
The identifiers {\tt inparm, group, region,} and {\tt outparm} are 
parameters of the function and are used to pass data 
into and out of the procedure proper.
There is one \emphasize{required} parameter, {\tt inparm}, which is the input
file name that contains the name of
the file to be operated upon.  The other parameters are {\tt groups}
the number of data groups to be processed;
a \emphasize{hidden} parameter, {\tt region}, which will not be
prompted for; and the parameter, {\tt outparm}, which is
the name of the file that is to be written by the function.  The variable
{\tt cal\_file} is local to the procedure and is only
available within the procedure body (or to any lower level routines to which
variables may be passed as parameters).

There are some subtleties here that bear mentioning. Hidden parameters,
such as {\tt region}, may be defined for script tasks and must appear
\emphasize{before} the \usertype{begin} statement, but need \emphasize{not}
appear in the formal parameter list.   The {\tt groups} parameter will
be prompted for if not specified on the command line,
but is then assigned to a local variable {\tt n\_group}.
This is not required, but is desirable because of a side-effect of the
automatic prompting built into IRAF.  Any query mode parameter will be
prompted for automatically, \emphasize{each time it is referenced}.
This can be very useful in a script where a new value is to be input
on each execution of a loop, but can be surprising if one only intends
to enter the value once.  The obvious fix is to assign the value to
a local variable (at which time the prompt will occur) and then
operate only on the local variable.

As with the simple task described before, this procedure must be declared
with a \usertype{task} statement in order that the CL be able to locate it.

\begin{quotation}\noindent
\comptype{cl>} \usertype{task doit = home\$doit.cl}
\end{quotation}

\noindent
Remember to specify the logical 
directory in the declaration so that the task can unambiguously
be located no matter which directory you use it from.
When you run this new task, you will be expected to enter a value for
the input parameters (and you will be prompted if you don't).

 Remember that once you 
have used the \usertype{task} statement to inform the CL how to find your
new function, you need not do so again during that session, since the original
declaration of the task will allow it to be located even if you edit the body
of the task to change its internal operation.  
If you need to change the number or type of parameters to a task, 
or to change the name of a task, move it to another directory,
or if you wish to redefine the meaning of one of the standard tasks 
in the system, you will have to use the \usertype{redefine} command.

The following commands:

\begin{quotation}\noindent
\comptype{cl>} \usertype{rename home\$doit.cl funcs\$doit.cl} \\
\comptype{cl>} \usertype{redef doit=funcs\$doit.cl}
\end{quotation}

\noindent
rename the file \filename{HOME\$DOIT.CL} to \filename{FUNCS\$DOIT.CL}
and then redefines the \taskname{doit} task to point to the script.
This redefinition causes the CL to reprocess the script task 
in order to re-establish pointers to the file and to
redefine the data declarations.  

Once you have tested your new task and have it 
debugged, you may wish to enter a \usertype{task} definition for
it into your \filename{LOGIN.CL} file, or to install it in your own 
package of private functions.

\subsection{Using List Structured Parameters in a Script Task}

It is possible to define a CL script task such that a sequence of files
whose names are defined in an input list
may be processed in one call to the task.  This is convenient
when a number of files need to be processed in an identical way.  The
following example shows how the task \usertype{doit\_toit} has been
setup to accept a list structured input parameter, and then
to call another task, passing the files from the list one at a time
to the other task.  The obvious advantage is that the development
of the task that really does the work, viz. \usertype{doit}, can be done in 
isolation from the mechanics of batch processing the list of data files.

The \usertype{doit\_toit} function is set up for production use and, 
as such, it logs all activity in the standard logfile. 
It may be run as a background task, like any other IRAF function.

\begin{verbatim}
# DOIT_TOIT -- A driver task for batch operation of DOIT.

procedure doit_toit (images, section)

file    *images { prompt = 'List of images to be changed' }
char    section { prompt = 'Section of input images to be output' }

begin
        struct  imgs            # working storage for image file name
        bool    klog            # default size is 32 chars
        file    logf

        klog = keeplog          # get global keeplog flag
        logf = logfile          # ditto the log file name

        while (fscan (images, imgs) != EOF) {                           
            if (klog) {
                # Output a startup message if keeplog is true.
                print (' DOIT_TOIT: Process images ', >>logf)
                time (>> logfile)
                print ('    Images  : ', imgs, >>logf)
                print ('    Section : ', section, >>logf)
            }

            # Do the actual task by calling the DOIT function, passing
            # in the file name with the section concatenated.

            doit (imgs // section, imgs)

            if (klog) {     # output the trailing message
                time (>>logf)
                print (' DOIT_TOIT: Completed. ', >>logf)
            }
        }
end
\end{verbatim}

\noindent
The declaration for the variable \usertype{images} needs
some explanation.  The asterisk \usertype{'*'} indicates that 
\usertype{images} is a \irafname{list structured parameter}, i.e. that
it is to be processed as a pointer to a parameter list, rather than 
as the parameter itself.  In this instance it will contain the name
of a file that itself contains a list of the names of files to be
processed. 

As with the other script tasks that have been described, this one must 
be declared to the CL via a \usertype{task} statement before it can
be executed. Once this has been done the task can be called as follows:

\begin{quotation}\noindent
\comptype{cl>} \usertype{task doit\_toit = home\$doit\_toit.cl} \\
\comptype{cl>} \usertype{doit\_toit ( 'images.txt', '[]' )}
	 \hfill \#~no~sub-sections \\
\comptype{cl>} \usertype{tail logfile} \hfill \#~check~the~logfile~messages
\end{quotation}

\noindent
The name of the file containing the list of images \filename{``IMAGES.TXT''}
is passed directly into the task as a quoted string.  

\subsection{Establishing Your Own Function Package}

Once you have defined several functions that do a useful set of operations,
you may wish to set them up so that they are always available to you.
This can be done by defining them as a package, which is the mechanism 
that IRAF uses to organize the other groups of tasks that are made 
available as part of the system proper.  (Or, more easily, by putting
the \usertype{task} declarations into your \filename{LOGIN.CL} file.)

\newpage
\begin{verbatim}

package my_package

set 	funcs = "home$func/"           # define the logical directory

task    fib   = funcs$fibonacci.cl
        glib  = funcs$wordy.cl
        doit  = funcs$doit.cl

clbye()      # invoke the cl again for interactive use

\end{verbatim}

\noindent
If you now place the declaration for this package task in your
\filename{LOGIN.CL} file, these tasks will be available to you whenever
you login to IRAF.  It is a good practice to always use logical directory
names in task declarations and in other file names, since changing the
search path with a \usertype{chdir} may otherwise render tasks not
locatable.

Packages may, of course, be more complex than the above, since they can
refer to several logical tasks that may be CL script tasks or executable
tasks.  User packages may also reference logical tasks that are in other
packages directly, if only one or two such tasks from another package are 
needed.  Additionally, a package task may declare variables
that are to be treated as global to all of the tasks \emphasize{within} 
the package, but are to remain local to the package itself.  Other IRAF 
commands can be included in a package task as well, such as a load request
for a package of utility routines.  As you will recall, the
load operation for a package is implicitly executed whenever a package
is named; thus, a utility package such as \taskname{plot} or \taskname{imred}
can be loaded and made available just by naming it in the package description.

\subsection{Creating Fortran, SPP and other External Tasks}

While the IRAF and SDAS applications packages, along with the CL 
language, offer substantial facilities for interaction with and 
analysis of data, it would not be unusual for users  to wish to 
make their existing algorithms available
for use in IRAF.  Neither the IRAF packages nor the SDAS packages
can provide all of the functions that everyone might desire. IRAF has been
developed as an \emphasize{open system}, and is therefore extendible by the
user so that externally compiled programs are accessible with the CL.
These programs may be coded in any language that
conforms to the standard calling conventions, but Fortran, C, and the
Subset PreProcessor (SPP, the IRAF portable language) have predefined sets of
interface routines that establish access to the IRAF \irafname{kernel}
functions.

It is suggested that the Fortran programmer use the SDAS/ST
interface routines to access the IRAF environment.  These routines
provide access to parameters, perform I/O on image files as well as other data
file formats, provide facilities for header data manipulation, etc.
The routines are described in the \reference{SDAS Applications Programmer's
Guide} (the \reference{Green Book}) and in the \reference{Software
Interface Definition, ST-ECF O-11}, which describes the set of
interfaces that have been agreed upon between the STScI and the
European Coordinating Facility (ECF).

The SDAS interface routines (and the ST-ECF interfaces) are all 
built upon the existing IRAF kernel interfaces as described in the 
\reference{IRAF Programmer's Crib Sheet}. These interfaces are rather
more complete than the SDAS/ST ones, providing full access to the facilities
of the IRAF virtual operating system. These routines can be called directly
from SPP, but typically \emphasize{cannot} be called directly from
Fortran programs.

A selection of software development tools are available to the user who wishes
to integrate personal programs into the IRAF environment. These utilities
are provided as parts of the \taskname{softools} package, and include such
functions as IRAF-specialized compilation and linkage, help file creation, etc.

A simple SPP language routine is included here as an example that
can be tried from the terminal.  It is not a particularly useful
function (it just feeps the terminal bell), but does show the
ease with which an external task can be linked into the environment.

\begin{verbatim}
#------------------------------------------------------------
# Simple task to show use of SPP external procs
#	Compile and link using SPP command in Softools

task feep = t_feep
include	<chars.h>            # include the standard char defs

# FEEP -- Feep the terminal.

procedure t_feep()
begin
        call putc (STDOUT, BEL)
end
\end{verbatim}

\noindent
After you have used the editor to create the program source file,
you should load the \irafname{softools} package that contains
the \irafname{xc} compile/link tool.  This will compile the
program, link it, and create an executable named \filename{FEEP.E}.

\begin{quotation}\noindent
\comptype{cl>} \usertype{softool} \\
\comptype{so>} \usertype{xc feep.x}
\end{quotation}

Once the \usertype{feep} task has been compiled and linked
it may be made available from within the IRAF environment
in a fashion analogous to that used for CL script tasks.
A \usertype{task} statement that names the executable file and binds it
to a task name must be used to declare the task to the CL.  Once this
has been done, the executable task can be invoked just like any other
task. 

\begin{quotation}\noindent
\comptype{cl>} \usertype{task feep = feep.e } \\
\comptype{cl>} \usertype{feep} \hfill \#~is~used~to~call~it
\end{quotation}

\noindent
N.B. IRAF tasks written in SPP (and other languages) 
may contain more than one logical task, and the CL 
\usertype{task} statement must be used to declare each of them.
The logical task names used on the CL \usertype{task} statement
\emphasize{must} correspond with the task names from  the {\tt task}
statement used in the body of the SPP file.

The parameter handling facilities at the user level behave 
identically for executable 
external tasks and for CL script tasks.  If the complete facilities
of parameter range checking, prompt messages, and default values
are desired, a data declaration statement that defines
these values will have to be  specified.  If a declaration statement 
is not provided, the standard prompt processing (naming the
parameter and soliciting input) will be used when parameters are
referenced.

The details of parameter and file I/O in SPP, and in the Fortran and
C interfaces, are sufficiently different from those presented for the 
CL that the entire subject is best deferred to a separate document.  
It is important to note however, that the facilities that are available
in the CL and in the IRAF kernel routines that support it are
equally available to all executable modules.  The implication of
this is that any program that has been linked into IRAF will have the
same apparent interface as all of the existing programs, and thus
can easily be made to appear as a unified part of the larger system.
This can, of course, be subverted, and programs may maintain their
own identities in so far as that is desirable.  However, the advantages
of a unified user interface and of a well defined and completely
implemented set of flexible interface routines cannot be stressed enough.

\newpage
\section{Relevant Documentation (the Yellow Pages)}

This document should serve to get the first-time user started (and if it
doesn't, we would like to know about it), but there are many topics 
that have been covered quickly or not at all.  Other documents and
sources of information about IRAF, SDAS, standard packages, use of
SPP, IRAF internals, etc. exist and this section will provide pointers
into that realm for those who would like more information on these topics.

\subsection{IRAF Command Language}

Some of the documents describing the CL are now somewhat out of date
since there have been at least two revisions to IRAF since they were
written.  However, these documents are readable and are still
useful, since, by design, most of the changes made to the CL are 
compatible with what had gone before.

\noindent
\reference{CL Programmer's Guide, in preparation}

This is to be the most complete introduction to programming in the
CL and to the facilities of the CL.  As such, it provides details of language
use (especially helpful when developing external and/or script tasks in
Fortran, SPP, and C).  Also included are descriptions of the workings of 
the CL, the IRAF kernel and inter-process communications as they affect 
the use of IRAF for program development.

\noindent
\reference{Detailed Specifications of the IRAF Command Language, rev Jun82}

This paper discusses in technical detail the major functions of the CL
and some details about how it works.  Since this is a specifications
document, it is not as readable as a user document, but it
does cover many of the same areas as the \reference{CL Programmer's Guide}
in somewhat more detail.

\subsection{IRAF Applications Packages}

Much of the richness of the IRAF environment comes from the packages
of applications programs that are being made available within the 
environment. The IRAF group at NOAO and the SDAS group at STScI have been
developing analysis programs that are available as packages
within the IRAF environment, and the end-user-oriented documentation of
these systems is described below.

\noindent
\reference{IRAF Applications Packages, Structure and Requirements, Aug83}

This document is an attempt to define fully the decomposition of the IRAF
system and applications software into packages. The functions performed by
each package are summarized in the form of requirements.

Descriptions of specific IRAF applications packages developed at Kitt Peak
are available in a set of user-handbooks :

\begin{itemize}
\item \reference{APPHOT - Digital Aperture Photometry, Aug83}
\item \reference{GRAPH - Simple Graphics Routine, Mar84}
\item \reference{SURFACE - 3-D Surface Display, Mar84}
\item \reference{CONTOUR - Contour Map Display, Mar84} 
\item \reference{HELP - On-Line HELP for IRAF, Mar84}
\item \reference{DATAIO - Data Readers and Writers, Mar84}
\item \reference{LISTS - Basic List Processing Functions (ASCII files), Mar84}
\item \reference{UTILITIES - Miscellaneous Utility Functions, Mar84} 
\item \reference{SOFTOOLS - Software Utilities, make, yacc, xc, mklib, Mar84}
\end{itemize}

\noindent
\reference{Science Data Analysis Software Requirements, Final, Aug82}

These are the contract requirements of the SDAS system.

\noindent
\reference{SDAS User's Manual, in preparation}

A descriptive guide to the use of SDAS.

\subsection{Standard Program Interfaces}

There are three sets of interface routines available to the programmer:
those for SPP, those for C, and those for Fortran. The language that
you use depends on the nature of the project being undertaken, your 
own level of expertise, and on the
need for creating portable code.  SPP is the language of choice for packages
that are to become part of IRAF or for tasks that require access to the
entire virtual system interface.  Fortran and the SDAS/ST
interfaces will remain the choice for existing Fortran codes and for many
small scientific applications programs.  Users are encouraged to choose 
the SDAS/ST interface for their Fortran programs.  C has been used
for the innards of the CL itself, and a set of interfaces (the LIBC library)
is provided that emulates the UNIX standard I/O facilities and 
gives access to the IRAF kernel facilities.

\noindent
\reference{A Reference Manual for the IRAF System Interface, rev May84}

This document is the most complete (and recent) treatment of the
linkages between the portable IRAF kernel, the CL, the external procedures
and the system dependent Z-routine layer.  It describes these interfaces
in detail and has the complete specifications of the
Z-routine interfaces. It is of particular use to both the individual who is
trying to port IRAF to another system (it is a \emphasize{must read} for such
persons) and to the system or applications
programmer who wants a more detailed understanding of IRAF.

\subsubsection{SPP Interfaces}

\noindent
\reference{Programmer's Crib Sheet for the IRAF Program Interface, rev Sep83}

This document describes the complete set of interface functions
for the IRAF virtual 
operating system as it is available to the SPP programmer.  Several
sets of library functions are described for accessing images and various
kinds of data files, terminal capabilities, graphics and image I/O, etc.
Programs written using only these interfaces
will be fully portable, along with the main body of IRAF code.

\noindent
\reference{Reference Manual for the IRAF SPP, rev Sep83}

This is the definitive document about the IRAF Subset Preprocessor
language.  The language is somewhat like Ratfor (from which
it derives), but it has extensions for dealing with the memory management
and referencing issues that arise when operating on large scale image data.

\noindent
\reference{The Role of the Preprocessor, rev Dec81}

This document is an early discussion of the philosophy behind use of
the SPP language.  As such, it is valuable
background reading for anyone who wishes to understand fully the
benefits of using a preprocessed language for 
implementing a large body of portable
code like IRAF.

\subsubsection{Fortran Interfaces}

\noindent
\reference{SDAS Applications Programmer's Guide}

This is the complete description of the interface set that is now 
being used to develop the SDAS program suite at STScI.  These interfaces
are expected to be replaced eventually by the set of SDAS/ST 
interfaces mentioned in the following document.

\noindent
\reference{Software Interface Definition, ST-ECF O-11, rev Aug84}

This describes the set of standard interfaces agreed upon between 
the STScI and the ST-ECF.  It incorporates most of the features of the
SDAS standard interfaces and is to be used for program development 
at STScI and for future MIDAS programs developed at ESO.  It is
a rather complete interface for image data, process parameters,
and table data structures, but does leave out many of the other 
facilities provided in the complete IRAF SPP interface.

\newpage
\section{And into the Future}

This version of IRAF and its CL represents the first external release
of a system that has been under development for more than three years,
and which will continue to evolve for several
more.  IRAF was born out of the need for a system that
could survive changes in operating systems and hardware, since such
changes are a normal part of computer system evolution.  To 
accomodate such changes, and to provide a level of stability 
and portability across operating systems,
IRAF is a \emphasize{layered} system: the CL is the user layer;
the kernel is the operating system independent layer; and the
z-routines are the system dependent layer.  

Most of the discussion in this document describes the appearance 
and function of the current command language (CL2), the user layer 
of IRAF.  As has been noted at various points in the text, 
the CL is still undergoing
development and is expected to change over time.  (The paragraphs
marked \irafname{CL++} in the text hold the clues.)  The intent
in these changes is two-fold:

\begin{itemize}

\item Provide evolutionary enhancements to the user interface
to improve utility, functionality, usability and coherence.

\item Bring the programming elements of the CL language
into line with the SPP language which is used for the bulk of the
IRAF portable code.

\end{itemize}

\noindent
These requirements are somewhat at odds, as was noted in \S 6, but
further attention is being given these issues to try and resolve 
the dilemma.  Although not all elements of the CL language can
be mapped easily into the SPP programming language (consider the I/O
control commands), the notion that one
can do development in an interactive environment and then
realize compiled code speeds for execution is an attractive one.
The CL2 implementation has
taken steps in this direction and we expect to see how far this idea
can be taken over the next few years.

\subsection{Near-Term Software Projects}

While the evolution of the CL is an important part of IRAF, there
are other elements of the system that are even more important which are
still under development at this time.  The most important single area
for development is the database and data catalogue.
Design and prototyping of these important functions, and the
necessary query language, is in progress
right now.  These functions are doubly important, since they both represent 
a user facility for creating and operating on private catalogues 
of data; and also are at the heart of the effort to merge the
SDAS functions cleanly into the IRAF control structure.  Only after
the DBIO and IMIO packages have been fully implemented and integrated
into the rest of the system will functions from these two large
applications groups be able to share data and file structures.  
A tables system is also envisioned that will offer similar capabilities
to the MIDAS tables, but will be built upon the DBIO routines.  

The areas of graphics and image display will also receive
attention during the next year.  The current GIO package
supports a fast kernel and both a GKS and an NCAR emulation.  
However, image data are not merged into this structure 
and no common meta-file
formats exist that allow image, annotation, and overlay graphics
to be represented in one consistent form.  Some efforts have already
been made toward understanding what needs to be done and how (or if)
the requirements can be satisfied within existing standards.
Further efforts will be made, both at NOAO and STScI, and at
other facilities like RAL who have expertise in this area, to develop
an approach that satisfies the requirements.

Developments in the area of networks, both LAN and wide-area; workstations;
and the related topics of access to distributed data bases and archives
are also receiving attention.  We believe that IRAF
has a sufficiently robust and flexible structure that it can operate
successfully within a distributed operating environment.  Small scale 
efforts are now underway to explore some of the issues related to network
file systems.  

At the same time, a prototype project is underway with a
single platter laser disk, to evaluate the suitability of this media 
for large scale, long term archival storage of images and other related 
data.   As a part of this activity, IRAF is currently
being ported to a SUN workstation and high resolution image display 
at the STScI.  IRAF and its database package will be important 
to this effort, since they will provide some of the basic facilities 
for processing the data and managing the catalogues for this archive. 

These are all components of a distributed data system, a long range goal
for the Space Telescope community, and probably of interest to the entire 
astronomy and astrophysics community.  To the extent that IRAF proves
useful to astronomers, it will play a key role in such a data system.

\subsection{Where Is the Future?}

The usual rapid pace of developments in hardware and software systems 
will also prompt consideration of changes to the external appearance
and some of the internal implementation details of IRAF.
Developments in graphics and image displays, and in various data
input and storage
devices promise to make revolutionary changes in the way that
people and computers interact. High resolution graphics, touch screens,
mice, WYSIWYG (What You See Is What You Get), DWIM (Do What I Mean),
and the 'cluttered desk' paradigm pioneered by Xerox PARC and emulated
by everyone else, will all appear in one form or another in a variety
of different systems in the next few years.  These presentation
techniques and differing interactive views of data,
when well thought out and integrated into a system,
can serve to make computers more accessible to people.  
These ideas, however, have been much slower to arrive in the 
large-scale systems that have been used for data analysis than in
the super-micro and PC class machines. 

IRAF, in its current version, incorporates only some of these elements,
but many others will be experimented with as it is ported to
different hardware environments.  
Because the CL is a separable piece of the system, 
it can be changed or replaced, without necessarily making major changes
to the underlying system structure.  Efforts now underway to move
IRAF out of the super-mini systems where it has been developed, and
into super-micro workstations will afford the opportunity to
explore some of these user interface issues in a prototyping 
mode.  Depending on the results of such experiments,
other CL interfaces that take advantage of those
elements that prove successful are likely to evolve.  

These statements should not be
construed to mean that constant change will be the norm.  IRAF
was designed to protect the substantial software investment that any 
large data analysis system represents, and this it will do, both for
the developers and for the users.  The IRAF kernel and the layered
interfaces for applications programs are quite stable, and are not
expected to change, except to incorporate additional functionality.
Furthermore, any changes proposed for
the user interface will be carefully evaluated in terms of their
impact on the existing user community.  But, just as we expect that
faster, more efficient FFT or filtering algorithms would receive
a welcome reception we expect that a stable, but slowly evolving system 
that continues to serve
users needs will meet with approval.  Feedback and commentary from the
users of the system will be vitally important in this development
process, and we encourage that dialogue.

\newpage
\appendix
\section{Appendices}

\subsection{CL Commands and the System Package}

\subsubsection{CL Intrinsic and Builtin Functions}

\begin{tabular}{rcl}

	 access & - & Test to see if a file exists \\
	    bye & - & Exit a task or package \\
          cache & - & Cache parameter files, OR \\
                  & & Print the current cache list (no arguments)\\
	     cd & - & Change directory \\
	  chdir & - & Change directory \\
	     cl & - & Execute commands from the standard input \\
	  clbye & - & Exit a task or package to save file descriptors \\
	 defpac & - & Test to see if a package is defined \\
	 defpar & - & Test to see if a parameter is defined \\
        deftask & - & Test to see if a task is defined \\
       ehistory & - & Edit commands from the history log file \\
	 envget & - & Get the string value of an environment variable \\
         eparam & - & Edit the parameters for a function \\
	  error & - & Print error code and message and abort \\
      flprcache & - & Flush the process cache \\
	 fprint & - & Format and print a line into a parameter \\
	  fscan & - & Scan and format an input list \\
       hidetask & - & Define a new hidden task \\
        history & - & Print the last few commands entered \\
	   jobs & - & Show status of background jobs \\
	   keep & - & Make recent set, task, etc. declarations permanent \\
	   kill & - & Kill a background job or detached task \\
	 logout & - & Log out of the CL \\
	 lparam & - & List the parameters of a task \\
	 mktemp & - & Make a temporary (unique) file name \\
	  mkdir & - & Make a new file sub-directory \\
        package & - & Define a new package, OR\\
                  & & Print the current package names (no arguments) \\
	  print & - & Format and print a line on the standard output \\
	  radix & - & Print a number in the given radix \\
       redefine & - & Redefine a task \\
	   scan & - & Scan and format the standard input \\
        service & - & Service a query from a background job \\
	    set & - & Set an environment variable, OR \\
                  & & Print environment (no arguments) \\
	   show & - & Show the values of one or more environment variables \\
	  sleep & - & Pause execution for  specified period \\
	 substr & - & Extract a substring from a string \\
	   task & - & Define a new task \\
        unlearn & - & Restore the default parameters for a task or package \\
	 update & - & Update a task's parameters (flush to disk) \\
        version & - & Print the revision date of the CL \\
	   wait & - & Wait for all background jobs to complete
\end{tabular}

\subsubsection{System Package Functions}

\begin{tabular}{rcl}

       allocate & - & Allocate a device \\
	   beep & - & Beep the terminal \\
	  clear & - & Clear the terminal screen \\
    concatenate & - & Concatenate a list of files to the standard output \\
	   copy & - & Copy a file, or copy a list of files to a directory \\
	  count & - & Count the number of lines, words, and characters in a file \\
     deallocate & - & Deallocate a previously allocated device \\
         delete & - & Delete a file \\
      devstatus & - & Print the status of a device \\
      directory & - & List files in a directory \\
      diskspace & - & Show how much diskspace is available \\
	   edit & - & Edit a file \\
	  files & - & Expand a file template into a list of files \\
         gripes & - & Post bug reports, complaints, suggestions \\
	   head & - & Print the first few lines of a file \\
           help & - & Print online documentation \\
         lprint & - & Print a file on the line printer device \\
	  match & - & Print all lines in a file that match a pattern \\
	   news & - & Page through the system news file \\
	   page & - & Page through a file \\
      pathnames & - & Expand a file template into a list of OS pathnames \\
        protect & - & Protect a file from deletion \\
         rename & - & Rename a file \\
      revisions & - & Print/post a revision notice for a package \\
         rewind & - & Rewind a device \\
	   sort & - & Sort a text file \\
	    spy & - & Show processor status \\
	   stty & - & Show/set terminal characteristics \\
	   tail & - & Print the last few lines of a file \\
	    tee & - & Tee the standard output into a file \\
	   time & - & Print the current time and date \\
	   type & - & Type a file on the standard output \\
      unprotect & - & Remove delete protection from a file
\end{tabular}
\clearpage

\subsection{SDAS Analysis Packages}

\begin{itemize}

\item General Data Analysis \\

\begin{tabular}{rcl}
   areavolum & - & Integrate to find the area/volume under a curve/surface\\
   arrayops & - & Perform arithmetic, logical, and matrix operations on\\
                  & &  \quad SDAS data arrays\\
   convert & - & Convert data from one type to another (real, integer,\\
                   & &  \quad logical, byte)\\
   curfit & - & Fit curve to one-dimensional data\\
   dimage & - & General image display package\\
   extract & - & Extract a subset of a data array\\
   fitsrd & - & Read a standard FITS tape and create an SDAS disk data file\\
   fitswr & - & Write a standard FITS tape from an SDAS disk data file\\
   four1d & - & Perform one-dimensional Fourier analysis\\
   four2d & - & Perform two-dimensional Fourier analysis\\
   hstats & - & Compute standard statistics, including histograms\\
   locate & - & Locate features in a spectrum, time series, or image\\
   makemask & - & Make a data mask\\
   plot1d & - & Plot one-dimensional (equally-spaced) data\\
   plot2d & - & Plot two-dimensional (equally-spaced) data as contour\\
                    & &  \quad map or ruled-surface map\\
   probdist & - & Compute standard probability distributions\\
   register & - & Compute registration parameters for two displaced data\\
                     & &  \quad arrays (use in conjunction with resample)\\
   repmod & - & Replace/modify/input data in an existing data array\\
   resample & - & Resample data from one grid to another (shift, rescale, rotate)\\
   smooth & - & Smooth data by convolution filtering, median window
\end{tabular}

\item Spectral Analysis \\

\begin{tabular}{rcl}
   cntana & - & Continuum analysis (determine reddening, correct for\\
                     & &  \quad reddening, fit continuum models)\\
   ewlnst & - & Measure equivalent width/line strength\\
   gspect & - & Generate a spectrum for testing\\
   rvdet & - & Measure radial velocities\\
   specph & - & Spectrophotometry
\end{tabular}

\item Image Analysis \\

\begin{tabular}{rcl}
   gimage & - & Generate an image for testing\\
\end{tabular}

\clearpage
\item Time Series Analysis \\

\begin{tabular}{rcl}
   glcurv & - & Generate a light curve for testing\\
   hldelc$^*$ & - & Correct HSP times for light delay time\\
   hspcir$^*$ & - & Correct HSP data for instrumental response\\
   hspolar$^*$ & - & Polarimetry package for HSP data\\
   hspphot$^*$ & - & Photometry package for HSP data\\
   hsubbkg$^*$ & - & Subtract background from HSP data
\end{tabular}

\item Astrometric Analysis \\

\begin{tabular}{rcl}
   bdresid$^*$ & - & Make histogram of FGS beam deflector residuals\\
   centroid$^*$ & - & Centroid raw FGS encoder data\\
   errsig$^*$ & - & Make histogram of FGS error signals
\end{tabular}

\end{itemize}

\vskip 2cm \noindent
$*$ --- these programs may not be available
\clearpage

\subsection{IRAF Application Packages}

\begin{itemize}

\item CRYOMAP Package \\

\begin{tabular}{rcl}

        extract & - & Extract Cryomap spectra\\
    findspectra & - & Find Cryomap spectra\\
           iids & - & Convert integrated spectra extractions to IIDS format\\
        maplist & - & List information about the multi-aperture plate\\
       specplot & - & Plot extracted integrated spectra

\end{tabular}

\item DATAIO Package \\

\begin{tabular}{rcl}

	 bintxt & - & Convert a binary file to an IRAF text file\\
	 ldumpf & - & List the permanent files on a Cyber DUMPF tape\\
      mtexamine & - & Examine the structure of a magnetic tape\\
        rcamera & - & Convert a Forth/Camera image into an IRAF image\\
     rcardimage & - & Convert a cardimage file into a text file\\
	 rdumpf & - & Convert IPPS rasters from a DUMPF tape to IRAF images\\
        reblock & - & Copy a binary file, optionally reblocking\\
          rfits & - & Convert a FITS image into an IRAF image\\
       ridsfile & - & Convert IDSFILES from a DUMPF tape to IRAF images\\
	ridsmtn & - & Convert mountain format IDS/IRS data to IRAF images\\
        ridsout & - & Convert a text file in IDSOUT format to IRAF images\\
           rpds & - & Convert a PDS image into an IRAF image\\
	 rrcopy & - & Convert IPPS rasters from an RCOPY tape to IRAF images\\
	 txtbin & - & Convert an IRAF text file to a binary file\\
     wcardimage & - & Convert text files to cardimage files\\
	  wfits & - & Convert an IRAF image into a FITS image\\
	widsout & - & Convert an IRAF image to IDSOUT text format
\end{tabular}

\item ECHELLE Package \\

\begin{tabular}{rcl}

     background & - & Subtract a scattered light background\\
	extract & - & Extract Echelle orders\\
     findorders & - & Find Echelle orders\\
           iids & - & Convert integrated spectra extractions to IIDS format\\
      orderplot & - & Plot extracted integrated spectra

\end{tabular}
\clearpage

\item GENERIC Package \\

\begin{tabular}{rcl}

	biassub & - & Subtract a bias image\\
       chimages & - & Change images: trim, flip, transpose, rotate\\
     colbckgrnd & - & Fit and subtract a column by column background\\
	colflat & - & Create a flat field by fitting a function \\
		&&	to the image columns\\
	darksub & - & Scale and subtract a dark count image\\
	 dcbias & - & Subtract a constant bias and trim images\\
        flatten & - & Flatten images using a flat field\\
    linebckgrnd & - & Fit and subtract a line by line background\\
       lineflat & - & Create a flat field by fitting a function \\
		&&	to the image lines\\
      normalize & - & Normalize images\\
       normflat & - & Create a flat field by normalizing and \\
		&&	replacing low values

\end{tabular}

\item IMAGES Package \\

\begin{tabular}{rcl}

        imarith & - & Simple image arithmetic\\
      imaverage & - & Average images together\\
	 imcopy & - & Copy an image\\
       imdelete & - & Delete an image\\
      imlinefit & - & Fit a function to each image line\\
       imheader & - & Print an image header\\
    imhistogram & - & Compute image histogram\\
   imstatistics & - & Compute and print image statistics\\
    imtranspose & - & Transpose a two dimensional image\\
     listpixels & - & Convert an image section into a list of pixels\\
       sections & - & Expand an image template on the standard output\\
     shiftlines & - & Shift image lines\\
             tv & - & Image display (see TV-IMAGE Package)

\end{tabular}

\item LISTS Package \\

\begin{tabular}{rcl}

	average & - & Compute the mean and standard deviation of a list\\
	gcursor & - & Read the graphics cursor\\
       imcursor & - & Read the image display cursor\\
	  table & - & Format a list of words into a table\\
	 tokens & - & Break a file up into a stream of tokens\\
	 unique & - & Delete redundant elements from a list\\
	  words & - & Break a file up into a stream of words

\end{tabular}

\clearpage
\item LOCAL Package \\

\begin{tabular}{rcl}

       binpairs & - & Bin pairs of (x,y) points in log separation\\
	   epix & - & Edit pixels in an image\\
	 fields & - & Extract specified fields from a list\\
      imreplace & - & Replace pixels in a range by a constant\\
	imscale & - & Scale an image to a specified (windowed) mean\\
	imstack & - & Stack images into an image of higher dimension\\
       imsurfit	& - & Fit a surface to an image\\
	imtitle & - & Change the title of an image\\
	  notes & - & Record notes\\
        polyfit & - & Fit polynomial to lists of X,Y pairs

\end{tabular}

\item MULTISPEC Package \\

\begin{tabular}{rcl}

      findpeaks & - & Find the peaks\\
    fitfunction & - & Fit a function to the spectra parameter values\\
      fitgauss5 & - & Fit spectra profiles with five parameter \\
		&&	Gaussian model\\
      modellist & - & List data and model pixel values\\
      msextract & - & Extract spectra\\
         mslist & - & List entries in a MULTISPEC database\\
         msplot & - & Plot a line of image and model data\\
          msset & - & Set entries in a MULTISPEC database\\
  newextraction & - & Create a new MULTISPEC extraction database\\
       newimage & - & Create a new multi-spectra image

\end{tabular}

\item PLOT Package \\

\begin{tabular}{rcl}

	contour & - & Make a contour plot of an image\\
	  graph & - & Graph one or more image sections or lists\\
	   pcol & - & Plot a column of an image\\
	  pcols & - & Plot the average of a range of image columns\\
	   prow & - & Plot a line (row) of an image\\
	  prows & - & Plot the average of a range of image lines\\
	surface & - & Make a surface plot of an image
\end{tabular}

\clearpage
\item SOFTOOLS Package \\

\begin{tabular}{rcl}

     hdbexamine & - & Examine a help database\\
	  lroff & - & Lroff (line-roff) text formatter\\
	   make & - & Table driven utility for maintaining programs\\
       mkhelpdb & - & Make (compile) a help database\\
	  mklib & - & Make or update an object library\\
      mkmanpage & - & Make a manual page\\
       xcompile & - & Compile and/or link an SPP, C or Fortran program\\
	   yacc & - & Build an SPP language parser

\end{tabular}

\item TV-IMAGE Package \\

\begin{tabular}{rcl}

      blink 	& - & Blink the TV display\\
      display	& - & Manipulate the TV display\\
      erase	& - & Erase the TV display\\
      frame	& - & Define the frames to be manipulated\\
      lumatch	& - & Match color look up tables\\
      monochrome& - & Set display into monochrome mode\\
      pseudocolor& - & Set pseudocolor mode on display\\
      rgb	& - & Set true RGB mode on display\\
      window	& - & Define a display window area\\
      zoom	& - & Zoom the display

\end{tabular}

\item UTILITIES Package \\

\begin{tabular}{rcl}

	airmass & - & Compute the airmass at a given elevation \\
		&&	above the horizon\\
	ccdtime	& - & Compute time required to a observe star \\
		&&	of given magnitude\\
	  detab	& - & Replace tabs with tabs and blanks\\
	  entab & - & Replace blanks with tabs and blanks\\
	  lcase & - & Convert a file to lower case\\
	precess & - & Precess a list of astronomical coordinates\\
       translit & - & Replace or delete specified characters in a file\\
	  ucase & - & Convert a file to upper case\\
	  urand & - & Uniform random number generator
\end{tabular}

\end{itemize}
\clearpage

\subsection{IRAF Editor Functions}

\begin{tabular}{llll}

Command & Emacs  & EDT$^{\dag}$ & Vi$^{\ddag}$ \\
\\
move-up & \key{$\uparrow$} or \key{CTRL/P} & \key{$\uparrow$} 
	& \key{j} or \key{CTRL/P} \\
move-down & \key{$\downarrow$} or \key{CTRL/N} & \key{$\downarrow$} 
	& \key{k} or \key{CTRL/N} \\
move-right & \key{$\rightarrow$} or \key{CTRL/F} & \key{$\rightarrow$} 
	& \key{l} or \key{$\rightarrow$} \\
move-left & \key{$\leftarrow$} or \key{CTRL/B} & \key{$\leftarrow$} 
	& \key{h} or \key{$\leftarrow$} \\
\\
ins-chr/word & {\it text} & {\it text} & i/a-{\it text}\ \key{ESC} \\
del-left & \key{CTRL/H} or \key{DEL} \hspace{1cm} & \key{DEL} & \key{DEL} \\
del-char & \key{CTRL/D} & \key{,} & \key{x} \\
del-word & \key{ESC}\ \key{d} & \key{-} & \key{d}\ \key{w} \\
del-line & \key{CTRL/K} & \key{PF4} & \key{d}  \key{d} \\
undel-char & \key{ESC}\ \key{CTRL/D} & \key{GOLD}\ \key{,} & \key{u} \\
undel-word & \key{ESC}\ \key{CTRL/W} & \key{GOLD}\ \key{-} & \key{u} \\
undel-line & \key{ESC}\ \key{CTRL/K} & \key{GOLD}\ \key{PF4} & \key{u} \\
\\
set-fwd & & \key{4} & \\
set-rev & & \key{5} & \\
next-word & \key{ESC}\ \key{f} & \key{1} & \key{w} \\
prev-word & \key{ESC}\ \key{b} & \key{5}\ \key{1} & \key{b} \\
move-eol & \key{CTRL/E}  & \key{2} & \key{\$} \\
move-bol & \key{CTRL/A}  & \key{BS} or \key{CTRL/H} \hspace{1cm} 
	& \key{.} \\
next-page & \key{CTRL/V}  & \key{7} & \key{CTRL/D} or \key{CTRL/F} \\
prev-page & \key{ESC}\ \key{V} & \key{5}\ \key{7} 
	& \key{CTRL/U} or \key{CTRL/B} \\
move-start & \key{ESC}\ \key{$<$} & \key{GOLD}\ \key{5} & \key{1}\ \key{G} \\
move-end & \key{ESC}\ \key{$>$} & \key{GOLD}\ \key{4} & \key{G} \\
\\
get-help & \key{ESC}\ \key{?} & \key{PF2} & \key{PF2} or \key{ESC}\ \key{?} \\
repaint & \key{CTRL/L} & \key{CTRL/R} & \key{CTRL/L}\\
exit-update & \key{CTRL/Z} & \key{CTRL/Z} 
	& \key{:}\ \key{w}\ \key{q} \\
exit-no update \hspace{1cm} & \key{CTRL/C} & \key{CTRL/C} 
	& \key{:}\ \key{q}\ \key{!} \\

\end{tabular}

\hrule width5cm \vskip .15cm \noindent
\dag{} --- EDT employs the notion of ``direction'' (forward and backward
cursor motion). Several command sequences are preceded by \key{5} to indicate
explicitly that they only function after setting ``backward'' mode.  All EDT
keystrokes, with the exception of \key{CTRL} keys, use the keypad.

\medskip \noindent
\ddag{} --- Vi has \emphasize{insert/replace/change modes},
which are entered by command and terminated by the \key{ESC} key.
Vi-type keystrokes for \usertype{eparam} and \usertype{ehist} are not
yet implemented.

\twocolumn \columnsep 1cm
\section{Glossary}

\medskip \noindent \irafname{AAS} --- American Astronomical Society.

\medskip \noindent \irafname{band} --- A two dimensional array. The Nth band
of a three dimensional array or \irafname{image} is denoted by the subscript
[$*$,$*$,N], where $*$ refers to all the pixels in that dimension.

\medskip \noindent \irafname{binary file} --- An array or sequence of
data words.  Data is transferred between a binary file and a buffer in the
calling program by a simple copy operation, without any form of conversion.

\medskip \noindent \irafname{binary operator} --- An operator which combines
two operands to produce a single result 
(e.g., the addition operator in $x + y$).

\medskip \noindent \irafname{brace} --- The left and right braces are 
the characters `\{' and `\}'.  Braces are used in the CL and in the 
SPP language to group statements to form a compound statement.

\medskip \noindent \irafname{bracket} --- The left and right brackets 
are the characters `[' and `]'. Brackets are used in the CL and in the
SPP language to delimit array subscripts.

\medskip \noindent \irafname{byte} --- The smallest unit of storage on 
the host machine.  The IRAF system assumes that there are an integral 
number of bytes in a \irafname{char} and in an address increment 
(and therefore that the byte is not larger than either).
On most modern computers, a byte is 8 bits, and a \irafname{char} is 16 bits
(I$*$2).  If the address increment is one byte, the machine
is said to be \emphasize{byte addressable}.  Other machines are \emphasize{word
addressable}, where one word of memory contains two or more bytes.
In the SPP language, SZB$_{CHAR}$ gives the number of bytes per char,
and SZB$_{ADDR}$ gives the number of bytes per address increment.

\medskip \noindent \irafname {C} --- A powerful modern language for 
both systems and general programming.
C provides data structuring, recursion, automatic storage, a fairly
standard set of control constructs, a rich set of operators,
and considerable conciseness of expression.

\medskip \noindent \irafname{char} --- The smallest signed integer that can be
directly addressed by programs written in the SPP language.  The char
is also the unit of storage in IRAF programs; the sizes of objects are
given in units of chars, and binary files and memory are addressed in
units of chars.  Since the SPP language interfaces to the machine via the
local Fortran compiler, the Fortran compiler determines the size of a char.
On most systems, the IRAF data type \emphasize{char} is equivalent to the
(nonstandard) Fortran datatype I$*$2.

\medskip \noindent \irafname{CL} --- The IRAF Command Language.  The CL is an
interpreted language designed to execute external \irafname{tasks}, and
to manage their \irafname{parameters}.
The CL organizes tasks into a hierarchical structure of independent
\irafname{packages}.  Tasks may be either \irafname{script tasks}, written in
the CL, or compiled \irafname{programs}, written in the SPP language, and
linked together to form \irafname{processes}.  A single process may contain
an arbitrary number of tasks.

The CL provides \irafname{redirection} of all I/O streams, including graphics
output, and cursor readback. Other facilities include command logging, an
on-line help facility, a ``programmable desk
calculator'' capability, and a \irafname{learn mode}.
New packages and tasks are easily added by the user,
and the CL environment is maintained in the user's own directories,
providing continuity from session to session.

\medskip \noindent \irafname{column} --- a one-dimensional array. The Nth
column vector of a two dimensional array or image is denoted
by the subscript [N,$*$],
where $*$ refers to all the pixels in that dimension.
The Nth column of the Mth band of a three dimensional array or image
is denoted by [N,$*$,M].

\medskip \noindent \irafname{coupling} --- A measure of the strength of
interdependence among modules.
The independence of modules is maximized when coupling is minimized.

\medskip \noindent \irafname{CTIO} --- Cerro Tollolo Image Observatory,
one of the NOAO facilities located in Chile.

\medskip \noindent \irafname{data structure} --- An aggregate of two or more 
data elements, where the elements are not necessarily of the same type. 
Examples include arrays, files, rec\-ords, linked lists, 
trees, graphs, and so on.

\medskip \noindent \irafname{data file} --- a data storage file.  Data
files are used to store program generated \irafname{records} or descriptors,
that contain the results
of the analysis performed by a program.  Datafile records may be the
final output of a program, or may be used as input to a program.  Data
file may contain ASCII or binary data, and may have implicit or explicit
data structures.

\medskip \noindent \irafname{environment variables} --- Parameters that
affect the operation of \emphasize{all} IRAF programs.
Environment variables define logical names for directories, associate 
physical devices with logical device names, and provide control
over the low level functioning of the IRAF file I/O system.

\medskip \noindent \irafname{ECF} --- European Coordination Facility. The
center that is to coordinate use of Space Telescope data and programs for 
the European scientific community.

\medskip \noindent \irafname{ESO} ---  European Southern Observatory,
headquartered at Garching, FDR.

\medskip \noindent \irafname{field} --- An element of a \irafname{data
structure} or \irafname{record}. Each field has
a name, a datatype, and a value.

\medskip \noindent \irafname{FITS} --- Flexible Image Transport System. FITS is
a standard tape format used to transport images (pictures) between computers
and institutions.  Developed in the late 1970s by Donald Wells (KPNO), 
Eric Greisen (NRAO), and Ron Harten (Westerbork),  
the FITS standard is now widely used for the
interchange of image data between astronomical centers, and is officially
sanctioned by both the AAS and the IAU.

\medskip \noindent \irafname{Fortran} --- As the most widely used language 
for scientific computing for the past
twenty years, Fortran needs little introduction.  Fortran is used in the 
IRAF system as a sort of ``super assembler'' language.  Programs and procedures
written in the IRAF \irafname{SPP} language are mechanically translated 
into a highly
portable subset of Fortran, and the Fortran modules are in turn translated
into object modules by the host Fortran compiler.  Existing numerical
and other modules, already coded in the Fortran language, are easily linked
with modules written in the SPP language to produce executable programs.
The IRAF system and applications software does not use any Fortran I/O;
all I/O facilities are provided by the IRAF \irafname{program interface} and
\irafname{virtual operating system}.

\medskip \noindent \irafname{function} --- A procedure which returns a value.
Functions must be declared before they can be used, and functions must only be
used in expressions. It is illegal to \emphasize{call} a function.

\medskip \noindent \irafname{HSI} --- The IRAF Host System Interface,
i.e., the interface between the portable IRAF software and the host system.
The HSI include the \irafname{kernel}, the \irafname{bootstrap utilities},
and any host dependent graphics device interfaces.

\medskip \noindent \irafname{hidden parameters} --- Parameters that
are not displayed by the CL.
The CL does not query for hidden parameters, but automatically
uses the default values.  Hidden parameters may be set on the command line,
but the value from the command line will not be \irafname{learned}.

\medskip \noindent \irafname{IAU} --- The International Astronomical Union.

\medskip \noindent \irafname{IKI} --- The Image Kernel Interface.  The IKI
gives IRAF the capability of dealing with multiple physical image storage
formats.  The high level image i/o software calls the IKI, which in turn
calls one of the format specific image kernels, e.g., the OIF kernel or
the STF kernel.

\medskip \noindent \irafname{identifier} --- A sequence of characters used to
name a procedure, variable, etc. in a compiled language.  In the CL and 
SPP languages, an identifier is an upper or lower case letter, followed 
by any number of upper or lower case letters, digits, or underscore characters.

\medskip \noindent \irafname{image} --- An array of arbitrary dimension 
and datatype, used for bulk data storage.
An image is an array of \irafname{pixels}.

\medskip \noindent \irafname{imagefile} --- The form in which images are
stored in the IRAF system.  IRAF currently supports images of up to seven
dimensions, in any of eight different data types.
Only \emphasize{line storage} mode is currently available, but support for
VMS mapped image sections is planned.
The imagefile structure is actually implemen\-ted as two separate files,
an \irafname{image head\-er file} and a \irafname{pixel storage file}.

\medskip \noindent \irafname{image header file} --- a file describing the
contents of an image. It is a small file that is normally placed in the
user's own directory system.

\medskip \noindent \irafname{interface} --- The visible portion of a
system, program or collection of programs.  The only portion of such a
entity that other entities need to have knowledge of or access to.
The connection between hardware or software entities.

\medskip \noindent \irafname{IRAF} --- The Image Reduction and Analysis 
Facility.
IRAF comprises a \irafname{virtual operating system}, a command language
(CL), a general purpose programming language (SPP, which
was developed along with IRAF), a large I/O library, and numerous support
utilities and scientific applications programs.  The system is designed to be
transportable to any modern superminicomputer.  The
system provides extensive facilities for general image processing,
astronomical data reduction and analysis, scientific programming,
and general software development.

\medskip \noindent \irafname{IRAF Guru} --- Any individual whose knowledge
of IRAF is greater than yours. Gurus' wisdom embraces all of the essential
mysteries of IRAF, and usually includes the locations of good Chinese
restaurants.

\medskip \noindent \irafname{kernel} --- A host dependent library of SPP
(or Fortran) callable subroutines implementing the primitive system services
required by the portable IRAF virtual operating system (VOS).  Most of the
machine dependence of IRAF is concentrated into the kernel.

\medskip \noindent \irafname{learn mode} --- A facility designed
to simplify the use of the CL. By default, the CL ``learns'' the value of all
function \irafname{parameters} that are prompted for or explicitly set.

\medskip \noindent \irafname{line} --- A one-dimensional array. The Nth line
of a two dimensional array or image is denoted
by the subscript [$*$,N],
where $*$ refers to all the pixels in that dimension.
The Nth line of the Mth band of a three dimensional array or image
is denoted by [$*$,N,M].

\medskip \noindent \irafname{list structured parameter} --- A text file, each
line of which is a record that contains one or more fields, separated
by blanks or commas, that can be interpre\-ted by the CL.
Not all fields need be present, omitted fields are indicated by insertion
of an extra comma (fields can only be omitted
from right to left).

\medskip \noindent \irafname{Lroff} --- The text formatter that is part of
the portable IRAF system and used to process \irafname{help} file text. 
Lroff is patterned after the UNIX \irafname{Troff} text formatter.

\medskip \noindent \irafname{macro} --- (1) A \irafname{script task}.
(2) An inline function with zero or more arguments that is 
expanded by text substitution during the preprocessing phase
of compilation.

\medskip \noindent \irafname{metacharacter} --- Characters that have special
meaning to the CL. For example, the asterisk `$*$' is used as a ``wild card''
place-holder; any alphanumeric character is considered a match.

\medskip \noindent \irafname{MIDAS} --- Munich Image Data Analysis System.
An analysis package under development by the ESO.

\medskip \noindent \irafname{NOAO} --- National Optical Astronomy
Observatories.

\medskip \noindent \irafname{NRAO} --- National Radio Astronomy Observatory.

\medskip \noindent \irafname{operand} --- A data object that is
operated upon by an operator, \irafname{procedure}, or \irafname{task}.
Operands may be used for either input or output, or both.

\medskip \noindent \irafname{OIF} --- The old IRAF image format.  Refers to the
physical format in which images are stored on disk, as well as to the
\irafname{IKI} kernel used to access images stored externally in the OIF format.

\medskip \noindent \irafname{OS} --- Operating System.

\medskip \noindent \irafname{package} --- (1) A collection of modules that 
are logically related (e.g., the set of \irafname{system} utilities).
(2) A set of modules that operates on
a specific \emphasize{abstract datatype}. The modules in a package may be
either \irafname{procedures} or \irafname{tasks}.
Examples of abstract datatypes include the CL, the file,
the \irafname{imagefile}, and so on.

\medskip \noindent \irafname{parameter} --- An externally supplied 
argument to a module which directly controls the functioning of the module.

\medskip \noindent \irafname{pathname} --- An absolute OS-dependent filename
specification.

\medskip \noindent \irafname{pipe} --- An abstraction that connects the output
of one \irafname{task} to the input of another. The implementation of pipes
is OS-dependent.

\medskip \noindent \irafname{pixel} --- Picture element. The fundamental unit
of storage in an \irafname{image}.

\medskip \noindent \irafname{pixel storage file} --- a file that contains image
pixel data. Typically, it is a bulky file and for this reason it is usually
placed in a file system designated for such files.

\medskip \noindent \irafname{portable} --- A program is said to be portable
from computer A to computer B if it can be moved from A to B without change
to the source code.
A program is said to be \emphasize{transportable} from computer A to computer B
if the effort required to move the program from A to B is much less than the
effort required to write an equivalent program on machine B from scratch.

\medskip \noindent \irafname{positional parameters} --- Parameters
that are required for the execution of a given \irafname{function},
and will be queried for by the CL if not given on the command line. Positional
\emphasize{arguments} are the first arguments on the command line (following
the command), and they are associated with parameters by their position
on the command line. The first positional parameter will be set by the first
positional argument on the command line, the second positional parameter by
the second positional argument, and so on.

\medskip \noindent \irafname{preprocessor} --- A program which transforms the
text of a source file prior to compilation.  A preprocessor, unlike a compiler,
does not fully define a language.  A preprocessor transforms only those
constructs which it understands; all other text is passed on to the compiler
without change.  The SPP language is implemented as a pre-processor.

\medskip \noindent \irafname{procedure} --- A separately compiled program unit.
The procedure is the primary construct provided by programming languages for
the \emphasize{abstraction of function}.
The external characteristics of a procedure are its name, argument list,
and optional return value.

\medskip \noindent \irafname{process} --- An executable partition of 
memory in the host computer.
The host OS initiates a process by copying or mapping an executable file
into main memory. In a multitasking and multiuser system, a number of processes
will generally be resident simultaneously in main memory,
and the processor will execute each in turn.

\medskip \noindent \irafname{program} --- A compiled procedure called by the
CL. The procedure must be referenced in a \irafname{task} statement before it
can be accessed by the CL.  An arbitrary number of programs may be 
linked to form a single \irafname{process}.

\medskip \noindent \irafname{program interface} --- The interface between an
applications program and everything else.  In IRAF, the program interface
defines access to all I/O devices, system services, files, and several
other non-computational facilities that pro\-grams require.

\medskip \noindent \irafname{record} --- A \irafname{data structure} consisting
of an arbitrary set of fields, used to pass information between program modules
or to permanently record the results of an analysis program in a
\irafname{data file}.

\medskip \noindent \irafname{redirection} --- The allocation of an input or
output stream to something other than the standard device.  For example,
\irafname{tasks} can be made to write output to files instead of terminals
and the output of one task may be redirected to the input of another.

\medskip \noindent \irafname{script task} --- An interpreted program written
in the CL. A script task, like a compiled program, may have formal parameters
and local variables. A script task may call another task, including another
script task, but may not call itself.
To the caller, script tasks and compiled programs are equivalent.

\medskip \noindent \irafname{SDAS} --- Science Data Analysis System. A set
of applications routines that are under development at STScI.

\medskip \noindent \irafname{SPP} --- The IRAF Subset Preprocessor Language.
A general purpose language patterned after Ratfor and C, the SPP provides
advanced capabilities, modern control constructs, enhanced portability,
and support for the IRAF runtime library (CL interface, etc.).

\medskip \noindent \irafname{STF} --- The STScI SDAS group data image format.
Refers to the physical format in which images are stored on disk, as well as
to the \irafname{IKI} kernel used to access images stored externally in the
STF format.

\medskip \noindent \irafname{STScI} --- Space Telescope Science Institute.

\medskip \noindent \irafname{system interface} --- The interface between 
the portable IRAF software and the host operating
system.  The system interface is a \irafname{virtual operating system}.
The system interface routines, described in \reference{A Reference Manual
for the IRAF System Interface}
are in principle the only parts of a system that need to be changed
when porting the system to a new computer.

\medskip \noindent \irafname{task} --- A CL callable program unit.  
CL tasks may be script tasks, external programs,
or compiled procedures which are built in to the CL.

\medskip \noindent \irafname{task statement} --- (1) The CL statement that
enters the name of a task in the IRAF task dictionary,
defines the type of task, and in the case of a compiled task, the name of
the process in which it resides.
(2) The statement in the SPP language that defines a list of programs
to be linked together to form a single process.

\medskip \noindent \irafname{template} --- A string consisting of one or more
names, which may or may not contain patterns
(with \irafname{metacharacters}).

\medskip \noindent \irafname{text file} --- A file which contains only 
text (ASCII character data), and which is maintained
in the form expected by the text processing tools of the host OS.

\medskip \noindent \irafname{Troff} --- The UNIX text formatter.

\medskip \noindent \irafname{unary operator} --- An operator which operates on
a single operand, e.g., the minus sign in the expression ``$-x$''.

\medskip \noindent \irafname{UNIX} --- An operating system developed at Bell
Labs in the early 1970s by Ken Thompson and Dennis Ritchie. Originally
developed for the PDP11, UNIX is now available on a wide range of machines,
ranging from micros to superminis, mainframes, and supercomputers.\\  
UNIX is the software development system for the IRAF project at NOAO.

\medskip \noindent \irafname{virtual file} --- A file that uses a machine
independent filename within IRAF. The virtual filename is mapped to its
host OS counterpart by the CL.

\medskip \noindent \irafname{virtual memory} --- A form of addressing that
enables a process to address locations that are not in physical memory.
The amount of physical memory available to a process is known as the
\emphasize{working set} of a process; the virtual address space is organized
into a series of fixed size \emphasize{pages}. Pages which are not
\emphasize{memory resident}, i.e., not in the working set, reside on some form
of backing store, usually a disk file.  When a page is referenced which is not
in the working set, a \emphasize{page fault} occurs, causing the page to be
read into the working set.

\medskip \noindent \irafname{virtual operating system} --- A set of system
calls that define primitive functions comparable
to those provided by an actual operating system.
IRAF provides routines (the so-called
\irafname{program interface}) for file access, process initiation and control,
exception handling, logical names, etc.

\medskip \noindent \irafname{VMS} --- The native operating system for the
Digital VAX series of supermini computers.

\medskip \noindent \irafname{VOS} --- The IRAF Virtual Operating System.
The VOS implements all of the basic functionality provided by IRAF, and defines
the environment in which applications programs are written.  For example,
the VOS provides facilities for file access, image access, access to graphics
and image display devices, access to the command language to fetch parameters
etc., process control and exception handling facilities, and so on.  The VOS
is written in portable SPP using the facilities provided by the IRAF
\irafname{kernel}.

\medskip \noindent \irafname{Z-routines} --- Machine dependent routines used
to interface to the host operating system.  The IRAF Z-routines are maintained
in the package \taskname{OS}.

\onecolumn

\end{document}