Capture STDIN / STDERR / STDOUT of a process AFTER it's been started, using command line?

Question

Thanks! My usercase: I started a lengthy interactive 'configure' process (say under 'screen'), and then realised I need to always answer 'no' until I see a particular keyword. Seems a waste of time to do this by hand (not to say that I can easily miss the keyword..)

Thus it seems I want to pipe (a copy of) STDERR / STDOUT to a filter, and also be able to inject into the STDIN of a (console) process, AFTER it's been started, using command line? Is there a ready-made solution?

The following tools seem help. To capture output, use

strace -ewrite -p $PID

It's not that clean (shows lines like: write(#,) ), but works! But does it say handle UTF8 correctly?

To redirect the output, do something like

printf '..input..' >/dev/pts/33

But it is not clear how to find the right device..

Answer 1

Solved in Linux (apparently Linux-specific):

reptyr -s PID 

attaches a process to another terminal and/or exposes its input and output as pipes.

Answer 2

This is possible but it's not pretty. The process is as follows:

1. use gdb to attach to the already running process
2. run p close(<fd>) where <fd> is the file descriptor you want to change
3. run p creat("<path to file">, <perms>) to send the output of the closed fd somewhere else

See This Link for more detailed information

Answer 3

Why do you want to do that??

It is not possible in a portable Posix-ly way! Maybe open-ing the /proc/1234/fd/0 and /proc/1234/fd/1 and /proc/1234/fd/3 pseudo-files (for process 1234) could be an ugly possiblity! And even that might not work in some cases (e.g. for pipes).

In particular, I believe that the semantics of SIGPIPE sent to the process if nobody is reading a pipe would be broken...

And I don't believe that you would be able to keep the pseudo-tty quality of e.g. stdout .

So basically, you'll better find a different way to achieve your overall goals, which you did not explain explicitly.

If your use-case is some weird configure script, you could restart it and feed it with some script of your own (in shell, python, perl, etc...). Don't lose time to try to catch an existing configure process, just restart it appropriately.

Look also at the screen command (and how it is implemented!)