🚀 go-pugleaf

In GNU Emacs 18.57.12 of Wed Jul 10 1991 on beast (berkeley-unix)

Here is the process-status code in our copy of 18.57 (which we obtained
by way of Franz, incorporated):

    DEFUN ("process-status", Fprocess_status, Sprocess_status, 1, 1, 0,
      "Return the status of PROCESS: a symbol, one of these:\n\
    run  -- for a process that is running.\n\
    stop -- for a process stopped but continuable.\n\
    exit -- for a process that has exited.\n\
    signal -- for a process that has got a fatal signal.\n\
    open -- for a network stream connection that is open.\n\
    closed -- for a network stream connection that is closed.\n\
    nil -- if arg is a process name and no such process exists.")
    /* command -- for a command channel opened to Emacs by another process.\n\
       external -- for an i/o channel opened to Emacs by another process.\n\  */
      (proc)
	 register Lisp_Object proc;
    {
      register struct Lisp_Process *p;
      proc = Fget_process (proc);
      if (NULL (proc))
	return proc;
      p = XPROCESS (proc);
      if (!NULL (p->raw_status_low))
	update_status (p);
      if (XTYPE (p->status) == Lisp_Cons)
	return XCONS (p->status)->car;
    /*
     * This code added by Franz causes cmushells, shells, ispell, and
     *  other subprocesses to feign death:
     * (code tests something like (member (process-status p) '(run ...)))
     *
     *  if (!NULL (p->childp))
     *   {
     *     if (EQ (p->status, Qrun))
     *	return Qopen;
     *      if (EQ (p->status, Qexit))
     *	return Qclosed;
     *    } 
     */
      return p->status;
    }

I also note that there is a definition in process.c:


    /* a process object is a network connection when its childp field is neither
       Qt nor Qnil but is instead a string (name of foreign host we
       are connected to + name of port we are connected to) */

    #ifdef HAVE_SOCKETS
    #define NETCONN_P(p) (XGCTYPE (XPROCESS (p)->childp) == Lisp_String)
    #else
    #define NETCONN_P(p) 0
    #endif /* HAVE_SOCKETS */


Which list-processes uses to determine whether or not a process is a network
connection.  This evidently works, because list-processes reports:

    Proc         Status   Buffer         Command
    ----         ------   ------         -------
    lisp-backdoor run     (none)	     (network stream connection to beast)
    lisp-evalserver	run   (none)	     (network stream connection to beast)
    *tcp-common-lisp*<1> run *tcp-common-lisp* (network stream connection to beast)
    nntpd	     run       *nntpd*	     (network stream connection to icad)

although status shows "run" instead of "open", as list_processes_1 doesn't bother to 
differentiate.

Kevin: I *think* the fix to process-status *should* look like: (I haven't tried this
but it should work based on list-process' behavior)

    DEFUN ("process-status", Fprocess_status, Sprocess_status, 1, 1, 0,
      "Return the status of PROCESS: a symbol, one of these:\n\
    run  -- for a process that is running.\n\
    stop -- for a process stopped but continuable.\n\
    exit -- for a process that has exited.\n\
    signal -- for a process that has got a fatal signal.\n\
    open -- for a network stream connection that is open.\n\
    closed -- for a network stream connection that is closed.\n\
    nil -- if arg is a process name and no such process exists.")
    /* command -- for a command channel opened to Emacs by another process.\n\
       external -- for an i/o channel opened to Emacs by another process.\n\  */
      (proc)
	 register Lisp_Object proc;
    {
      register struct Lisp_Process *p;
      proc = Fget_process (proc);
      if (NULL (proc))
	return proc;
      p = XPROCESS (proc);
      if (!NULL (p->raw_status_low))
	update_status (p);
      if (XTYPE (p->status) == Lisp_Cons)
	return XCONS (p->status)->car;

#ifdef HAVE_SOCKETS

      if (NETCONN_P(proc))
        {
          if (EQ (p->status, Qrun))
     	return Qopen;
           if (EQ (p->status, Qexit))
     	return Qclosed;
      } 

#endif /* HAVE_SOCKETS */

      return p->status;
    }


list_processes_1 should also be patched analogously.


  --nick caruso
    icad inc, 201 broadway			   
    peoples republic of cambridge, MA 02139-1901	   
    internet: nick@icad.com / UUCP: ...uunet!icad.com!nick	   
    ------------------------------------------------------
   "Uh-oh- looks like we've got another schizoid embolism!"