[plt-scheme] Trouble with IO ports

On Feb  8, Michel S. wrote:
> Using PLT 4.1.4 (the Fedora 9/i386 from plt-scheme.org), when
> creating a process, the input port appears to never contain
> anything.
> 
> Example:
> 
> (require scheme/system)
> > (require scheme/system)
> > (define p (process "bash"))
> > (define ip (car p))
> > (define op (cadr p))
> > (char-ready? ip)
> #f

Why did you expect something to be available at this point?  (If you
try to run bash manually from a redirected port instead of a terminal,
it doesn't print any prompt.)


> > (fprintf (cadr p) "ls /")
> > (flush-output)
> > (char-ready? ip)
> #f

You're missing a newline -- otherwise, bash is still just waiting for
your input.


> On Windows, the problem appears to be worse -- in Unix, this works:
> > (fprintf (cadr p) "echo foo > foo.txt")
> > (flush-output)
> 
> whereas in Windows (using cmd instead of bash), nothing is written.

I'd be surprised if Windows' cmd.exe behaves differently in this
respect.


> On the other hand, on Windows, the input port initially contains some
> data, and the following code will retrieve the data without any
> problem: [...]

I can't see the whole picture (partly because you only included a
random piece), but in general you have plenty of input functions that
can deal very well with things like reading the available part of an
input port.  But if you plan to be interacting with an interactive
command (like bash or python), then it is not a good idea to work in a
simple mode where you throw some characters in and then wait for the
output to come.  It is much better to set up thread to do some of this
work too.

And BTW -- it is also not a good idea if you expect the response text
to be a reply for the input text.  This is true for any language that
can spit out text asynchronously.


> I'm writing an interface from Scheme to Python, using process pipes to
> communicate between the two, so bidirectional communication is rather
> important. Any idea why this bizarre behavior occurs?
> 
> (on Chez Scheme, in Unix -- Linux and OS X -- everything works;

I doubt it -- it's more likely that you have different code for Chez
and you didn't forget the newline there.


> on Windows, the output works but the input is even more dangerous --
> char- ready? will erroneously return #t but the interpreter enters
> an infinite loop when (read-char ip) is attempted.

In general, `char-ready?' and `read-char' are poor choices to build
this functionality on.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!