iraf.net

Hi there,I have noticed that when I try to run an interactive task from a c shell script, the prompts are answered for me i.e., it does not wait for me to respond; it is like it is hitting <return> for me.My c shell script contains the line:[code:1:fb0a022c34]cl < myscript.cl[/code:1:fb0a022c34]where myscript.cl contains a task definition for an interactive task, along with the execution of the task:[code:1:fb0a022c34]task $myinteractivetask = /path/myinteractivetask.cl
myinteractivetask[/code:1:fb0a022c34]I have also tried [code:1:fb0a022c34]myscript.cl | cl[/code:1:fb0a022c34]and [code:1:fb0a022c34]cl <<EOF
task $myinteractivetask = /path/myinteractivetask.cl
myinteractivetask
EOF[/code:1:fb0a022c34]and all have the same results. However, when I just have [code:1:fb0a022c34]cl[/code:1:fb0a022c34]in my c shell script and I type the commands manually into the ecl> prompt when it appears, the task will work correctly and wait at the prompt for an answer from me. Also, if I add into myscript.cl the replies to the prompts (i.e., y, n, etc) it reads them correctly.Basically, what I think is happening is when the task is redirected into the cl from myscript.cl and the task is executed, it tries to exit the cl at the next prompt (i.e., when it thinks the task has finished), when, in fact, it is waiting for a response from me.So my question is, is there a way to tell my script to wait until I have entered the replies to the prompts? Or a way to execute the commands in myscript.cl so that it is just like I am typing them in on the command line (i.e., no EOF)?Many thanks,Emma

Hi Emma,Maybe Mike has additional comments, but basically this is a problem we are already familiar with. I think it occurs because when you redirect a script to the CL, the script replaces the standard input and IRAF tries to get the prompt answers from it as well as the commands to execute. As far as I know there is no proper solution using the "cl <" syntax. You have to declare the script as an IRAF task or a "host" script (CL shell script, ie. using #!/cl) or cut and paste the script from your editor into the CL to run it. Sometimes the fastest thing to do is comment out sections of the script and run it a bit at a time with the "cl <" method. Jen and Kathleen should also be able to comment on this (eg. if you have a question about a specific application such as the RTF).Cheers,James.

Hi James,I think deep down I knew the "cl <" syntax had issues when running interactive tasks but that's why I was trying to find an alternative method! I already tried putting the commands from myscript.cl into a CL shell script and running that from my c shell script, but it still doesn't wait for me to answer the prompts. I really thought that the "cl <<EOF ... EOF" syntax would work, since it was equivalent to pasting the commands into the CL ... but I think the EOF is ruining everything I guess I was just wondering whether there is a command that I can put before the EOF in the "cl <<EOF ... EOF" syntax that will wait to read the EOF until the task has completed? Thanks,Emma

As with many thing IRAF, there is some subtlety in what you're trying to do: The command[code:1:7f740f47b2]cl < myscript.cl[/code:1:7f740f47b2]when use in a shell means means the 'cl' in this case is the CL startup script that happens to be a C-shell script that eventually invokes the binary. This is different from the same command issued at the CL prompt where the 'cl' is then just the interpreter to execute the script directly. Another case is in the use of a #!cl script which calls the CL binary directly to run the script, this is much like the first case of using it from the unix prompt.What these all have in common is that the redirection affects not only the unix stdin but also the standard input stream in the CL and the binaries it invokes as well. The effect as James explained is that [b:7f740f47b2]all[/b:7f740f47b2] standard input is taken from the script file meaning that if you call a task that reads from stdin the next line in your script will be the input. If you know that your script requires 3 newline chars to answer the prompt then 3 blank lines in the script might do the trick, but more commonly it isn't so simple.Also note that [i:7f740f47b2]how[/i:7f740f47b2] you prompt for the input is important as well, i.e. a parameter query is different that calling a compiled task expecting to read from stdin (in the CL they are different I/O streams). Likewise, a graphics cursor response is different as well and the normal way to supply that input is with a cursor command file (see 'help cursors' for details).If your task is truly interactive, i.e. you have a variable number of prompts or the answers won't always be the same, then I can't think of a reliable way to start this from a script other than to just invoke the 'cl' so you still have terminal input. Depending on what your script is doing, calling the binary directly might be an option (but not for graphics tasks) but I'd really have to see the script to make concrete suggestions (and/or to burst your hopes and tell you it can't be done). I actually don't know whether using pyraf as the interpreter would help in this case.-Mike