iraf.net

So, someone contacted me recently getting the old [code:1:d7cde1a375]cannot open connected subprocess (mscdisplay$x_mscdisplay.e)[/code:1:d7cde1a375]error, relating to running mscred on MacOS X intel. So, i went through the standard problems, missing binaries, wrong (ppc) binaries, etc., but nothing seemed to make sense so I went looking at the mscred.cl file that holds on the definitions for the packgaes and tasks and now I'm [i:d7cde1a375]really[/i:d7cde1a375] confused.Because, it looks like tasks, even on my working mscred installation, point to non-existent files and yet still work.for example, let's look at mscdisplay, from the mscred.cl file:[code:1:d7cde1a375]set mscdisplay = "mscsrc$mscdisplay/"
task mscdisplay,
mscrtdisplay = mscdisplay$x_mscdisplay.e
[/code:1:d7cde1a375]So ,that to me makes it look like it's going to look for the task mscdisplay at mscsrc$mscdisplay/x_mscdisplay.e.But, that directory has no .e files in it. It's the src directory, all the binaries are in bin.macintel in mscred$. Yet, on my machine, all mscred tasks work just fine, where as to my diagnostic eye, they should not.So, what sort of odd voodoo is going on here? What am I missing?

---

The re-born Mac IRAF web site: http://macsingularity.org

The 'task' statement is a but subtle: The command on the right is used both to define the task to be executed as well as the location of the parameter file (e.g. 'mscdisplay$' in this case). External packages use another mechanism to locate the bin directory and if it's not there will ultimately fallback to the location actually specified by the task statement before issuing the cryptic 'cannot open connected subprocess' message with that path.So, if you see the message the binary isn't being found where it's supposed to be. Look for the following:1) Invalid definitions the package (mscred$) in the hlib$extern.pkg file (usually a trailing '/' is missing but results in a 'param not found' message).
2) An invalid architecture. e.g. a "cl> show arch" command should return ".macintel" (note the dot!) for this system. If it still says 'macosx' there may be an old file somewhere
3) Check the permissions on the binaries as well as all directories leading up to it.You can use Spotlight or the 'locate' command to find the actual x_mscdisplay.e file on the machine . Note that when building from source the most common mistake is to not reset the package architecture and so binaries end up in the 'bin.generic' package directory (which should always be empty!).Cheers,
-Mike

Yes, the problem turned out to be that the user had installed PowerPC IRAF on an Intel Mac system, and then installed Intel external packages. My guess is this made the IRAFARCH macosx and hten it wasn't looking for the macintel binaries.

---

The re-born Mac IRAF web site: http://macsingularity.org