Thread overview
Write to stdin, read from stdout of a spawn command (a library)
Jan 23, 2019
Victor Porton
Jan 23, 2019
Victor Porton
Jan 24, 2019
Jon Degenhardt
Jan 24, 2019
Kagamin
January 23, 2019
I want to write to stdin and read from stdout of an OS command I spawn without deadlocks. (I have a string to write to stdin and want to read its stdout as a string.)

Is there a ready D library for this?

I wrote a C library for this and consider to port to D (either as bindings or as a rewrite):

https://github.com/vporton/libcomcom
January 23, 2019
On Wednesday, 23 January 2019 at 22:51:45 UTC, Victor Porton wrote:
> I want to write to stdin and read from stdout of an OS command I spawn without deadlocks. (I have a string to write to stdin and want to read its stdout as a string.)
>
> Is there a ready D library for this?
>
> I wrote a C library for this and consider to port to D (either as bindings or as a rewrite):
>
> https://github.com/vporton/libcomcom

By the way, is it worth to rewrite this using fibers?

Fibers have the advantage that it becomes possible to run several spawn commands simultaneously. However, I suspect that usage of fibers may make the code even less efficient than the current approach which passes input and output as one string write/read operation, without any split of data into several I/O operations.

What do you think?
January 24, 2019
On Wednesday, 23 January 2019 at 23:23:47 UTC, Victor Porton wrote:
> On Wednesday, 23 January 2019 at 22:51:45 UTC, Victor Porton wrote:
>> I want to write to stdin and read from stdout of an OS command I spawn without deadlocks. (I have a string to write to stdin and want to read its stdout as a string.)
>>
>> Is there a ready D library for this?
>>
>> I wrote a C library for this and consider to port to D (either as bindings or as a rewrite):
>>
>> https://github.com/vporton/libcomcom
>
> By the way, is it worth to rewrite this using fibers?
>
> Fibers have the advantage that it becomes possible to run several spawn commands simultaneously. However, I suspect that usage of fibers may make the code even less efficient than the current approach which passes input and output as one string write/read operation, without any split of data into several I/O operations.
>
> What do you think?

You've probably looked at std.process (https://dlang.org/phobos/std_process.html), but in case not, take a look, it may contain the building blocks you need.

--Jon
January 24, 2019
See also http://libpipeline.nongnu.org/