iraf.net

I have got a lot of scripts working under iraf/fedora/ncl - and I am having a problem
running some of them under iraf/macos/ecl (or ecl under iraf/fedora). This is an example script:
(pp.cl)procedure pict(input)char input{"",prompt="input file"}beginreal zpab[8]=24.0,24.828,26.634,23.02,22.090,25.872,26.226,26.169real factor[8]print("starting")
print("here")print("test ",factor[1],factor[2],factor[8])
print("test ",zpab[1],zpab[2],zpab[8])factor=0.1*10.**((25-zpab)/2.5)print("testout ",factor[1],factor[2],factor[8])print("here")
end
(obviously simplified to test out the problem).I define
task pp=pp.cland then runpp "test"Under fedora/ncl I get properly:
starting
here
test INDEF INDEF INDEF
test 24. 24.828 26.169
testout 0.25118864315096 0.11716556739113 0.034072186165936
hereUnder macos/ecl :ecl> pp test
starting
here
test INDEF INDEF INDEF
test 24. 24.828 26.169
ERROR: stack underflow
""
line 4: pp.cl
called as: `pp (input=test)'The error goes away if I assign the array elements individually - it seems.
But I don't like to have to change all my scripts.
I also noticed that some of my environment variables (under unix) got
effected. (for one of my other scripts,
ecl> !printenv LOGNAME would give a messed up username
)It turns out that ecl on fedora also produces the error listed above.
Is it possible to "fix" ecl ? some logical ? Any help is appreciated !

This appears to be introduced with the ECL, which saw quite a few changes in implementing the error handling. I'd have to dig down into it to figure out what might be wrong, but a quick wotkaround is simply to use the old CL. You can start this from the unix commandline as "cl -old" and your script should work again.As for the environment variables, a stack corruption like this could easily mess up any number of things. Do you see the problem anytime other than when using the ECL with these array scripts?-Mike

thanks a lot for the speedy response. I can confirm that "cl -old" works perfectly fine. I never had any problems with these scripts before, it is really switching over to ecl (independent of operating system) which appears to be causing the trouble. At least I have a solution for now (running the old cl).