Communicating with a subprocess created with os/spawn via stdin/stdout

[ammojamo]

Hi, Janet newbie here.

Just trying to work out how to interact with a subprocess.

As a toy example, I figure I should be able to spawn cat, write a string to its standard input and read it back again from its standard output.

My attempt:

repl:20:> (def p (os/spawn ["cat"] :p {:in :pipe :out :pipe}))
<core/process 0x7F8E20B06FE0>
repl:21:> cat: stdin: Resource temporarily unavailable

repl:22:> (:write (p :in) "hello world")
error: stream hup
  in ev/write [src/core/ev.c] on line 2716
  in _thunk [repl] (tailcall) on line 22, column 1
repl:24:> (:read (p :out) :all)
nil

I suppose the problem is there at the beginning with cat: stdin: Resource temporarily unavailable.

Where am I going wrong?

My Janet version is Janet 1.17.1-meson macos/x64

Thanks

[llmII]

Looking at the test suite for an example, perhaps instead of :p it should be :px?

os/spawn example with in/out

[sogaiu]

Unfortunately, I get the same:

$ janet
Janet 1.18.0-f0da793f linux/x64 - '(doc)' for help
repl:1:> (def p (os/spawn ["cat"] :px {:in :pipe :out :pipe}))
<core/process 0x562F90D50660>
repl:2:> cat: -: Resource temporarily unavailable

This is on a Linux box.

[sogaiu]

Possibly relevant: https://unix.stackexchange.com/questions/613117/cat-resource-temporarily-unavailable

[llmII]

Changing ["cat"] to ["cat" "-"] didn't make a difference either...

[llmII]

I think cat won't work...

From stackexchange:

That is turning the non-blocking mode back off (to normal). Since cat is designed to read in blocking mode, it will exit with an error when reading from stdin fails with an EAGAIN error. Now the problem is to determine which program you have run has messed up your terminal ;-)

Janet's pipes are non-blocking, but cat wants blocking IO.

[sogaiu]

On a related note, I've been trying out:

(def is (os/open "/dev/stdin" :r))

I wonder if there is a way to get that to work on non-Linux...

[llmII]

Works on FreeBSD (probably other BSD's, maybe Mac), I can see the obvious fail point, Windows... can't imagine a way to make it work under Windows.

[sogaiu]

Thanks, that seems to be echoed here.

[llmII]

Oddly enough, I wonder how often one would encounter programs that expect blocking read/write on stdin/stdout/stderr, and if such should be something that's supported.

[ammojamo]

Thanks @llmll and @sogaiu for your input on this.

My actual use case was to run a couple of queries against MySQL database. Rather than setting up bindings to the MySQL client library, I thought it would be easier to just pipe in a query to the mysql command and parse the output.

If there is no way to pipe data directly to/from the subprocess, I can probably get away with using temporary files to store input and output and invoke mysql via the shell: mysql < in.tmp > out.tmp.

Oddly enough, I wonder how often one would encounter programs that expect blocking read/write on stdin/stdout/stderr, and if such should be something that's supported.

If this is something that is wanted, I'd be interested in helping out .. I have experience with C, new to Janet.

[sogaiu]

os/spawn does work with some things, e.g. I've used it with universal ctags.

May be it's worth trying with the mysql binary?

[sogaiu]

Ah, I forgot, there is also os/execute:

$ janet
Janet 1.18.0-f0da793f linux/x64 - '(doc)' for help
repl:1:> (spit "fun.txt" "hello")
nil
repl:2:> (def if (file/open "fun.txt" :r))
<core/file 0x5609D4CCB9F0>
repl:3:> (def of (file/open "out.txt" :w))
<core/file 0x5609D4CCC600>
repl:4:> (os/execute ["cat"] :p {:in if :out of})
0
repl:5:> (slurp "out.txt")
@"hello"

So depending on what you want to do precisely, may be that could work?

[ammojamo]

May be it's worth trying with the mysql binary?

os/spawn doesn't work with mysql - that's actually what I first attempted before playing around with cat

Ah, I forgot, there is also os/execute:
...
So depending on what you want to do precisely, may be that could work?

Yes that does the trick, good enough for my purposes for now - thanks!

[bakpakin]

Ok, this looks like a bug, and I have fixed it in 0774e79.

I will create a bug to reference this discussion for tracking purposes.