🚀 go-pugleaf

	There is a bug in process-exit-status.  I will start off with
an explanation of the symptoms I have seen, and then follow with a
possible fix that appears to work for me.

Symptoms:
	The bug that I am getting is that process-exit-status returns
zero regardless of the actual exit status of the program.  For
example, if I interactively do the following:
-----------
(defvar test-process nil)
(setq test-process (start-process "xmenu" nil "xmenu" "-heading" "Test"
			"test1" "test2))
;; Wait until xmenu is finished
(process-exit-status test-process)
-----------
	I get 0, even though the program xmenu actually returns 101.
I am using both emacs version 18.55.7 and epoch 3.2 on a Sparcstation
1 with SunOS version 4.0.3c.  HAVE_PTYS is defined in my compilation.
	I have also tried various hacks using a process sentinel and
have not had any luck.

Fix?:
	I've done some digging into the source code, and it appears
that the cause of the problem is at the end of
wait_reading_process_input (process.c).  The following lines can be
found there:
-----------
/*
 * With ptys: when the parent process of a pty exits we are notified,
 * just as we would be with any of our other children.  After the process
 * exits, select() will indicate that we can read the channel.  When we
 * do this, read() returns 0.  Upon receiving this, we close the channel.
 *
 * For external channels, when the peer closes the connection, select()
 * will indicate that we can read the channel.  When we do this, read()
 * returns -1 with errno = ECONNRESET.  Since we never get notified of
 * this via wait3(), we must explictly mark the process as having exited.
 */
		  if ((XFASTINT (XPROCESS (proc)->flags) & PROC_STATUS)
		      == RUNNING)
		    {
		      XFASTINT (XPROCESS (proc)->flags) = EXITED | CHANGED;
		      XFASTINT (XPROCESS (proc)->reason) = 0;
		    }
-----------
	I have put debugging lines in the code, and determined that
the exit code is being set properly to 101, but it later gets stomped
on in this function.  At least in my situation, it appears that simply
removing the last line solves the problem, but, of course, this may
cause other problems of which I am not aware.

		Gill Derge
		derge@crd.ge.com