<davexunit>does anyone know how I would fork a child process and "send" stdin to it <davexunit>I'm writing a utility that spawns a certain type of process on behalf of the user, and that process may be interactive <davexunit>I understand that there's 2 things to be concerned with: stdin and a tty <mark_weaver>(1) will the child process stay in guile, or will you exec a different program? <mark_weaver>(2) do you just want the child to inherit stdin/stdout/stderr from the parent, or do you want the parent to be able to communicate with the child's stdin/stdout/stderr via pipes or something? <mark_weaver>does stdin/stdout/stderr in the child need to be a tty, or would pipes be sufficient? <davexunit>to start with, I can just use a pipe. the end goal is to be able to handle something like bash. <davexunit>this is for my ongoing container project with guix <davexunit>if I can just pipe stdin that would be a good enough start <davexunit>from what I've read so far, I think I might need to use dup or dup2 <mark_weaver>well, I'm a bit rusty on this, but will try: with pipes, generally how this is done is to create a pipe in the parent, fork, and then in the child to close the existing stdin/stdout/stderr (0/1/2) fds and use some variant of 'dup' to duplicate the FDs inherited from the parent into the 0/1/2 FDs. <mark_weaver>also, the parent should close the ends of the pipes that the child will use. <mark_weaver>and the child will close the ends of the pipes that the parent use. <mark_weaver>when you move to ttys, then see section 17.8.2 of the GNU libc manual (Opening a Pseudo-Terminal Pair). <mark_weaver>I haven't done that before, but it seems to be not entirely unlike dealing with pipes. <mark_weaver>also, when you graduate to ttys, you'll probably want to use setsid() and start thinking about process groups and the controlling terminal. see chapter 28 of the GNU libc manual (Job Control) <mark_weaver>also, in the child, after calling 'dup2', you should close the original FDs. <mark_weaver>if you want to launch an interactive shell, I don't think pipes will cut it. you'll need to create a pseudo-terminal, I think. <zacts>we need to speak with listhps ***michel_mno_afk is now known as michel_mno
<lloda>mark_weaver, I don't think the points at infinity are the same issue. <lloda>For me, the question is whether the sign of the (real!) nan is meaningful and should influence the result of log, to the point that (log real) becomes complex. Not a problem with regular Scheme numbers, nan+iπ is still a nan. But a complex nan doesn't fit in a typed real array, so I think it's worthwhile to avoid the extension to complex in this case. <lloda>You can't generally rely on the sign of the nan for anything. The C library prints +nan and -nan differently, but +inf/+inf gives -nan (!). <lloda>Guile only prints +nan.0, even though the reader accepts -nan.0, and (log -nan.0) => +nan.0, so that sign is ignored, but when I produce an actual -nan using a bytevector and check the sign with log, I get these: (/ ±inf ±inf) => +nan, but (/ ±nan ±nan) => nan with the sign of the dividend (!!). <lloda>The doc for clog in the C library says that 'If z is NaN+yi (for any finite y), the result is NaN+NaNi and FE_INVALID may be raised'. <lloda>The extra check would only happen if the copysign check failed, so I don't think it's too bad. <jmd>Act like a real nan ! ***michel_mno is now known as michel_mno_afk
<paron_remote>davexunit: you're running guixsd on yer libreboot'ed x200 right? <davexunit>my other machine uses nouveau and that works too <paron_remote>I think I'm getting a gluglug and slapping guixsd on it sometime after recovering from the moving costs. <paron_remote>but first, I might convert my home server to run guixsd as a first run <davexunit>if I could just get xbmc packaged I'd switch my home server over