Thank's to everyone who pointed out that stdout and stderr are not synchronized, as I confirmed with a simple test program: #include <stdio.h> #include <stdlib.h> int main(void) { int i; for (i = 0; i < 50000; i++) fprintf(((rand()&1) ? stdout : stderr), "<--%d-->\n", i); return 0; } Malcolm> Malcolm> Greg Klanderman wrote: Malcolm> Malcolm> Why do you need to redirect the output, rather than just slurping it Malcolm> into an XEmacs buffer and processing it there, either from the Malcolm> process-filter or process-sentinel? Yes, that's what I would actually do. Malcolm> Redirection is pretty broken on Malcolm> Windows systems, so you might find this less robust than you hope. Malcolm> Since the cvs messages themselves are always sensible (ie they don't Malcolm> appear intermingled) it would also seem to me that this would remove the Malcolm> worries about synchronisation. Unless someone has seen cvs produce Malcolm> garbled output on a terminal :-) Well, after some sleuthing, it seems that CVS goes to some trouble to keep its stdout and stderr synchronized. So I am proceeding with the change to pcl-cvs I suggested and have M-x cvs-status working correctly even recursing down subdirectories. If this weren't the case, we'd have problems. On unix you can bind process-connection-type to t around the call to start-process to have it to use a pty, which appears to cause stdout to get put in line-buffered mode. NT does not appear to use this variable, and so I can only assume this would not have been a workable solution. Running (let ((process-connection-type nil)) (start-process "test" "*test*" "/path/to/my/test/program")) should demonstrate the output being garbled. greg