ecl crashes on execution
JCab wrote on Jun 02, 2008
I am attempting to reduce some Hectospec data using their shell scripts and while I am quite sure these scripts worked pre-IRAF 2.14, I am currently havingfailures with IRAF 2.14.
Specifically there is a script called 'callhectospec' which calls ecl and looks like this (some lines removed for clarity:
When I attempt to execute this script from the command line, even with the final printf command (which passes the actual command to cl) commented out, I get the following error:
I can execute commands within IRAF with no issue, but this script is crashing. Anyone have any idea what might have changed in ecl between versions 2.12.2 and 2.14? I would suspect the call to cl(), but commenting out that line results in the same error.
Specifically there is a script called 'callhectospec' which calls ecl and looks like this (some lines removed for clarity:
#!/scisoft/all/packages/iraf/irafbin/bin.macosx/ecl.e -f
# This script runs HPROC from a Unix command line
# Replace the path in the first line with one appropriate to your machine
# Required packages: hectospec
string args1
string uprm, hm
# Set machine type appropriately
set ( arch="." // envget("IRAFARCH") )
# Removed embedded tabs from following line - jec 06.02.2008
set min_lenuserarea = 200000
# Set the terminal type.
if (envget("TERM") == "sun") {
stty gterm
} else if (envget("TERM") == "xterm") {
stty xterm
} else if (envget("TERM") == "network") {
stty vt100
} else {
stty xterm
}
if (defvar("UPARM")) {
uprm = envget("UPARM")
i = strlen(uprm)
if (substr(uprm, i, i) == "/")
set (uparm = uprm)
else
set (uparm = uprm // "/")
}
else {
printf("callimages %s: UPARM not defined?\n", args)
logout
}
# Set the user name which may appear on graphical output
set user = envget("USER")
wcstools motd=no
rvsao motd=no
hectospec verbose=yes
# Execute the task
printf ("%s\n", args) | cl()
logout
When I attempt to execute this script from the command line, even with the final printf command (which passes the actual command to cl) commented out, I get the following error:
PANIC in `/scisoft//all/packages/iraf/iraf/bin.macintel/x_system.e': fatal error during process shutdown
I can execute commands within IRAF with no issue, but this script is crashing. Anyone have any idea what might have changed in ecl between versions 2.12.2 and 2.14? I would suspect the call to cl(), but commenting out that line results in the same error.
Mike Fitzpatrick wrote on Jun 02, 2008
You need to remove the 'stty' commands from the script, or else use 'cl.e' instead of 'ecl.e' as the interpreter.
-Mike
-Mike
JCab wrote on Jun 02, 2008
I get almost the same error, wording is:
PANIC in `/scisoft/all/packages/iraf/irafbin/bin.macintel/ecl.e': segmentation violation
I realized this started occurring when I moved from PowerMac G5 (and PPC version of IRAF, which I think was version 2.12.2) to Intel.
I'll check into removing those stty lines, but I will note this script ran just find with IRAF 2.12.2 on my PPC.
PANIC in `/scisoft/all/packages/iraf/irafbin/bin.macintel/ecl.e': segmentation violation
I realized this started occurring when I moved from PowerMac G5 (and PPC version of IRAF, which I think was version 2.12.2) to Intel.
I'll check into removing those stty lines, but I will note this script ran just find with IRAF 2.12.2 on my PPC.
Mike Fitzpatrick wrote on Jun 02, 2008
I'll check into removing those stty lines, but I will note this script ran just find with IRAF 2.12.2 on my PPC.
Right, v2.12 use 'cl.e' as the default, in v2.14 it is the ecl.e being used and the thing not happy with the stty commands in host scripts.
-Mike
JCab wrote on Jun 02, 2008
fitz
Right, v2.12 use 'cl.e' as the default, in v2.14 it is the ecl.e being used and the thing not happy with the stty commands in host scripts.
But the script _explicitly_ called ecl.e, that part of the script was not changed! I understand the default environment (ecl versus cl) is different, but was 'ecl.e' being routed to 'cl.e' without my knowing it in IRAF 2.12.2?
BTW, it looks like removing the stty lines did the trick, although I will reserve judgement because I am now getting an error that at least _looks_ different. :roll:
Last post on Jun 02, 2008