Re^2: cmd timeout

The problem with this kind of stuff (such as nc host port | tr foo bar) is usually that the first program (the one you read from) will buffer output if the stdout isn't a terminal, and you can do nothing about that without changing that program. Just changing the second program isn't enough. I don't know tcpdump so I can't tell if that's the problem here too though.

Comment on Re^2: cmd timeout Download Code

Replies are listed 'Best First'.
Re^3: cmd timeout by bart (Canon) on Apr 07, 2010 at 11:18 UTC
There might be a command line option to make `tcpdump` output non-buffered. Looking at the man page, `-U` (packet-buffered) looks promising. Alternatively, take a look at `-c` (exit after receiving count packets) and `-G` (rotates the dump file specified with the -w option every rotate_seconds second). I would also like to point out that there's a good Perl module for Pcap, which is what `tcpdump` is built around: Net::Pcap.	[reply] [d/l] [select]
Re^3: cmd timeout by cdarke (Prior) on Apr 07, 2010 at 11:11 UTC
I agree, so I would change the signal handler to something like this: `sub { kill 'INT', $pid; sleep 1; # Yield the CPU close $process; die "timeout\n" };` [download] You might need to give the process chance to flush its buffers. I know, a sleep is usually a sign of a suspcious hack.	[reply] [d/l]
Re^4: cmd timeout by ikegami (Patriarch) on Apr 07, 2010 at 15:08 UTC
And it's no exception here. There's no guarantee that enough other packets will be gathered to fill the buffer in that second. Or maybe you're trying to make sure the child finishes, but `close` already does that by calling a blocking `waitpid`.	[reply] [d/l] [select]