> A) # tail trace.txt | grep "com" > - WORKS: produces output > B) # tail trace.txt | grep "com" | cat > - WORKS: produces output > C) # tail -f trace.txt | grep "com" > - WORKS: produces output, then waits and reports new lines > D) # tail -f trace.txt | grep "com" | cat > - FAILS: no output from existing lines, never gets new data > > To me, it seems completely counterintuitive that A, B, and C would > work, but D does not. Each line of input read by tail should be > passed to STDOUT, which is then read as STDIN by grep/sed, then passed > to STDOUT and read by cat. It should not matter if tail is "done" > reading the output or not, as clearly that works fine in case C.
Buffering occurs line by line in cases A and C, in bigger blocks in cases B and D. So the data is stuck in grep (or sed's) buffers until enough of it is produced. If it is never produced, it is stuck unless sed/grep see an end-of-file condition on stdin -- which they do with tail, but not with tail -f. Paolo _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
