[plt-scheme] Re: Trouble with IO ports

On Feb 8, 5:24 pm, Eli Barzilay <e... at barzilay.org> wrote:
> 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.
Turns out to be a trivial error -- I was printing the first expected
input on stderr, and on Chez, stdout/stderr is redirected to a single
input port. My real code has the newlines, yes, so Robby and yourself
are correct on that point. Also, it looks like Chez more aggressively
flushes output ports; so flushing after every write on the Scheme side
(as well as on the sending side) helps.

> 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 aware of this; when working on the REPL, enough time normally has
lapsed that I don't include the actual input-parsing code in my
original question. After sending a command, I'd wait for the next
available input, then keep reading until there has been no input for x
seconds.

> I doubt it -- it's more likely that you have different code for Chez
> and you didn't forget the newline there.
>
The Chez bug still remains, alas (on Windows). Oh well, I'll bug the
relevant people about that.

> > 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.
Unfortunately that seems the lowest common denominator. copy-port
appears to be PLT-specific. Any suggestion?

Thanks,

--
Michel