IRC channel logs


back to list of logs

<apteryx>dsmith-work: but for system, execlp, etc. "system" calls, redirecting the Guile port has no effect, so piping seems a necessity
<apteryx>for any other kind of output (output directly driven by the Guile program rather than indirectly through a shell'd process for example), a soft-port seems a hacky but working solution.
<apteryx>for more context on what I'm attempting to do: I'd like to cause every line output by an mcron job 'action' (either a procedure to be applied, a list to be eval'd or a string to be shell'd) to be annotated by the date and the job name, to make its log more comprehensible.
<apteryx>the thunked action is applied here:
***chris is now known as Guest2897
***Guest2897 is now known as chrislck
<apteryx>'format' is weird; it causes the output to be printed one "character" (as a string) at a time, at least that's what I see when using a soft port.
*apteryx zzz
***daviwil_ is now known as daviwil
<apteryx>It seems Guile does not do output redirection of children processes, when using the likes of with-output-to-string ?
***jackhill_ is now known as jackhill
<dsmith-work>Tuesday Greetings, Guilers
<vijaymarupudi>apteryx: I think I can reproduced that behavior, and yeah, seems like a bug to me, the C code for system* does seem to use the current-output-port
<vijaymarupudi>have reproduced*
<vijaymarupudi>Link to code:
<vijaymarupudi>I'm not really sure what's happening here
***d4ryus2 is now known as d4ryus
<civodul>apteryx: hi!
<civodul>redirecting stdout to a non-file port cannot work
<civodul>so indeed, as vijaymarupudi points out, the current code just redirects to /dev/null if current-output-port/current-error-port is not a file port
<civodul>the reason is that at the OS level, all you have is a bunch of file descriptors
<civodul>the Scheme i/o ports are gone
<civodul>so when you want to capture the stdout of a process, you instead have to use 'open-pipe*' & co.
<vijaymarupudi>That makes sense to me
<vijaymarupudi>Thanks, civodul
<apteryx>vijaymarupudi, civodul hey, thanks for explaining!
<apteryx>I'm slowly figuring that out, wanting to use pipe and dup2 as I found mcron was already doing for its email redirection
<apteryx>So do I understand correctly that if I dup2 an output port created in the parent process to the fdes 1 and 2 in the child, all of its output including from shell commands should go to it? Are pipes file port as the OS level?
<dsmith-work>apteryx: yes
<apteryx>OK, good! I must be getting close to something. The next step will be to have the child's piped output processed asynchronously. Pointers welcome!
<stis>Tjaba guilers!
<leoprikler>apteryx: 0xdeadbeef
<apteryx>leoprikler: meaning, it's not possible?
<vijaymarupudi>apteryx: Are you willing to roll your own event loop?
<apteryx>If that's the best way to do it, yes!
<vijaymarupudi>Guile Fibers might be useful, I haven't use it yet:
<vijaymarupudi>Otherwise, you'll need to handle a hashtable of fds -> callbacks for read actions
<vijaymarupudi>For each iteration of the event loop, you submit all the fds in the hashtable to the poll libc function
<vijaymarupudi>It returns the fds that are available to read, then you can read from them, and call the associated callback in the hashtable with the data
<vijaymarupudi>You could use existing event loops like libuv, but if you just care about process output, this might be lighter
<vijaymarupudi>(add some delimited continuations for taste)
<apteryx>Thanks for sharing this :-) It makes sense!
<vijaymarupudi>You're welcome!
<apteryx>so, I have this for now, just trying to get the child output from the parent, and I can't get it working for some reason:
<apteryx>the output from the test is empty ("") as can be seen. I'd expect the whole of format, display, etc. to be captured.
<RhodiumToad>your plumbing does not look sensible
<RhodiumToad>"Disconnect the write end of the pipe before the fork," -- how's the child supposed to inherit it if you closed it?
<RhodiumToad>unrelated, setgid isn't sufficient, you should be paying attention to the supplementary group list too
<apteryx>hmm, does the port need to be open to copy its file descriptor?
<apteryx>it seems yes
<RhodiumToad>closing the port closes the fds
<apteryx>ah, and because of the catch all I was unaware of it. nice shooting myself in the foot
<RhodiumToad>the parent process should close its copy of the write end of the pipe after the fork and before trying to read
<apteryx>that part is covered
<apteryx>now I'm back to what I was debugging before introducing the bug you spot: the port blocking on get-string-all. If I uncomment that line, block goes away:
<RhodiumToad>then the close didn't close what it was supposed to
<RhodiumToad>check what fds are open in the parent
<apteryx>OK! thanks