1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
.help "intro" Feb86 language
.ih
NAME
intro -- a brief introduction to the CL
.ih
DESCRIPTION
1. \fBGeneral\fR
The CL (or Command Language) is the command interpreter of the IRAF
environment. Among it's responsibilities are: task initiation and
termination; parameter retrieval and updating; and error handling.
In addition the CL has certain `builtin' utility functions which enable
monitoring and changing of the IRAF environment, control flow features
roughly modeled after C and Ratfor as well as fairly sophisticated
capabilities for performing mathematical calculations and string manipulation.
The CL environment may easily be extended by the user.
2. \fITask Initiation and Termination\fR
IRAF organizes tasks into groups called \fIpackages\fR. When a package
(which is itself a special kind of task) is invoked, it defines
all the tasks which belong to that package, and the user may
then execute any of the tasks in the package. Some of these new
tasks may themselves be packages. Normally at the start of a
CL session, the \fIlanguage\fR package, including all functions built directly
into the CL, and the \fIsystem\fR package, which contains basic system
utilities, are automatically invoked. The user may configure their
"login.cl" file to automatically invoke other packages.
Within the CL a task is invoked by entering its name, e.g.
cl> reduce args
If two tasks in different packages have the same name, then the
package name may be included:
cl> spectra.reduce args
The task name may be followed by a parameter list and tasks
may be linked together by pipes (see parameters). The task initiates
execution of either a script file, an ASCII file containing further
CL commands, or an executable image, an external program linked with
IRAF libraries so that it may be called as a sub-process from the
CL process. The correspondence between the task name and the name
of the script or image file is made using the task and redefine builtin
commands.
When a script is run the CL effectively calls itself recursively
with the new incarnation of the CL having its standard input
not from the terminal, but from the script file. When the script
terminates the recursion unwinds, and the CL returns to an interactive
mode. A script may itself call another script or executable.
An executable is run as a separate process with communication
and synchronization maintained using an inter-process communication
link (a pipe in UNIX or a shared memory region in VMS). When
the executable requires a parameter a request is sent across the
link, and the CL replies in the same fashion. When the process terminates
it informs the CL and then hibernates. Normally the executable's
process is not terminated, but is maintained in a process cache
so that the executable may be used again without the overhead of
re-initiating the process. The process finally terminates when the CL
finishes, when the space in the cache is needed by a new executable
image, or when the user explicitly clears the cache using the flprcache
command. The size of the process cache is small, usually only
three executables can be maintained in the cache.
3. \fIParameter Retrieval and Update\fR
Most CL tasks have a parameter list associated with them. When the task
starts up, the CL looks to see if the user has a private copy of the
parameters from the last time he ran this task. If so these parameters
are loaded into memory. Otherwise the CL looks for the default values
of the parameters and loads these. While the task is active
the parameters are maintained in memory, but when it finishes the CL
checks if any `learned' parameters have been modified. If so
a new private copy of the parameters is stored into the directory
pointed to by the IRAF logical name `uparm'. A number of
builtins are used to control the handling of parameters including
lparam, eparam, update and unlearn.
4. \fIError Handling\fR
The CL attempts to trap most kinds of errors that may occur and
to keep the user in a viable IRAF environment. When an error occurs in
a script, execution of the script is terminated and the CL returns to an
interactive level. The user may force an error using the \fIerror\fR
builtin. When a executable image encounters an error it cannot handle
itself, it sends an error message to the CL and then hibernates in the
process cache until its next invocation. If executable was called by
a script, the script is terminated and the CL returns to an interactive mode.
The error message from the executable is relayed to the user.
.ih
SEE ALSO
commands, mathfcns, strings
.endhelp
|
