Blargh

I've always wanted to be able to move a process from one terminal to another. For example if I've started a long-running foreground process (such as irssi or scp) outside of a screen and I have to log out my local terminal. I looked around and there doesn't seem to be any way to do this. There is a program called retty that I found later on that sort of does this, but it only closes and re-opens stdin/out et al. It doesn't seem to do full terminal handling. Nor does it seem to detach the original terminal. It only allows you to peek into the process, control it for a bit, and then hand it back. If you shut down the original terminal you're still screwed. Attempt 1: pass the fd for the real pty I thought I could ptrace() attach to the process, inject code to dup2() onto stdin/out/err, and do some ioctl()s and that would be that. No such luck as we shall see. The easiest (and most portable way) to do it would be to dlopen() a shared libr...

I'm trying to force a program not to buffer its output to stdout. Any program, all programs. It can't involve changing the source code or depending on weird or unportable stuff. It should be possible. It seems like I'm missing something obvious, but I can't figure out what. Some background info I've written a program ( ind ) that puts itself between a subprocess that it creates and the terminal. It acts as a filter for the output from the subprocess. Like this example, where it prepends "stdout: " to all lines that the subprocess prints to standard output: $ echo hej hej $ ./ind -p 'stdout: ' echo hej stdout: hej The dataflow is, from left to right: echo (the subprocess) -> pipe(2) -> ind -> the terminal (stderr runs through a separate pipe(2). Stdin has not been played with yet) So far so good. The problem is that the subprocess' libc (not the kernel) buffers all output using s...