MSCRED Error
Josh Walawender wrote on Nov 18, 2008
Hi,
I just installed IRAF on a Mac OS X 10.5 intel machine and though IRAF appears to work, MSCRED seems to have problems. I can load the package, but when I run a task, I get the following:
ERROR: Cannot open connected subprocess (./x_mscred.e)
It appears that the $mscred is missing from the path. How can I fix this?
thanks,
Josh
I just installed IRAF on a Mac OS X 10.5 intel machine and though IRAF appears to work, MSCRED seems to have problems. I can load the package, but when I run a task, I get the following:
ERROR: Cannot open connected subprocess (./x_mscred.e)
It appears that the $mscred is missing from the path. How can I fix this?
thanks,
Josh
Mike Fitzpatrick wrote on Nov 18, 2008
The 'cannot open connected subprocess' message usually means that either the binaries weren't installed, they were install in the wrong location, or if you built from source that the package wasn't reconfigured for the current architecture before compiling. The 'mscred' package directory should be defined normally in the hlib$extern.pkg file (be sure it has a trailing '/'). If you defined the package yourself in a login.cl or loginuser.cl file, be sure this was done before the final 'keep' statement in each file.
-Mike
-Mike
Josh Walawender wrote on Nov 18, 2008
Hi Mike,
The binary (x_mscred.e) exists and has read and execute permissions for all users. I also triple checked the hlib$extern.pkg file and it appears to be correct. Problems there were my first guess.
It seems odd to me that the task is looking for x_mscred.e in the local directory (./x_mscred.e) as opposed to mscred$x_mscred.e. Is that a concern?
thanks,
Josh
The binary (x_mscred.e) exists and has read and execute permissions for all users. I also triple checked the hlib$extern.pkg file and it appears to be correct. Problems there were my first guess.
It seems odd to me that the task is looking for x_mscred.e in the local directory (./x_mscred.e) as opposed to mscred$x_mscred.e. Is that a concern?
thanks,
Josh
Mike Fitzpatrick wrote on Nov 18, 2008
The error message is somewhat misleading since what it really means is that the binary wasn't found where the package said it would be, and it wasn't where the task declaration said it should be, so the error is printed using the path checked last. In this case, it appears your 'mscred' is set to "./" for some reason?? What does a "cl> show mscred" say? Is this by chance a SciSoft installation or did you do it yourself?
-Mike
-Mike
Josh Walawender wrote on Nov 18, 2008
Hi Mike,
This is an install from http://macsingularity.org/ not something I've done myself.
ecl> show mscred
/iraf/extern/mscred/
The x_mscred.e executable is in /iraf/extern/mscred/bin/
cheers,
Josh
This is an install from http://macsingularity.org/ not something I've done myself.
ecl> show mscred
/iraf/extern/mscred/
The x_mscred.e executable is in /iraf/extern/mscred/bin/
cheers,
Josh
Mike Fitzpatrick wrote on Nov 18, 2008
The mscred$bin is normally a link pointing to a bin.<arch> directory where the system actually looks. If your 'bin' is a real directory containing the binary that might explain it.
Otherwise, try executing the 'x_mscred.e' binary from the unix level, it may exist in the right place but might not be executable, had a missing lib dependency, etc and the host command is usually more informative.
-Mike
Otherwise, try executing the 'x_mscred.e' binary from the unix level, it may exist in the right place but might not be executable, had a missing lib dependency, etc and the host command is usually more informative.
-Mike
Josh Walawender wrote on Nov 18, 2008
Hi Mike,
I checked the bin/ and bin.macosx/ folders, both have the executable and both appear to have proper permissions. I was able to run both executables from the unix prompt.
In both cases I got a > prompts and was able to exit using 'bye'.
-Josh
I checked the bin/ and bin.macosx/ folders, both have the executable and both appear to have proper permissions. I was able to run both executables from the unix prompt.
In both cases I got a > prompts and was able to exit using 'bye'.
-Josh
Mike Fitzpatrick wrote on Nov 18, 2008
Could you turn on the 'd_trace' or 'd_on' toggles (i.e. type those commands at the CL prompt) before executing the command and post the result?
Also, just checking that you installed the source for the package even if you used prebuilt binaries? Do any other packages show similar problems?
Also, just checking that you installed the source for the package even if you used prebuilt binaries? Do any other packages show similar problems?
Josh Walawender wrote on Nov 18, 2008
Hi Mike,
This was an installer package, so I'm not sure of the source was included.
I have poked around and I've gotten a similar error out of the stsdas package, however, so far, the noao package appears unaffected.
Here is the result of d_trace:
This was an installer package, so I'm not sure of the source was included.
I have poked around and I've gotten a similar error out of the stsdas package, however, so far, the noao package appears unaffected.
Here is the result of d_trace:
mscred> d_trace
2 403+3: end
mscred> mscgetcat
----- task cl - line 2 (CALL) -----
2 395+6: call mscgetcat
2 401+3: exec
----- exec script mscgetcatalog (mscsrc$mscgetcatalog.cl) - line 2 -----
----- task mscgetcatalog - line 15 (PUSHCONST) -----
15 407+9: pushconst `tmp$iraf'
15 416+6: pushconst 1
15 422+5: intrinsic mktemp
15 427+5: assign inlist
17 432+7: call mscextensions
1: CALL mscextensions
17 439+5: pushparam input
List of Mosaic files (FGN_reg_H2.fits):
17 444+4: posargset 0
17 448+8: pushconst `file'
17 456+5: absargset output
17 461+7: pushconst `0-'
17 468+5: absargset index
17 473+7: pushconst `'
17 480+5: absargset extname
18 485+7: pushconst `'
18 492+5: absargset extver
18 497+6: pushconst no
18 503+5: absargset lindex
18 508+6: pushconst yes
18 514+5: absargset lname
18 519+6: pushconst no
18 525+5: absargset lver
18 530+7: pushconst `'
18 537+6: absargset ikparams
18 543+5: pushparam inlist
18 548+3: redir
18 551+3: exec
----- exec external task mscextensions - line 20 -----
----- connect to ./x_mscred.e -----
ERROR: Cannot open connected subprocess (./x_mscred.e)
cl_error: abort=1 trace=1 flpr=1
cl_error: code=0 do_err=1 errtype=1/1 task='mscgetcatalog'
"extver="", lindex=no, lname=yes, lver=no, ikparams="", > inlist)"
line 18: mscsrc$mscgetcatalog.cl
called as: `mscgetcatalog ()'
----- task cl - line 2 (END) -----
2 404+3: end
mscred>
Mike Fitzpatrick wrote on Nov 18, 2008
Josh,
Marcos just posted something today that said something like "update the STSDAS installer to the latest version" but I'm not sure whether he refers to the latest OSX version or the STSDAS version. In any case, the simplest thing may be to just download the src/binaries and unpack them anew. I.e. get the files
http://iraf.net/ftp/iraf/extern/mscred-src.tar.gz
http://iraf.net/ftp/iraf/extern/mscred-bin.macintel.tar.gz
Unpack each file in the /iraf/extern/mscred directory to overwrite whatever is there currently. If there's a problem with the installer, I suspect e.g. the hlib$extern.pkg is missing a final 'keep' statement or something.
-Mike
Marcos just posted something today that said something like "update the STSDAS installer to the latest version" but I'm not sure whether he refers to the latest OSX version or the STSDAS version. In any case, the simplest thing may be to just download the src/binaries and unpack them anew. I.e. get the files
http://iraf.net/ftp/iraf/extern/mscred-src.tar.gz
http://iraf.net/ftp/iraf/extern/mscred-bin.macintel.tar.gz
Unpack each file in the /iraf/extern/mscred directory to overwrite whatever is there currently. If there's a problem with the installer, I suspect e.g. the hlib$extern.pkg is missing a final 'keep' statement or something.
-Mike
Josh Walawender wrote on Nov 18, 2008
Excellent, that appears to have worked. Thanks!
-Josh
-Josh
Last post on Nov 18, 2008