[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Plumbing
In response to my suggestion of a multipipe primitive for es,
Steve Kilbane wrote:
> > It would be useful to be able to distinguish between
> > the two kinds of output; but you don't just want to send them
> > to different places, because you want to keep the two
> > synchronised.
>
> Bzzt! You're onto something of a loser here already, because
> once the output from the fds enters the realm of pipes, you're
> into buffering issues, and you lose the synchronisation.
*click* You're absolutely right, of course. On the other hand,
you keep *some* synchronisation (i.e., two bits of output emitted
at the same time are likely to arrive at about the same time);
it might or might not be enough for practical purposes. I'm not
very clued up on the implementation details; would someone more
expert than I am like to comment here?
and also:
> If you really want to go with this, I'd suggest dropping elegance and
> going for practicality. Perl's IPC::Open3 module will give the
> functionality you require, and Perl is always great for those one-off
> jobs that aren't worth breaking out the C compiler for...
That sounds like a good idea. I hadn't known about Open3, but it
looks like it will do what I want without too much pain. Thanks!
Paul Haahr, on the other hand, wrote in response to my suggestion
for the syntax of the extended %pipe this would require:
> > %pipe {make universe} '1 2' '0 3' {process_output}
...
> (Er, ugh.) If I were to do such a thing, I'd probably change the pipe
> primitive to take a list of output-on-left/input-on-right fd pairs,
> either counted or explicitly delimited, something like
>
> make universe |[1=0,2=3] process_output | grep errors
>
> turning into
>
> %pipe {make universe} 1 0 2 3 . {process_output} 1 0 . {grep errors}
The reason for my proposed syntax was that it would be backward-compatible
with the existing %pipe syntax. Isn't this relevant?
> But if we did this, then people would start to want things like circular
> pipes, just for the sake of completeness, and the notations get really
> absurd.
Well, you don't have to follow every idea to its illogical conclusion :-)
> Not crazy. It's just that the number of times it actually would be used
> is probably pretty rare.
I would use it every time I do a "make". (Following the suggestion
of Perl5's Open3 module, I'll probably actually use that instead.)
> Is there any chance of a future release of es seeing the light of day?
;-)
> If you implement it, release it as a patch and see if other es users
> find it useful.
Given that Perl will do the plumbing I need, I'll probably just use
that. But if anyone else on this list thinks the multipipe hack
would be useful, I might do it after all.
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
gjm11@dpmms.cam.ac.uk Cambridge University, England.