CL scripting from Unix
John Ouellette wrote on Mar 01, 2000
Hi,
I was wonder if you could provide (perhaps as a link on your web page) a
bit more info on how to
use the new ability of the IRAF cl to act as a shell for Unix scripts
(as described in v2112revs.html).
I tried a few simple scripts, none of which worked as hoped. For
example, the following script
#!/iraf/irafbin/bin.linux/cl.e -f
set home = "/astro/ouellet/niraf/login1/"
set imdir = ""
set uparm = "home$uparm/"
set userid = "ouellet"
set graphcap = home$graphcap
images
imutil
imheader /iraf/iraf/dev/pix.imh
logout
bombs with the following list of errors:
WARNING: login.cl version mismatch - rebuild with `mkiraf'
ERROR: Cannot open connected subprocess (imutil$x_images.e)
cl ()
cl ()
cl ()
cl ()
imutil ()
cl ()
immatch ()
cl ()
imgeom ()
cl ()
imfit ()
cl ()
imfilter ()
cl ()
imcoords ()
images ()
cl ()
Error while reading login.cl file - may need to rebuild with mkiraf
Fatal startup error. CL dies.
Modifying the script to include the first few lines of my login.cl
#!/iraf/irafbin/bin.linux/cl.e -f
# Identify login.cl version (checked in images.cl).
if (defpar ("logver"))
logver = "IRAF V2.11 May 1997"
set home = "/astro/ouellet/niraf/login1/"
set imdir = ""
set uparm = "home$uparm/"
set userid = "ouellet"
set graphcap = home$graphcap
images
imutil
imheader /iraf/iraf/dev/pix.imh
logout
Gets rid of the login.cl mismatch problem, but none of the other error
messages.
Thanks,
John Ouellette
Mike Fitzpatrick wrote on Mar 02, 2000
> I was wonder if you could provide (perhaps as a link on your web page) a
> bit more info on how to use the new ability of the IRAF cl to act as a
> shell for Unix scripts (as described in v2112revs.html).
Hi John,
The #!cl feature was only added in V2.11.2 and we don't have much
experience with it ourselves so unfortunately there is no formal document-
ation. I'll post something like this reply on our web pages and update
it as as we learn more to answer your question since we've had other
inquiries recently.
The short answer for your problem: You need to define an 'arch'
variable in the script to locate the binaries as well as 'logver' (e.g.
on a Solaris system where your IRAFARCH is "ssun" your definition of 'arch'
should be ".ssun", for "linux" it would be ".linux", etc). Normally this
is defined by the cl.csh startup script, along with environment defs like
$iraf and $IRAFARCH.
Now the details:
The thing to keep in mind is that a #!cl script does not make use of
a login.cl file (and thus a loginuser.cl file) or the normal environment
definitions that it sets or which are set in the cl.csh startup script.
This means that #!cl script start really fast, but things taken for granted
like package loading and foreign task definitions must be dealt with in each
script itself. Scripts will accept command line arguments, which are passed
as a space-delimited 'args' script variable and are inserted into the
cl.args parameter.
The form of a #!cl script should be something like:
#!/usr/local/bin/cl.e -f [1]
<environment definitions> [2]
<parse args> [3]
<task declarations> [4]
<script body> [5]
logout [6]
To explain each section:
[1] #!/usr/local/bin/cl.e -f
The first line of a script which calls the CL as a shell should
be something like "#!/usr/local/bin/cl.e -f", where /usr/local/bin/cl.e
would be either a copy of the cl.e executable, or a link such as
cl.e -> /iraf/iraf/bin.ssun/cl.e (don't call the link "cl", as this
name is already used for the shell script used to start up an
interactive iraf session). Note this also means the scripts can
all use a path that is platform-independent, all you need to do
to get the scripts working on a different system is change the
link or copy the new cl.e
[2] <environment definitions>
This is probably the most complex and important part of the script.
Since a #!cl script doesn't make use of login.cl file or the environ-
ment set by the cl.csh login script the #!cl script must define all
that is needed but may be taken for granted when writing 'normal'
scripts. This includes things like logical directories such as the
uparm directory, iraf root dir, foreign tasks defs, external package
definitions, and architecture-dependent settings which may need to
be modified as the script moves to new machines (e.g. any settings of
the 'arch' or 'IRAFARCH' or 'iraf' variables which are hardwired in
the script.
Other things to keep in mind:
o Once the environment stuff and packages are loaded it's probably
a good idea to put a 'keep' statement before the actual script body
begins so the definitions are retained properly.
o The variable 'logver' must be defined for any script which loads the
IMAGES package.
o IRAF logical variables can be used in #!cl scripts, but be careful
about escaping the '$' when passing values in from the shell.
[3] <parse args>
As mentioned above any unix command-line arguments to the script are
passed in as a space-delimited script variable called 'args' or are
available in the cl.args parameter. For example, a #!cl script around
the DISPLAY task called as
% display foo.fits 1 fill+
would define an 'args' parameter of
"foo.fits 1 fill+"
It is up to the script to separate the args into the values that can be
passed as valid parameters to the task(s) being used. Note that by
declaring tasks before this step you can either write a task to do the
parsing or make use of foreign tasks like 'perl', 'awk', etc.
[4] <task declarations>
In a normal CL login procedure the login.cl file defines many common
tasks such as 'ls', 'vi', and 'mv' as foreign tasks meaning they are
accessible transparently from the CL. Another function is to source a
user's 'loginuser.cl' file in order to pick up and local environment
definitions or task/package declarations (which may be called from the
#!cl script). External packages are loaded via the hlib$zzsetenv.def
file and will be available, but user's can also define a 'zzsetenv.def'
file in the current directory to override this. Unless that file also
sourced, the extern.pkg file the only way to access external packages
is to load the 'clpackage' with a command such as
clpackage
in the script.
For example, one might have an application which selects a
'stdimage' or 'printer' value via some Tcl/Tk GUI before executing
an IRAF host #!cl command. To do this, the choices are
1) edit the #!cl script environment section before executing the
command,
2) copy the zzsetenv.def and append any supplemental definitions,
3) create a file of settings that is 'sourced' using something like
cl < my_env_file
where the name of 'my_env_file' can be passed in as an argument.
[5] <script body>
The body of the script can be anything from a simple task call, to a
full-fledged CL script several hundred lines long. All that is required
is that the proper environment be defined and all the necessary packages
be loaded and tasks defined. The host scripting facility is still
primitive and we don't necessarily recommend it for large projects
it at this point, but it is functional for small tasks.
[6] logout
The last command in the script should be a 'logout' so that the CL will
terminate. Otherwise you'll be left with a running CL and not the
command prompt.
Obviously with some thought, #!cl scripts could be written diff-
erently, but it's important to remember that the 'default' iraf
environment used when writing scripts to be run under the CL be maintained
when writing host scripts. This environment however is not always
obvious, so users with questions should feel free to contact IRAF
site-support at iraf@noao.edu with any problems or questions. The host
scripting capability and our documentation of it will evolve in time, stay
tuned or ask about updates.
Hope this helps.
Regards,
Mike Fitzpatrick
Jim Lewis wrote on Mar 07, 2000
Mike Fitzpatrick wrote: > > I was wonder if you could provide (perhaps as a link on your web page) a > > bit more info on how to use the new ability of the IRAF cl to act as a > > shell for Unix scripts (as described in v2112revs.html). > > Hi John, > The #!cl feature was only added in V2.11.2 and we don't have much > experience with it ourselves so unfortunately there is no formal document- > ation. I'll post something like this reply on our web pages and update > it as as we learn more to answer your question since we've had other > inquiries recently. > The short answer for your problem: You need to define an 'arch' > variable in the script to locate the binaries as well as 'logver' (e.g. > on a Solaris system where your IRAFARCH is "ssun" your definition of 'arch' > should be ".ssun", for "linux" it would be ".linux", etc). Normally this > is defined by the cl.csh startup script, along with environment defs like > $iraf and $IRAFARCH. > > Now the details: > > The thing to keep in mind is that a #!cl script does not make use of > a login.cl file (and thus a loginuser.cl file) or the normal environment > definitions that it sets or which are set in the cl.csh startup script. > This means that #!cl script start really fast, but things taken for granted > like package loading and foreign task definitions must be dealt with in each > script itself. Scripts will accept command line arguments, which are passed > as a space-delimited 'args' script variable and are inserted into the > cl.args parameter. > > The form of a #!cl script should be something like: > > #!/usr/local/bin/cl.e -f [1] > <environment definitions> [2] > <parse args> [3] > <task declarations> [4] > <script body> [5] > logout [6] > > To explain each section: > > [1] #!/usr/local/bin/cl.e -f > > The first line of a script which calls the CL as a shell should > be something like "#!/usr/local/bin/cl.e -f", where /usr/local/bin/cl.e > would be either a copy of the cl.e executable, or a link such as > cl.e -> /iraf/iraf/bin.ssun/cl.e (don't call the link "cl", as this > name is already used for the shell script used to start up an > interactive iraf session). Note this also means the scripts can > all use a path that is platform-independent, all you need to do > to get the scripts working on a different system is change the > link or copy the new cl.e > > [2] <environment definitions> > > This is probably the most complex and important part of the script. > Since a #!cl script doesn't make use of login.cl file or the environ- > ment set by the cl.csh login script the #!cl script must define all > that is needed but may be taken for granted when writing 'normal' > scripts. This includes things like logical directories such as the > uparm directory, iraf root dir, foreign tasks defs, external package > definitions, and architecture-dependent settings which may need to > be modified as the script moves to new machines (e.g. any settings of > the 'arch' or 'IRAFARCH' or 'iraf' variables which are hardwired in > the script. > Other things to keep in mind: > > o Once the environment stuff and packages are loaded it's probably > a good idea to put a 'keep' statement before the actual script body > begins so the definitions are retained properly. > o The variable 'logver' must be defined for any script which loads the > IMAGES package. > o IRAF logical variables can be used in #!cl scripts, but be careful > about escaping the '$' when passing values in from the shell. > > [3] <parse args> > > As mentioned above any unix command-line arguments to the script are > passed in as a space-delimited script variable called 'args' or are > available in the cl.args parameter. For example, a #!cl script around > the DISPLAY task called as > > % display foo.fits 1 fill+ > > would define an 'args' parameter of > > "foo.fits 1 fill+" > > It is up to the script to separate the args into the values that can be > passed as valid parameters to the task(s) being used. Note that by > declaring tasks before this step you can either write a task to do the > parsing or make use of foreign tasks like 'perl', 'awk', etc. > > [4] <task declarations> > > In a normal CL login procedure the login.cl file defines many common > tasks such as 'ls', 'vi', and 'mv' as foreign tasks meaning they are > accessible transparently from the CL. Another function is to source a > user's 'loginuser.cl' file in order to pick up and local environment > definitions or task/package declarations (which may be called from the > #!cl script). External packages are loaded via the hlib$zzsetenv.def > file and will be available, but user's can also define a 'zzsetenv.def' > file in the current directory to override this. Unless that file also > sourced, the extern.pkg file the only way to access external packages > is to load the 'clpackage' with a command such as > > clpackage > > in the script. > For example, one might have an application which selects a > 'stdimage' or 'printer' value via some Tcl/Tk GUI before executing > an IRAF host #!cl command. To do this, the choices are > > 1) edit the #!cl script environment section before executing the > command, > 2) copy the zzsetenv.def and append any supplemental definitions, > 3) create a file of settings that is 'sourced' using something like > > cl < my_env_file > > where the name of 'my_env_file' can be passed in as an argument. > > [5] <script body> > > The body of the script can be anything from a simple task call, to a > full-fledged CL script several hundred lines long. All that is required > is that the proper environment be defined and all the necessary packages > be loaded and tasks defined. The host scripting facility is still > primitive and we don't necessarily recommend it for large projects > it at this point, but it is functional for small tasks. > > [6] logout > > The last command in the script should be a 'logout' so that the CL will > terminate. Otherwise you'll be left with a running CL and not the > command prompt. > > Obviously with some thought, #!cl scripts could be written diff- > erently, but it's important to remember that the 'default' iraf > environment used when writing scripts to be run under the CL be maintained > when writing host scripts. This environment however is not always > obvious, so users with questions should feel free to contact IRAF > site-support at iraf@noao.edu with any problems or questions. The host > scripting capability and our documentation of it will evolve in time, stay > tuned or ask about updates. > Hope this helps. > > Regards, > Mike Fitzpatrick Hi, Any chance of a couple of example scripts ? cheers, Jim
Last post on Mar 07, 2000