Ran into the same problem today.
FWIW you can use
| cat instead of
| echo in your example,
echo apparently does nothing by default with no parameters.
On my box
strace ls 2>&1 | grep "execve" > asd.out actually works OK...so you're doing it right.
My hunch is the problem is in the "attaching" like
strace -p xxx because typically you have to hit
ctrl+c to exit it and intermediate buffers in your command chain are not flushed.
So this works for me (I think it flushes on a new line because it detects it it outputting to "the screen"/terminal/tty):
strace ruby -e "sleep" 2>&1 | grep execve
but this doesn't
strace ruby -e "sleep" 2>&1 | grep execve > my_output_file
(I think because the final redirect is "not to a tty" so it uses a larger 4k internal buffer or something, or uses an internal buffer instead of buffering "by line" anymore).
But using a hint from here, this works:
strace ruby -e "sleep" 2>&1 | stdbuf -oL grep execve > me
Pretty weird stuff. In a disconcerting way. And my theory is that with longer chains (ex:
grep | grep | grep the size of the buffer grows linearly...4k each time...including for the one that writes it finally out to disk...)
Another thing that can help is insert an "output to screen" peeker in your chain, which is apparently
strace ruby -e "sleep" 2>&1 | tee /dev/tty | grep execve > my_output_file
Then at least you'll see it on the screen even if it never makes it to the output file.
So anyway the take away from this is that strace logs to "normal"
stderr (so if it's "running a process" eg.
strace ls then the output from the process and strace will be mixed). You can avoid the mixing by using the
-o output_file parameter.
Also be careful you must redirect stdout first, then stderr, ex:
progname >out.txt 2>&1
order matters, it can't be the other way around.