Re: Using open-input-output-pipe

[Edwin Watkeys]

Hi all,

Thanks for all the input. Here a simple implementation that I've come up
with; I'm not sure it's bullet-proof. This scenario is so common—using
open-input-output-port on a Unix filter—that I would argue that the rw-port
design is broken; there really should be a way to close the input and
output independently. I checked back on the mailing list to the genesis of
this feature, and there didn't seem to be a lot of discussion of the
design. Something that's analogous to open-process, which returns multiple
values, or a hypothetical (call-with-port-input-output ARGS (lambda (in
out) ...)) would seem to be better. I'm going to try out these ideas when I
get a bit of spare time.

(define (generate-digest str)
  (call-with-values
      (lambda () (open-process OPEN_BOTH "shasum" "-a" "256"))
    (lambda (read-port write-port pid)
      (write str write-port)
      (close-port write-port)
      (let ((line (read-line read-port)))
(close-port read-port)
(car (string-split line #\space))))))

Regards,
Edwin

On Mon, Jan 22, 2018 at 6:00 AM, Chris Vine <address@hidden> wrote:

> > On 01/21/2018 12:31 PM, Edwin Watkeys wrote:
> >
> > > Hi all,
> > >
> > > I'm trying to write a procedure that processes some input through a
> > > unix utility. Open-input-output-pipe returns a bidirectional pipe
> > > that I can both read and write to. However, there is no way that I
> > > can figure out to tell the external process that input is complete,
> > > as there is no way to determine the output port of the rw-port and
> > > therefore no way to close it. Closing an rw-port closes both the
> > > read and write ports.
> > >
> > > Open-input-output-port therefore seems useful for line-based
> > > external processes but not for ones that function on the entirety
> > > of user input e.g. wc and sort.
> > >
> > > Is my analysis of the situation roughly accurate?
> > >
> > > Regards,
> > > Edwin
>
> If you want fine-grained control, you might want to look at some of the
> procedures in guile-lib's (os process) module, and in particular the
> 'run-with-pipe' procedure, or using its 'run-concurrently+' procedure
> with guile's 'pipe' (the parent can block on its read pipe once it has
> completed writing to the child until the child process closes the other
> end of the pipe upon finishing, causing the parent to get an eof-object
> provided it has itself previously closed the write end of its read
> pipe).
>
> Otherwise if you want to stick to guile proper, you may have to do it by
> hand.  As 'pipe' gives you an input and output port for each pipe which
> can be independently closed, you could use two of these with the
> 'dup2', 'fork' and 'execl' procedures.  It's tedious though.
>
> Chris
>
>


-- 
Edwin Watkeys; phone: 917-324-2435.