The IRAF system is distributed in three parts: the source tree
for the core system and the NOAO package (the as.* files), the binaries
for the core system (the ib.* files), and the NOAO package binaries (the
nb.* files). Because the system is distributed with source, considerable
disk space can be recovered by stripping the source files with the
cl> mkpkg strip # strip the core system
cl> cd noao # move to NOAO directory
cl> mkpkg -p noao strip # strip the NOAO package
utility, run as iraf from the iraf root. The source files are not required
for a run-time system. Software development, including IMFORT programming
and building external packages, can still be accomplished on a stripped system.
The "mkpkg strip" is normally done after unpacking the as and ib/nb
files, after IRAF is fully installed. On systems where space is extremely
tight, you can run "mkpkg strip" immediately after unpacking the as files
and running the install script. This would free sufficient space to allow
the binaries to be unpacked. We estimate about 1/2 the total diskspace
consumed by IRAF is recovered by stripping the source. If this is still not
sufficient, it is possible to delete individual binaries by hand. IRAF site
support can advise you as to which binaries are least likely to be useful
for your particular applications.
It is important to remember that IRAF doesn't necessarily have to
be installed on a disk local to the machine, any available (e.g. NFS mounted)
disk will do. External packages can similarly be stripped of source.
In general terms the install script does the following:
- edits the iraf pathname and imdir directory in the following files:
hlib$cl.csh
hlib$mkiraf.csh
hlib$libc/iraf.h
- creates fifo pipes for image display in the /dev directory
- creates the /usr/include/iraf.h symbolic link defining the iraf root
- sets root ownership for the tape allocation task 'alloc.e'
- creates symbolic links for IRAF commands like 'cl' in the site
dependent 'local bin directory'.
Because the install script affects files in system directories, root permission
is required to run it successfully. Workarounds for some things done by the
install script can be found elsewhere in this FAQ.
The install script must be run on each client machine to create the
fifo pipes for that node. If nodes in the network will be sharing an
iraf directory tree, the iraf root must appear to be the same on all nodes.
This can be done with a symbolic link and is necessary so the definition of
the iraf root in the shared hlib$cl.csh file is valid for all nodes.
The only thing done by the Unix IRAF install script in /usr is the
creation of a symbolic link /usr/include/iraf.h. This file contains
definitions necessary to rebuild IRAF (which you will not be doing) and
defines the IRAF root and HOST directories used in iraf networking. The CL
must know the IRAF root or it cannot start. However, this information is now
part of the $hlib/cl.csh script, so /usr/include/iraf.h is no longer searched
when starting the CL. /usr/include/iraf.h is searched, however, when the IRAF
root must be known without starting the CL, as in any node! reference invoking
IRAF networking. For this reason, the /usr/include/iraf.h symbolic link is
a required part of the IRAF installation.
It is common, although not necessary, to choose /usr/local/bin as
the "local bin directory" when installing IRAF. This is where the install
script makes links for commands such as 'cl' and 'mkiraf'. Any directory
(outside of the iraf tree!) can serve this purpose as long as it is in each
user's search path. It is also possible to make these commands available as
aliases, by putting the following in each user's .login file:
setenv iraf /path/iraf/ # note trailing '/' !!
source $iraf/unix/hlib/irafuser.csh
alias cl $hlib/cl.csh
Even if you cannot write to the system directories, it is still imperative
that the install script be run (as user 'iraf' at least) so that the files
in the IRAF system are properly edited with the required pathnames. If this
is not done the system may not run at all, or images will be inaccessible.
Yes, but it's not recommended. Usually the only time this is needed
is when locally written software fails to run after an IRAF upgrade (e.g.
large scripts using obsoleted tasks or parameters). In this case it is
better in the long term to upgrade the software.
Where there is no alternative to having both systems around it is
possible to have separate installations of the system, but only one can be
'installed' in the normal way for doing program development. What's typically
done is that a host level script such as
#! /bin/csh
# IRAFO -- Run the "old" (previous) version of IRAF.
setenv iraf /ursa/iraf/irafo/
setenv host $iraf/unix/
setenv hlib $iraf/unix/hlib/
setenv hbin $iraf/unix/bin/
# Set value of IRAFARCH and determine platform architecture.
if (`uname -r | cut -c1` == 5) then
setenv IRAFARCH ssun
else
setenv IRAFARCH sparc
endif
# Run the desired CL.
setenv arch .$IRAFARCH
exec $iraf/bin.$IRAFARCH/cl.e
is put in the local bin directory (which should be common to all users). The
path definitions for $iraf should be changed to point to the iraf root dir-
ectory for the old system (or whichever one is not the default). Users would
start up IRAF using this script (call it 'irafo' or something) instead of
using the 'cl' command.
In this way it is possible to have two versions of IRAF available at
the same time, but problems can arise if you log into one version using a
login.cl or parameter files generated by the other version of iraf. It is
easiest to create separate login directories for each version to isolate any
version specific files.
Section 8 of the "Introductory User's Guide to IRAF Scripts" (avail-
able as "script.ps.Z" from the iraf/docs directory of the iraf.noao.edu ftp
archive) deals with creating a personal package of tasks, including help
pages. Similarly, Chapter 7 of the "Introductory User's Guide to IRAF SPP
Programming" (available as 'sppguide.ps.Z' in the iraf archive iraf/docs
directory), also covers the creation of an IRAF package. Lastly, Chapter 4
of the "SPP Reference Manual" written by the STSDAS group (available via ftp
as stsci.edu:software/stsdas/docs in the file 'SPPManual.ps') discusses how to implement a package of SPP tasks.
Note that any external package available from our archive can be
used as a template for creating a new package. Indeed, the SPPTOOLS external
package has tasks which create and rename packages. Contact http://iraf.net
if you still have questions about how to create a package.
This message indicates a problem with the communications between the
IRAF DISPLAY task and the image display server, e.g., SAOimage or Imtool.
There are several known causes:
1. First verify that an XImtool or SAOimage process is running. You must have
a display window open before attempting to send output to it. The window
can be iconified, but it must be running.
2. If you are running SAOimage, make sure the message "Open to accept IRAF
input" appears in the text window from which you started SAOimage. If not,
restart SAOimage so it uses the IRAF fifo pipes. For the current version
of SAOimage, v1.07, or greater, this is the default. It can be
explicitly specified by adding the command line argument +imtool. Note that
the -imtool flag turns OFF IRAF communication for v1.06/1.07 of SAOimage.
If you're running v1.02 of SAOimage, the -imtool command line argument is
required for communication with IRAF.
3. If that's not it, you may have an installation problem. One function of
the install script is to make entries for the fifo pipes in the /dev
directory:
lrwxrwxrwx 1 root 10 Oct 6 1989 /dev/imt1 -> /dev/imt1o
prwxrwxrwx 1 root 0 Oct 27 1988 /dev/imt1i
prwxrwxrwx 1 root 0 Oct 27 1988 /dev/imt1o
This may have failed for some reason when you ran install. Make sure you
ran install as root after defining the IRAF environment variables.
This problem will generally only affect SAOimage displays since IRAF will
attempt to use unix sockets to connect to XImtool.
4. Another possibility is that the install script was not run on this
particular node. Install must be run on (or for) each node in the network
you intend to use with IRAF. For those nodes that have a local /usr
partition, run the install script on the machine itself. For those nodes
that don't have a local /usr partition, run install on the server for the
diskless node, then run install on the diskless node itself. More
information about installing IRAF on a network is found elsewhere in this
FAQ listing.
If none of these explains your problem contact site support for assistance.
If there's no error, DISPLAY has successfully sent the image to an SAOimage
process, but apparently not the one you intended. The image could have
been sent to another user's SAOimage window (see information about multiple
SAOimage processes per CPU elsewhere in this FAQ) or to a "zombie" process.
If you interrupt the DISPLAY task with ^C and certainly in other ways, you
can end up with an SAOimage process running without a connected window. If
you try to display and you get no output and no error, this may be the cause.
On Unix systems, you can use "ps -aux" to find the process and then kill it.
The error message almost always means there is an error in the iraf
root pathname and the param file simply can't be found. But since there's
a small chance the parameter file for the CL has been deleted or had read
removed, get a long listing of the file permissions:
tucana% ls -l $iraf/pkg/cl/cl.par
-rw-r--r-- 1 tody 1811 May 29 1992 /usr/iraf//pkg/cl/cl.par
If that checks out, you probably have an incorrect definition of the IRAF
root directory in one of two places. The iraf root is defined in the
hlib$cl.csh script which gets edited by the install script. The iraf
root can also be defined in the user's environment, which takes precedence
over the cl.csh definition.
If only the iraf account shows the error, it may be this definition
that is wrong. Make sure the login directory for the iraf account
is $iraf/local, that is, the local subdirectory of the iraf root directory.
Otherwise, the .login file won't be read as intended at login time. If the
error is seen for users other than iraf it may be that something went wrong
when install was run that resulted in an incorrect definition of iraf being
placed in hlib$cl.csh. Sometimes people have an "old" definition of iraf in
their .login or .cshrc file which can cause the error. Also check that the
value of IRAF in /usr/include/iraf.h (which is a symbolic link to
hlib$libc/iraf.h) is correct. To solve the error, you need to determine
the source of the incorrect value for the iraf root directory. Make sure
any definition of iraf in .login or .cshrc includes a trailing slash.
A second but less likely cause is that the user's environment has
defined a 'host' environment variable, typically as the machine name. IRAF
assumes that 'host', if defined, is the path to the iraf$unix (or iraf$vms)
directory. Removing or resetting this definition will fix the problem.
In general, the message indicates the named executable can't be found
or executed for some reason. It could be a problem with permissions (no read
or execute permission) or, more likely, the executable can't be found. The
named executable (x_pkg.e) is first looked for in the package bin directory,
e.g., bin$ or noaobin$. [The last placed searched is the package root
directory as reported in the error message.] You can cd to the package bin
directory and look around:
cl> cd noaobin
cl> path
tucana!/usr/iraf/noao/bin.sparc/
cl> dir long+
If all non-script tasks in the NOAO package can't be executed, an
installation error may have occurred. Check that the noao bin executables
were placed in the directory pointed to by the noao$bin.`mach' symbolic link.
It may be that they weren't installed at all or that they were placed in the
wrong directory.
Often, when tasks in an external package can't be executed, it is be-
cause mkpkg failed and the executables weren't created. Check the spool file
for errors. Another possibility with external packages is that the "-p pkg"
flag was omitted on the mkpkg command line, in which case the executables end
up in the pkg root directory with names like "pkgbinx_pkg.e". In this case,
you can simply move them to the the appropriate bin directory, the architecture
correct subdirectory of the package root directory. A trivial reason for
this error with external packages is that the package root is incorrectly
defined (maybe a missing trailing slash (UNIX) or unescaped $ (VMS)).
This usually indicates a missing or insufficient definition for
the LD_LIBRARY_PATH host environment variable. For example, on a Sun
system this may be set to simply '/usr/openwin/lib', but if the application
in question was compiled under the local X11R5 system the missing shared
object may be in /usr/lib/X11. In rare cases the missing object is in
the compiler directory.
To find out where the missing file is and reset the LD_LIBRARY_PATH
variable appropriately, try the following:
% echo $LD_LIBRARY_PATH # see what the current setting is
/usr/lib/X11
% ldd `which saoimage` # check dependencies
-lX11.4 => /usr/openwin/lib/libX11.so.4.3
-lc.1 => /usr/lib/libc.so.1.7.3
-ldl.1 => /usr/lib/libdl.so.1.0
% setenv LD_LIBRARY_PATH /usr/lib/X11:/usr/openwin/lib
This last command reset the variable so both /usr/lib/X11 and /usr/openwin/lib
are searched for the needed file, the command should run normally after that,
the directories /lib, /usr/lib and /usr/local/lib are searched by default.
The error "cannot open file (tmp$uidxxxxx)" typically indicates a
problem with the definition of the tmp directory. Either the directory
doesn't exist or you don't have write permission in it. In VMS/IRAF,
tmp$ is defined as tempdisk:[iraftmp], where tempdisk is defined in
hlib$irafuser.com as part of the IRAF installation. It is necessary to
create a directory [.iraftmp] as a subdirectory of the tempdisk area.
Some sites choose to have private tmp areas rather than a single area for
all IRAF users. This is described in the VMS/IRAF IG; often the private
tmp directory is a subdirectory of the user's login directory.
Another less likely explanation is that you may have tmp defined relative to
the current directory, so when you change directories, tmp can't be found.
Tmp should be an absolute pathname. How is tmp defined in your login.cl file?
The first step is to see how tmp$ is defined on your system and whether or not
you can edit a junk file in the directory:
cl> show tmp
tempdisk:[iraftmp]
cl> show tempdisk
usr$0:
cl> edit tmp$junk
`Dictionary full' means the CL's dictionary (what it uses to catalog
tasks, packages, parameters, etc.) is full. It can occur legitimately if
you are loading really long scripts with lots of loaded packages, local
variables, etc. It can also occur illegitimately, e.g. if a script were
repeatedly loading the same things in a loop and not unloading them. The
first thing to check is that it is not the latter; if you have to, send us
your script.
If it turns out that it is not a fault in the script design, then the
size of the dictionary can be increased. To increase the size of the diction-
ary, you would need to edit an include file in the CL package directory and
rebuild the CL. To do this:
cl> edit pkg$cl/config.h
...change DICTSIZE from its current value to something
larger (say, 50% larger)
% cd $iraf/pkg/cl
% mkpkg update
This means that the 'min_lenuserarea' iraf environment variable is
too small for the header size. This value is set as a system default in
the hlib$zzsetenv.def but can be reset by the user in their login.cl file
by uncommenting the definition (i.e. removing the '#' sign) and increasing
the size. Certain packages which deal with large headers will set this to
an appropriate value when the package is loaded. See IRAF Newsletter #10,
October 1990 (available from iraf/docs on iraf.noao.edu), for a related
discussion of "Problems with Long Image Headers".
For all platforms, graphics overlay is not currently available on
the image display in the digital photometry tasks. These tasks can read from,
but not write to, the image display. The warning message you report is normal
behavior for this task. The PHOT and POLYMARK manual pages give examples
of working interactively from a contour plot, by setting the task.display
parameter to stdgraph and the CL environment variable stdimcur to stdgraph.
This most often happens after an IRAF upgrade when the parameters for
a particular task may have changed, but the parameter file in the user's
uparm directory contain the set for the previous version. It is usually
cured with an "unlearn <task>" command, or by initializing the uparm directory
with a new MKIRAF (which is recommended anyway after an IRAF upgrade).
In cases where the problem continues, it means the last IRAF update
wasn't done properly (e.g. the patch files were not applied before installing
the binaries). Contact site support if you are unsure of the installation.
This message means there is some error in the image header dealing
with the description of the world coordinate system (WCS). In particular
the WCSDIM keyword is incorrect. The value of this keyword should
either match the dimensionality of the image if there is no WAXMAP01
keyword or half of the number of elements in that keyword if
present (that is if there are 6 numbers then WCSDIM should be 3).
How does this happen? The most common way in V2.10-V2.10.1 is that
the images produced by the APEXTRACT package when the "extras" parameter
is set, which produces 3D images, has a bug that sets WCSDIM=2. This
can be easily fixed by:
cl> hedit <images> wcsdim 3
cl> hedit <images> cd3_3 1. add+
cl> hedit <images> ltm3_3 1. add+
The last two additions are to avoid a "matrix inversion error" because
if the WCS dimensionality is 3 then there must be nonzero elements
for the step per pixel. The NPROTO.LINPOL task also has a similar
error which may be fixed similarly. Other possibilities are improper
editing of the image header by a user.
The pixels of an IRAF image are stored separately from the image header.
The pathname to the pixel file is contained in a header parameter referenced as
"pixfile" by the HSELECT and HEDIT tasks. Users occasionally need to
modify this pixel pathname, most commonly when the disk containing the pixels
has been renamed or if the pixel files have been moved en masse for system
administration reasons to a new location. The following method enables you to
modify a large number of image headers to contain new pixel pathnames. The
technique is to first create a temporary file of image names and their current
pixel pathnames using the task HSELECT. You globally edit this temporary file
to contain the new pixel pathnames and then use the modified file as input to
the HEDIT task.
cl> hselect *.imh $I,pixfile yes > filin
.... [do a global edit to filin and edit in the new pixel pathname]
cl> list="filin"
cl> {
while(fscan(list,s1,s2) != EOF)
hedit(s1,"pixfile",s2,verify-)
}
In any task that uses the GTOOLS interface (like SPLOT but not IMPLOT), you
can turn off the sysid banner with a cursor command. In interactive cursor
mode, try the command :/help for a full help page. You'll see:
:/sysid [yes|no] Include the standard IRAF user/date banner?
:/title string Title
The sysid banner includes information from the CL variable "version":
cl> show version
NOAO/IRAF V2.11EXPORT
So you can modify the sysid banner by resetting "version" to be the null
string or anything you want:
cl> reset version = ""
You can also reset the CL variable "userid" to personalize the banner. This
will affect IMPLOT as well as SPLOT plot banners.
The ^Z sequence has probably been mapped to the suspend character
on your machine. [You bring a suspended process back into the foreground
with the UNIX 'fg' command.] The ^Z is being intercepted by the terminal
driver and suspending the CL before the EPARAM task ever sees it. Mapping
of control characters is typically done with the stty command from a .login
file.
Whatever keytroke you use to EXIT_UPDATE in eparam, it must be noted
in the <editor>.ed file in dev$, where <editor> is the name of the editor
you are using (e.g., dev$vi.ed). You can have your own copy of this file in
your iraf home directory ("cl> show home"). The CL looks first in your home
directory before searching dev$ for the ed file. You can also have multiple
choices for the mapping in the .ed file, such as already exist for the MOVE_UP
and related keystrokes.