iraf.net

Hi people,
I'm running IRAF in a PC SUSE 9.x. The problem is that we haven't a
proper STSDAS compiled for it at STScI, so the people here compiled
STSDAS and TABLES in a lower SUSE distribution in order to pass thru the
gnu lib gcc-3 incompatibilities.
The fact is that I can no longer run IRAF in batch mode (cl < dumm.cl).
It seems to initialize, it writes headers and presentations but stops at
the first iraf task calling. It gets out and prints characters like "
;32;80t" at the unix prompt.
I don't know if this problem has some conection to our domestic binaries
compilation procedure.
I wonder if you have an idea about and help me to get over this limitation.Cheers,
J.L. Kohl Moreira

Hi J.L.,Without seeing the script I can't be specific, but the output appears to be some sort of tty setting. This might happen from an iraf task that e.g. pages a help file, but it could also happen the first time you call a foreign task (i.e. 'cat' instead of the iraf 'type' command) if your .cshrc file contains something like an stty/tset command (these belong in your .login anyway). Also, I assume you're using the "cl < dumm.cl" from within the CL already -- if you're doing this from the unix command line the 'cl' is the CL startup command and most likely you're seeing the clear screen issued by your login.Hope this helps, please supply more details if you still have questions.Cheers,
-Mike

Hi Mike,
Actually, I'm running from outside IRAF, that's say, from UNIX. I tried run a simple script like that one in file "dummy.cl":imcopy dev$pix acopy.fits
logoutfrom my Suse 9.x I and Mac OS 10.3 I have the weird stuff I told you in the last message. Note that the command "imcopy" is not executed because no file named "acopy.fits" in the folder.But, from a Suse 10.x and exactelly the same IRAF distribution, no problems. The command is pretty well executed.
I suspect, then, the bug is at the Suse and Mac OS X distributions, isn't it?Cheers,
J.L.

I just now noticed usage like this is mentioned in the FAQ (which I probably wrote), however I'd discourage you from using the unix 'cl' command in this way since it is different than say doing "cl < dummy.cl" from the CL itself. One goes through the whole CL login process, the other simply runs the CL command interpreter on the file. What I think you want is the latter, but from the unix prompt.So, see http://iraf.noao.edu/iraf/web/new_stuff/cl_host.html for ways to turn your dummy.cl file into a host-callable script and ignore the FAQ.In this particular case however, I think the behavior is explained by whether or not you have a login.cl file present in the directory. Specifically, the 'stty' command in that file does something to effectively "read" the first line of redirected input. Your example dummy.cl fails as you describe if the imcopy is on the first line, but works if there is a blank line before it. The "funny output" chars ;32;80t however are coming from the stty command as it tries to get the window size.Cheers,
-Mike

Mike,
Once you've mentioned TTY environments I've scanned for it in the login.cl files. Bingo! The stty declaration makes all the difference. One thing is for sure: calling "cl" from Unix batch does not work if stty declares "xgterm" in the login.cl. When I've changed it to "xterm", everything has become all right!
Perhaps it should be taken as a little hint to the users.Cheers,
J.L.PS. Good stuff the page you indicated on the last message. It clarifies many things to me.