🚀 go-pugleaf

The function call-process in GNU emacs does not return any information about
the success or failure of the called process. In a strict sense this is not a
bug because it was never implemented that way. But I feel that it is a serious
definiency for authors of elisp code who want to interact with the system, one
should be able to determine if the command succeeded or not. Currently
call-process always returns nil. Instead it should return the exit status of
the process. Since call-process has always returned nil it seems that
returning an integer should be backwards compatible with existing users of
call-process.

It is possible to set up an asynchronous process, loop till it exits, and then
get its exit status. However this approach seems very expensive and wasteful,
one should really have emacs suspend until the child process exits. The logic
for accomplishing this is already in place in the file callproc.c, it just
needs to be modified a bit to return the exit status.

I did attempt to modify the code to accomplish this, but I ran into a problem.
This is what I did.

In sysdep.c I modified the routine wait_for_termination to return the exit
status as reported by the wait or wait3 call. In callproc.c I save the return
value from wait_for_termination and then have Fcall_process
return(make_number(return_value)). Simple right?

Wrong. The problem I ran into was that the child_sig signal handler in
process.c would get invoked first, it would call wait3, scan the process list
for the process id, but it would not find it because it was the synchronous
process and not one of the asynchronous processes. Because the signal handler
did not find it in the process list it just exits. Then back in the routine
wait_for_termination any call to wait or wait3 fails because wait3 has already
been called on the synchronous process id in the signal handler and there is
no wait information to return.

Now I suspose it is possible to set up some global variables that
wait_for_termination and child_sig can use to communication about the state of
the synchronous process. But this seems ugly. Looks like someone already set
up a global variable for the sychronous process id (synch_process_pid) when
compiling in the BSD4_1 environment. But this variable alone is not sufficient
to enable child_sig and wait_for_termination to cooperate.

I wonder if the more elegant (and more correct??) solution would be to install
a special permanent synchronous process in the process list. This process
could never be removed from the process list. It may or may not be running. By
definition it could never show up as an active process in the process list
since emacs could not be running to processs the active process list if the
synchronous process was running. It could be given a special name like
"synchronous-process" then any elisp code that wants to check the return
status can just call (process-exit-status (get-process
"synchronous-process")). Maybe synchronous-process should be a predefined
symbol. One of the nice results of this is that there is no interference with
the child_sig handler, it would find the sychronous process in the process
list and log the information on it. It provides a richer set of operations
that can be used on the synchronous process and capitalizes on existing code.
However, I can see some down sides to this approach as well. Its a little
strange to have 'special hidden objects' and most of the functionality of
asynchronous processes will still not be available precisely because emacs
cannot be running at the same time. 

There is one other feature of processes that limits their usefullness. Both
the standard out and standard error are merged into one output stream from the
process. It would be very useful to keep them separate. When parsing the
output of a process it can be very helpful to know what is normal output and
what is error reporting. Some process output is very obvious about the
distinction, but some is not. Adding an extra parameter to start-process and
call-process like the output buffer parameter, but for standard error would
seem the route to go. Unfortunately I can't think of a way to add a new
parameter to these routines that would not break existing code so maybe two
new routines could be added.

I have no idea of what the ramifications are for non Unix systems such as VMS
on these proposals. I suspose that if a system does not have exit status
information nil could be returned and if a system does not have a separate
error output stream a fall back would be to leave it merged with the standard
output stream. Any feed back on these ideas?

John Dennis
E     Mail: johnd@Stardent.COM | {uunet,convex,decvax}!stardent!johnd
Snail Mail: Stardent Computer, 55 Wells Avenue Newton, MA 02159
Voice Mail: <Work>(617) 964-6228 x243 <Home>(508)366-7976