Hi Bryan:

>   My problem is finding a way to reliably read error output after a
>
>		    (excl::run-shell-command command
>				     :input :stream
>				     :error-output :stream
>				     :wait nil))
>
>   When the subprocess dies or exits
>   I find that a listen on the error output stream returns nil and
>   a read-line blocks forever after 1 line of error output is read.

When dealing with streams I found it best to use read-char-no-hang.
Unlike read-line, it doesn't hang when the stream is empty.
Also, you can extend it to your own read-line-no-hang.

>   I was able to get all of the output by calling (sleep 1) before checking
>   the stream, but in my application, waiting a second for this is often
>   more time than it takes to process a unit of work. I guess that some other
>   function that forces a unix context switch probably would do the trick.

I had the same problem several months ago. I also used
sleep but found it slow. What I ended up doing was coding all
of the necessary low level stream functionality in C using 
<unistd.h>, <sys/stat.h>, <sys/socket.h>, <sys/types.h>, and
<stropts.h>, putting an ACL layer on top of it, and using the 
ACL/Unix foreign function interface to load the C executables
into my running lisp image. I don't know if this is a viable 
option for you, but it worked for me very well.

>   Note that common lisp doesn't supply any interesting predicates to look
>   at the streams connected to the subprocess. There seems to be no way
>   of checking that the process attached is dead, that stuff written to the
>   input is disappearing into the bit bucket, etc.

It's true that ACL doesn't provide interesting predicates
on streams but one can define those given the functionality of
<stropts.h>. Also, ACL/Unix foreign function interface is great.

Best regards,
Val Kulyukin