<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. ***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. ***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
<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 ***d4ryus2 is now known as d4ryus
<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>so when you want to capture the stdout of a process, you instead have to use 'open-pipe*' & co. <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? <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! <apteryx>leoprikler: meaning, it's not possible? <apteryx>If that's the best way to do it, yes! <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 <apteryx>Thanks for sharing this :-) It makes sense! <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>"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>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