iraf.net

Hi,I have 3 recent questions concerning IRAF, and I could not find related
stuff in the FAQ/docs.
If You could help, I'd appreciate it. Thanks in advance,
Gaspar=======================================================================
Q001:How does iraf autoload a given task? (Ie is there any task which tells where
another task resides?)
=======================================================================
Q002:When using iraf in externally in a manner
cl < sth.cl
how can one eliminate the prompts and escape sequences in the output?Eg.:
[hatuser@hat iraftcl]$ cl < imgstat.cl
cl> im> im> im> im> im> im> im> im> im>
im> /data2/hatuser/HAT-1/20010926/10793 4194304 268.1891 1.673077 260. 985.
/data2/hatuser/HAT-1/20010926/10849 4194304 270.8053 2.382649 260. 935.
im> [hatuser@hat iraftcl]$ 24;80tI would need stable and clear output for further parsing.
=======================================================================
Q003:When using the host scripting facility of cl (!<path/cl.e -f), I would like
the script to return with return values showing the error status.
Actually I am trying to build an IRAF - Tcl interface, where tcl would
generate a script according to the users' needs (eg. invoke imstat on a few
images). I would like to check if the task exists, if the needed packages
exist, etc, and if not, return a value different from 0.Is this possible?
I see that "logout" and "bye" have no return values. "return" can be used to
exit a procedure, but not the whole script.Example script:#!/usr/local/iraf211/bin/cl.e -f# Definitions from the IRAFTCL file
cl < /home/hatuser/source/iraftcl/login.cl# Load necessary tables, etc.
#
if (defpac ("images") == 0) {
printf ("%s\n","Loading images");
images
}
;if (defpac ("lofasz") == 0) {
printf ("Error!");
logout 1
return 1
bye 1
????
}
;=============================================================================+ ------------------------------------------------------------------------ +
Gaspar A. Bakos
Predoctoral Fellow, Solar and Stellar Physics Division
Harvard-Smithsonian Center for Astrophysics
60 Garden Street, Cambridge, MA 02138 (USA)
Phone(office): 617-495-7410 Fax: 617-495-7049
email: gbakos@cfa.harvard.edu or bakos@konkoly.hu
homepage: http://cfa-www.harvard.edu/~gbakos
+ ------------------------------------------------------------------------ +

Hello Gaspar,> How does iraf autoload a given task? (Ie is there any task which tells
> where another task resides?)Each package contains a script task which is responsible for defining
the contained tasks and setting any necessary context for the package.
The help page for a given task usually provides an indication of the
package executable that contains a given task. One can also run the
task at the command line and then examine the process cache using the
prcache task to figure out what process IRAF started to run the task.> When using iraf in externally in a manner
> cl < sth.cl
> how can one eliminate the prompts and escape sequences in the output?In general, that is indeed a complication. I would advise using the
#!cl technique instead, or calling the specific iraf executable for
simpler applications not involving a lot of script control structures.At some point it becomes easier and more robust to implement a compiled
IRAF SPP task rather than a script.> When using the host scripting facility of cl (!<path/cl.e -f), I would
> like the script to return with return values showing the error status. This is not currently supported. One could perhaps work around this
using simple semaphors explicitly written into /tmp files.> Actually I am trying to build an IRAF - Tcl interface, where tcl would
> generate a script according to the users' needs (eg. invoke imstat on
> a few images). I would like to check if the task exists, if the needed
> packages exist, etc, and if not, return a value different from 0.We are examining the possibility of direct iraf support for multiple
scripting languages. TCL would be near the top of the list, as would
Python and Perl, etc. There has been no determination whether to
proceed with this project as yet.Rob Seaman
NOAO/IRAF

Hi Gaspar,> I am working on a data reduction pipeline for an automated telescope
> (HAT: http://cfa-www.harvard.edu/~gbakos/HAT/index.html)Looks like an interesting project!> Yes, the question when building a new pipeline is how deep shall I go to
> IRAF. It is very charming that most image reduction facilities are already
> written there, so I woulnd't need to rewrite them. Right. A continuing project will provide general purpose "Data Handling"
services for data acquisition systems such as the NOAO Mosaics. Among
other things this will provide pipeline access to IRAF tools. No schedule
is available for this project. (We're always oversubscribed.)> I don't know of any simple library consisting of building blocks
> suitable for assembling a pipeline, such as simple standalone tasks for
> bias/dark/flat reduction, aperture photometry, and so on, which have
> proper io control, pipes could be directed to them and from them, etc.
> I have a lot of public standalone software (daophots, isis, dophot), but
> i still think the astronomical community lacks a flexible unix-like
> environment consisting of small blocks, which can be controlled from
> whatever environment.The goal of simplicity contends with the goal to address all the
problems that you mention (and more) in a somewhat complete fashion.
Or on another axis, computer science needs contend with astronomical
science needs.> So I will try to use IRAF, as I like it, and used it a lot. I will
> generate files, and pipe them in cl, or generate host cl script files.
> This means writing to/reading from disk all the time, which will slow
> down the pipeline. Well, the file system should insulate you from a lot of that overhead.
In general, interpreted scripts are always going to be slower than
compiled tasks.> Error handling would be essential, as the pipeline has to stop
> whenever there is some problem, and has to handle it efficiently.Right. As I said, the basic idea would be to provide parallel access
to more modern scripting languages rather than try to retrofit the CL
with new capabilities.> What I will do is to use the iraf logging facility, and check if it
> 1) logged out properly
> 2) there are no error messages, such as "ERROR: "
> 3) there are no other flags defined by me.
> This is an awkward workaround, but for the moment it will do. Ok. I can't advise much better.> Tcl, python and perl - indeed, they are the ones of which I can think.
> I stay at tcl, as it has free compiler: TclPro, which is a very high
> quality one, and any script (environment) can be compiled with it
> resulting in a much faster executable. Also my whole telescope's
> control system is written in tcl. We already use TCL for various things like IRAF graphical user interface
definition and scripting in the IRAF data handling system. There is a
prototype python replacement for the IRAF CL. No specific ties to perl -
but it's an obvious choice.> Instead of file communication it would be very nice to be able to send
> commands to IRAF via sockets.The IRAF kernel already includes this capability. The hard part is
retrofitting all the layers above that to make use of sockets.You appear to be asking the same questions we are - it is simply hard to
move anything as large and integrated as IRAF on a rapid timescale given
the large number of projects we're committed to - and the large number
of outside projects that rely on the stability of IRAF.Rob