iraf.net

Hi Keith,
Sorry for the delay in replying. There is no more current
documentation on package structure but I've prepared a more up-to-date
template package you can use in ftp://iraf.noao.edu/pkg_template.tgz
(gzip'd tarfile). All you need to do is rename all files containing
'extern' in the name to whatever the package will be called, and edit
the contents of each file to similarly include the package name (e.g.
'extern.cl' becomes 'mypkg.cl', etc). There are no hard rules about
this, you can put your scripts in the 'src' subdirectory or include them
at the top level. The key file is the <pkg>.cl which declares the
tasks and loads the package. The <pkg>.hd file defines the help data-
base for the tasks, I'd have to see your current file to make a guess
as to why you're getting a bus error.
The 'package is not unique' errors may be related but usually
just means there a conflict with an existing package definition, e.g.
the 'slalib' in the core system and the 'slalib' help pages in an
external package like IMMATCHX. These can usually be ignored. If
typing 'help' doesn't produce the current package menu it's an error
in the ".hd" file, using the new template .hd as a guide should clear
that up.> And another question: my habit has been to keep the default
> parameter values for a cl script in the .cl file along with the
> parameter declarations, but it seems that these .par files abound in
> the various packages I've rooted around in. Is there any reason this
> is necessary in tasks defined as part of a package, or is it just
> a programming style? For procedure scripts the common practice is to just have the
script define the parameters so there is no need for an associated .par
file for each script. The exception is normally the package .cl file
which may contain a simple "version" parameter giving the date of the
release or may contain more glabal parameters that affect all tasks. Hope this helps, let us know if you still have problems or
questions.Cheers,
Mike Fitzpatrick