iraf.net

Hi,We are having a strange problem here. The syntax :
% cl < test.cldoes not work anymore. Well, I can get it to work mysteriously from some accounts, on some machines, but mostly it doesn't work. I suspect a silly configuration thing, but frankly I'm running out of things to try.So, if my test.cl is simply:
print('junk')
print('junk2')what can get in the way of "% cl < test.cl"? Note that sometimes I get the second print statement and if I add a few comment line ("#") the first print shows up too. This behaviour is not always observed, but it points at something 'eating' the content of test.cl.Any ideas?Kathleen

Hi Kathleen,Be sure you don't have a login.cl file in the directory you're working in, the 'stty xgterm' in there is what's eating the input.-Mike

Ah! Yes, commenting out that nasty stty xgterm does the trick.Question, doesn't one need the login.cl even when using % cl < test.cl ? Won't the configuration in login.cl and loginuser.cl be needed?In any case, commenting out stty xgterm or even setting it to be stty xterm solves the problem.Thanks Mike,
Kathleen

[quote:6ac2900280]Question, doesn't one need the login.cl even when using % cl < test.cl ? Won't the configuration in login.cl and loginuser.cl be needed? [/quote:6ac2900280]It depends on the script: Your test.cl certainly doesn't need it if all it does is call print(), more complex scripts will need packages loaded, foreign tasks defined etc. A better way to do this is which #!cl scripts where you're forced to setup the environment in the script rather than rely on a login.cl/loginuser.cl. Keep in mind that 'cl' is a csh script to startup the ecl.e/cl.e binary and setup things like $iraf.-Mike

Hi Mike,Following up on that last point, recently I've been finding that I sometimes get strange errors when using "host scripting" (with #!cl). I *think* I was seeing segmentation errors and a failure to connect with x_system.e (sorry, I don't have a proper note here and I may have got that wrong, but I wondered if this is a known problem -- otherwise I'll try to dig out the message later). The first time I saw this on Linux, I made the errors go away by doing a "set stacksize unlimited". The second time, I saw it on Solaris and the error went away after unsetting certain environment variables ("arch" and "host"), but I'm not sure the problem was really related to those variables directly, rather than some memory error that was no longer manifested after I unset them. Ironically, it was suggested to me that I do "cl <" instead, opposite to what you say above...Anyway, thanks for the quick solution to the above problem (as usual).James.

PS. In both cases, the task I was trying to run in the host script was mkhelpdb.cl.

Sorry -- I meant to say "mkhelpdb" without the cl. Too fast on the send button.

[quote:457d77b3d4]Ironically, it was suggested to me that I do "cl <" instead, opposite to what you say above... [/quote:457d77b3d4]What can I say, I use a Mac and have even the obscure iraf environment variables set in my .cshrc file. The reason "cl <" fixed your problem is because the 'limit stacksize unlimited' is in the cl.csh startup script. For #!cl you need to put this in your .cshrc/.login (a "!limit ..." escape command in the script won't do it).Things like $arch are also set in cl.csh and are needed to resolve the 'bin$' logical path (i.e. do a "cl> show bin" to see what I mean), this would explain a problem in finding x_system.e.Cheers,
-Mike

Thanks, Mike. It sounds like I was seeing 2 separate problems that I had thought were connected, one being the stacksize and the other being improper initialization of the environment for the host script. I was actually using "arch" for something else in the calling shell script, which probably didn't help... I still don't understand why it worked on one platform and not another, but this gives me a better idea what's going on.It sounds like there is no fundamental difference between "#!cl" and "cl <", other than what's in cl.csh and login.cl, which is useful to know -- I had the impression that "#!cl" was just a bit flaky, but it may just come down to me not understanding properly what the usual setup involves.Cheers,James.

[quote:2fcb4bb0f2]It sounds like there is no fundamental difference between "#!cl" and "cl <", ......[/quote:2fcb4bb0f2]Well, sorta. The #!cl is meant to use the CL binary directly as the script interpreter (the same way #!/bin/csh uses the C-shell as the interpreter), and so the setup of the environment is left to the script and/or the user. Using the "cl <" redirection eventually fires off the binary and as started this thread, will use a login.cl file if present (the "#!cl.e -f" won't). One major advantage of the #!cl approach is that you can pass in arguments since the commandline gets stuffed into the CL 'args' parameter, e.g. you can write a standalone 'help' script and give it a taskname.Internally, however, a #!cl is implemented using the redirection so in that sense they're the same.Cheers,
-Mike