Programming IRAF scripts in C
Elden Paul Iverson wrote on Apr 01, 2008
I was wondering if it is possible to write programs in C that integrate with IRAF packages/commands. If so, do you have any suggestions of where I could go to start. I am looking for examples, etc.
Thanks.
-Paul
Thanks.
-Paul
Mike Fitzpatrick wrote on Apr 01, 2008
Short Answer: It is possible, but painful and limited in terms of what you can do.
Long Answer: There are several levels at which you might want to interact with IRAF -- The script level, compiled tasks, or IRAF interfaces such as utility libs in the XTOOLS package (which sometimes show up in a help search and are confused as tasks, e.g. ICFIT). The first two are similar if what you want to is to be able to invoke a task from within another program, doing this however basically comes down to something like a system() call to invoke a host command. That host command can be a "#!cl" script (see http://iraf.noao.edu/iraf/web/new_stuff/cl_host.html) that encapsulates the IRAF functionality in a host command, or something more low-level like calling the executable for the task directly and supplying parameters on the command-line (in this case you won't have graphics though, a #!cl script of the same command starts a CL to do graphics). Note that in this case anything computed by your program must be passed to the command through files/parameters.
At the lower level where you want to call an interface, you would need to provide a binding for it and take into account C vs Fortran array ordering, IRAF strings vs C strings, etc. STSDAS provided a limited CVOS interface to some of the core iraf interfaces (e.g. IMIO) and there exists a C binding to IMFORT to access IMH images, but anything in XTOOLS or subroutines of tasks would require a custom interface. At the level where you want to e.g. call IMEXAM as a subroutine, you'd need to replicate a lot of the CL functionality like sub-process communications, parameter passing, graphics handling, etc.
If you really need IRAF tasks and are truly talking about "scripts", a better approach is to break up your C code into separate commands and call them as foreign tasks from a CL (or pyraf) script. For scripting there are a number of languages better than C.
Back when the Multi-Language CL was being contemplated, support for the 'CH' language (a true interpreted C) was on the list of what might be supported along with things like Python and Tcl. I've been told "the ML-CL will never happen" (officially anyway), but discussions are about to begin on "next-gen" systems and who knows what kinds of command/scripting environments might come out of that. As part of another project I developed an "IRAF Command Server" that basically let you send an IRAF command string to a socket for execution, this would be a simpler interface in your C code but still isn't ideal.
Cheers,
-Mike
Long Answer: There are several levels at which you might want to interact with IRAF -- The script level, compiled tasks, or IRAF interfaces such as utility libs in the XTOOLS package (which sometimes show up in a help search and are confused as tasks, e.g. ICFIT). The first two are similar if what you want to is to be able to invoke a task from within another program, doing this however basically comes down to something like a system() call to invoke a host command. That host command can be a "#!cl" script (see http://iraf.noao.edu/iraf/web/new_stuff/cl_host.html) that encapsulates the IRAF functionality in a host command, or something more low-level like calling the executable for the task directly and supplying parameters on the command-line (in this case you won't have graphics though, a #!cl script of the same command starts a CL to do graphics). Note that in this case anything computed by your program must be passed to the command through files/parameters.
At the lower level where you want to call an interface, you would need to provide a binding for it and take into account C vs Fortran array ordering, IRAF strings vs C strings, etc. STSDAS provided a limited CVOS interface to some of the core iraf interfaces (e.g. IMIO) and there exists a C binding to IMFORT to access IMH images, but anything in XTOOLS or subroutines of tasks would require a custom interface. At the level where you want to e.g. call IMEXAM as a subroutine, you'd need to replicate a lot of the CL functionality like sub-process communications, parameter passing, graphics handling, etc.
If you really need IRAF tasks and are truly talking about "scripts", a better approach is to break up your C code into separate commands and call them as foreign tasks from a CL (or pyraf) script. For scripting there are a number of languages better than C.
Back when the Multi-Language CL was being contemplated, support for the 'CH' language (a true interpreted C) was on the list of what might be supported along with things like Python and Tcl. I've been told "the ML-CL will never happen" (officially anyway), but discussions are about to begin on "next-gen" systems and who knows what kinds of command/scripting environments might come out of that. As part of another project I developed an "IRAF Command Server" that basically let you send an IRAF command string to a socket for execution, this would be a simpler interface in your C code but still isn't ideal.
Cheers,
-Mike
Last post on Apr 01, 2008