Strange bug with stdout redirection.
Feb. 21st, 2011 04:28 pmJust had to write a simple wrapper over a binary executable which reads some data from port, does some actions according to the input, and if input cannot be processed it does something like:
printf("Cannot process input: %x\n", input)
I wanted to redirect it's output to my script that would process some of the unprocessed input.
The miracle is that if I pipe or redirect output of an app all output disappears.
e.g. if I run
strace ./app
I got
write(1, "Cannot process input: 0xAA\n", 28)
but if I run
strace ./app >out 2>&1
I got all possible strace output from other functions but not from write. I did not have time to debug further and took different approach but looks like I have some major problem in my understanding of the platform I am running on. (Some embedded h/w with special linux distro)
P.S. I've recently interviewed a guy who teaches CS in Uni (won't tell in which one :). He is good with algorithms, OK with C/C++, but has zero understanding of multithreading. I was shocked.
printf("Cannot process input: %x\n", input)
I wanted to redirect it's output to my script that would process some of the unprocessed input.
The miracle is that if I pipe or redirect output of an app all output disappears.
e.g. if I run
strace ./app
I got
write(1, "Cannot process input: 0xAA\n", 28)
but if I run
strace ./app >out 2>&1
I got all possible strace output from other functions but not from write. I did not have time to debug further and took different approach but looks like I have some major problem in my understanding of the platform I am running on. (Some embedded h/w with special linux distro)
P.S. I've recently interviewed a guy who teaches CS in Uni (won't tell in which one :). He is good with algorithms, OK with C/C++, but has zero understanding of multithreading. I was shocked.