I've tried this approach and haven't been successful. Mostly I just wanted to try ptrace. I got as far as trying to read the file descriptors and getting nothing back.
I'd love to hear how to do it this way though, since it would probably be a lot more robust and performant. My email is in `setup.py` in the repo if you want to reach out.
Fair enough. Simply reading from the file descriptor won't work since some of the output will be redirected to the original process depending on who reads the next character first. The solution is to attach to the process using ptrace and then reditrect the stdout using dup. There is an example on how to do this with gdb on stackoverflow (http://stackoverflow.com/questions/1323956/how-to-redirect-o...) This would give a nice performance boost if you could implement this in your code.
Neat. I wrote something similar using websockets for piping stdout/stderr to the web[0]. This is much lower level, I'll be reading the code to see if I can improve performance in PipeUp.
Honestly, in the past I've wanted something like this when a co-worker was running a process that was outputting progress, and I didn't want to keep bugging them to see how far along it was. You could use it to check on something like that.
The evil use case is just to watch what someone else is doing.
You can provide multiple viewers read-only access to session using a combination of ttyrec by the recorder, and ttyplay in streaming mode for incoming tcp connections. Perhaps using socat, inetd, systemd, etc: http://0xcc.net/ttyrec/index.html.en
It should work, but it'll slow down any process you're tracing. As you mentioned, screen works great for stuff that you have the foresight ahead of time to run in a screen session, such as a remote demo.
