Is it possible to redirect the output from
strace to another window?
So I can have two windows, one for pry where I'm making all interaction, and another window of
You can use
strace -p in one window to trace a command running in another window. The
-p option accepts one or more process ids, so you could, for example, try
strace -p "$(pidof pry)"
if you have at least one process which
pidof recognizes as
pry. You might need to experiment with
pidof (if I want to strace a
pudb3 command, I need to use
python3 rather than
pudb3), and using
pidof might not be the best approach if there is any ambiguity associated with it (you might have multiple commands which match but only want to
strace one of them). It might be easier to find the right process is with
ps and provide the option directly.
This approach is not likely to work well with a short lived process, or in a situation where it's important to see output from early in the lifetime of the process, but for an interactive application whose startup time isn't especially interesting, it might be workable.
One difference with using
strace -p as opposed to
-p is how interrupts are handled. A process launched by
strace will have interrupts like Ctrl-C passed along to it (and reported by
strace), but Ctrl-C in
strace -p will detach it, and allow the process to continue without tracing (and Ctrl-C still works in the application if it's in a separate window).
And the wrapper method for short-lived processes or where it is important to see output from early in the lifetime of the process:
#!/bin/sh # the pid could be sent to a file or named pipe the-thing-that-does- # strace could be watching, though in most cases a human could copy it echo "PID to strace is $$" trap : USR2 # block while human copies pid over to strace (or some program acts on # the above pid being written in that other terminal). Busy loop or # something instead if this program must not consume input (`sleep` # complicates the signal handling) read blocking # then when strace is up, send this process a USR2 signal. this will # mean there will be some strace of this script in addition to the # target, hence the kinda sorta caveat. exec echo /the/program/of/interest
Or, instead simply run
sysdig in that other terminal window, as
sysdig can snoop directly on a program by name:
sysdig -p '%proc.name %evt.type(%evt.args)' \ proc.name contains /the/program/of/interest