Yeah I've run into this as well -- IIRC the streams were "backwards" when you were trying to communicate with a sub-process over stdio. I think we maybe did it this way to make it easier to stream outputs more like a "pipe" operation?
Its something I think we do need to address -- because its not a usable API in those cases. Your suggestion would probably work, but probably worth a look to see if the core design could be tweaked without a big breaking change...
For Studs I wrote a different version -- welcome to cherry pick if you want in the meantime:
(I've copied the code to a PasteBin because I was writing a Fantom shell - but never publicly released it.)
This Forum post on Threaded Streams was me airing thoughts and ideas specifically for this Process conundrum.
go4Sun 31 May 2020
I know someone understands what I'm saying. Thanks andy and SlimerDude.
brianWed 1 Jul 2020
Ticket promoted to #2796 and assigned to brian
Ok, I understand now.
My initial reaction is that I think that is a I/O stream API issue not a Process issue. You want to create an OutStream that automatically pipes to the Process.in stream to feed it data. Which is a generally useful feature beyond InStream.pipe.
Although the underlying Java process API is already being piped that way, so maybe its easier to expose those directly in the reversed fashion.
Either way, will take a look and propose something
go4 Thu 28 May 2020
A common task is to write something to a process and then read the output. But the input and output are auto piped in Process API.
I propose Process.outToIn and Process.inFromOut.
`
p := Process(cmd) while (true) { p.outToIn.write("hi") res := p.inFromOut.readLine echo(res) }`
brian Fri 29 May 2020
I don't follow that proposal, can you explain it more fully?
GayBigAss Sat 30 May 2020
I don't understand, too. Could you make it more clear?
go4 Sat 30 May 2020
Sorry, I don't know how to explain it.
I want java's Process.getOutputStream.
The Process.out is not getOutputStream.
andy Sun 31 May 2020
Yeah I've run into this as well -- IIRC the streams were "backwards" when you were trying to communicate with a sub-process over stdio. I think we maybe did it this way to make it easier to stream outputs more like a "pipe" operation?
Its something I think we do need to address -- because its not a usable API in those cases. Your suggestion would probably work, but probably worth a look to see if the core design could be tweaked without a big breaking change...
For Studs I wrote a different version -- welcome to cherry pick if you want in the meantime:
https://github.com/studsio/core/blob/master/src/studs/fan/util/Proc.fan
SlimerDude Sun 31 May 2020
...and here's my version of
Processthat lets you constantly stream input to the process:Process2 - https://gist.github.com/SlimerDude/blahblah
(I've copied the code to a PasteBin because I was writing a Fantom shell - but never publicly released it.)
This Forum post on Threaded Streams was me airing thoughts and ideas specifically for this Process conundrum.
go4 Sun 31 May 2020
I know someone understands what I'm saying. Thanks andy and SlimerDude.
brian Wed 1 Jul 2020
Ticket promoted to #2796 and assigned to brian
Ok, I understand now.
My initial reaction is that I think that is a I/O stream API issue not a Process issue. You want to create an OutStream that automatically pipes to the Process.in stream to feed it data. Which is a generally useful feature beyond InStream.pipe.
Although the underlying Java process API is already being piped that way, so maybe its easier to expose those directly in the reversed fashion.
Either way, will take a look and propose something