IRC channel logs

2021-10-28.log

back to list of logs

<dadinn>hi all
<lampilelo>hello
<dadinn>I am trying to figure out how to start a process with `system` and pass it some data on standard input, is there an example for this somewhere?
<dadinn>i've tried to do (with-output-to-port (popen:open-pipe* OPEN_WRITE "grep" "[a-z]+") (display "foobar") (display "12345")) but i am getting an error saying "Wrong type to apply #<unspecified>"
<dadinn>hmm, that is possibly missing a few (newline) calls too, as grep would work on lines I suppose?
<dadinn>khm, ok I forgot the thunk too: (with-output-to-port (popen:open-pipe* OPEN_WRITE "grep" "[a-z]+") (lambda () (display "foobar") (newline) (display "12345")))
<dadinn>I don't see anything printed in the repl though... I would expect "foobar" to be printed on stdout by the grep process
<lampilelo>dadinn: you're not waiting for the subprocess to finish before exiting
<lampilelo>also you should use OPEN_READ instead of OPEN_WRITE if you want to read from it
<lampilelo>ah, sorry, you want to write to it, i guess
<lampilelo>you may want to flush the data you write to a port with force-output
<lampilelo>and call close-pipe at the end
***rgherdt_ is now known as rgherdt
<dadinn>lampilelo: I think open-output-pipe sets the stdout for the process to be the current stdout in the context by default
<dadinn>is there a call-with-output-port macro maybe, which would allow to pass the port to the body of the thunk?
<dadinn>ahh, I think I should just wrap it in a let block
<lampilelo>with-output-to-port
<dadinn>lampilelo: that only takes a no argument thunk it seems
<dadinn>and sets the current stdout to the port
<lampilelo>ah yes
<dadinn>is there a way to get the exit code of the subprocess? close-port only returns a boolean
<lampilelo>close-pipe will return the exit code
<lampilelo>and will close the pipe correctly, if you close-port on a pipe, it will be marked for gc and may linger for some time
<dadinn>lampilelo: ah I see!
<lampilelo>it can stick around long enough for your program to reach the fd limit if you're not careful
<lampilelo>yeah, found out about that the hard way
<lampilelo>the gc will run and close the fd at some point either way, but it may take some time
<ajarara>looking at ,m (ssh session), how does it export `connect!` when it doesn't define it or re-export it? Where's the definition of `connect!`?
<civodul>ajarara: hi! it's defined in C, in libguile-ssh.so
<civodul>and exported from there
<ajarara>civodul: hello, and thanks! Is that the only other way symbols not in guile source are defined in the stdlib? What joins `libguile-ssh` to (ssh session)?
<ajarara>probably wrong of me to say 'stdlib': https://github.com/artyom-poptsov/guile-ssh
<lampilelo>SCM_DEFINE creates a recipe for defining a symbol in the top level environment of the current module, (ssh session), via load-extension, loads a c function that executes these definitions
<ajarara>esp since I don't see that package as inputs to any packages in (gnu packages guile)
<civodul>ajarara: session.scm calls load-extension or similar, which invokes a C function that defines things
<ajarara>Ah I see it! Thanks all.
<dthompson>has anyone else had troubles with geiser lately? the big problem I have been having is that when I evaluate code within a module file, the code is not evaluated in the context of that module, but in the context of whatever the current module is in the geiser repl buffer.
<dthompson>I haven't been able to do repl-driven development for quite some time because of this.
<lampilelo>it worked that way before?
<dthompson>yes! it's an essential feature
<dthompson>I could switch from buffer to buffer and everything I evaluated was in the proper context.
<dthompson>now it doesn't work at all
<dthompson>seems like ever since geiser was split into multiple packages it has never worked right
<lampilelo>i didn't know about that, interesting
<dadinn>lampilelo: I've tried to get this working but it is still not ideal: (let ((output-port (popen:open-pipe* OPEN_WRITE "grep" "[a-z]+"))) (rdelim:write-line "fuckshit") (force-output output-port) (status:exit-val (popen:close-pipe output-port)))
<dadinn>oops, sorry for the language :P
<lampilelo>close-pipe will flush the port, so you can skip force-output if you're closing the pipe right away
<dadinn>I would expect it to work like "echo foobar |grep [a-z]+"
<dadinn>it actually prints out the match, but for some reason the return code is 1 :/
<dadinn>I would expect 0
<dadinn>hmm, seems like my shell wizardry needs an upgrade... that is an extended regexp with grep :P
<lampilelo>you're writing to the current output port with write-line call, not to the pipe, but i'm not sure why it returns 1
<dadinn>"echo foobar |grep -E '[a-z]+'" is 0, but without the "-E" it's 1
<lampilelo>ah, makes sense
<dadinn> (let ((output-port (popen:open-pipe* OPEN_WRITE "grep" "-E" "[a-z]+"))) (rdelim:write-line "foobar" output-port) (status:exit-val (popen:close-pipe output-port)))
<dadinn>that returns 0
<lampilelo>without -E you need to \+ instead of +
<lampilelo>i.e. "[a-z]\\+"
<dadinn>yep ;)
***robin_ is now known as robin