[Apologies, if this hit the list twice.]
There seems to be some SLIME interaction between SBCL's SB-EXT:RUN-PROGRAM and *STANDARD-OUTPUT*. Consider this:
(defun test (stream) (let* ((p (sb-ext:run-program "tr" '("a-z" "n-za-m") :input :stream :output stream :search t :wait nil)) (in (sb-ext:process-input p))) (format in "test~%") (sb-ext:process-close p) (sb-ext:process-wait p)))
Executing (TEST T) causes the output go to emacs' *inferior-lisp* buffer, with (TEST *STANDARD-OUTPUT*) it goes to SLIME's REPL buffer, although they should behave the same, AFAICT.
GNU Emacs 21.3.50.1 SLIME CVS-2004/08/13 SBCL 0.8.13
(I understand that this could just as well be an SBCL issue.)
Now, why this function hangs after executing is another thing which I haven't figured out yet, but this is likely due to wrong use...
Cheers, Michael
Michael Weber michaelw+slime@foldr.org writes:
Executing (TEST T) causes the output go to emacs' *inferior-lisp* buffer, with (TEST *STANDARD-OUTPUT*) it goes to SLIME's REPL buffer, although they should behave the same, AFAICT.
I think T and *STANDARD-OUTPUT* are different in this case. The docstring says:
:OUTPUT Either T, NIL, a pathname, a stream, or :STREAM. If T, the standard output for the current process is inherited. ... If a stream, all the output from the process is written to this stream. ...
The "standard output" is probably the file descriptor 1. At least
(with-output-to-string (*standard-output*) (sb-ext:run-program "/bin/ls" '() :output t))
which just returns "", seems to confirm this.
Helmut.
-
Helmut Eller -
Michael Weber