Description of problem: When piping output from "tail" into "cut", the output of "cut" to stdout is buffered. This is unfortunate in case one wants to follow a logfile in realtime. E.g. "tail -f msgserver.log" ...outputs the lines as they come "tail -f msgserver.log | cut --field=6 --delimiter='|' ...outputs the lines once the buffer between 'cut' and the terminal driver is full (or something) Version-Release number of selected component: coreutils-5.2.1-31.4 How reproducible: Always Patch attached. I have added the option '--push' (with short option 'p') to 'cut' (no Red Hat patches have been applied to cut as far as I see) Why option 'p' instead of 'f'? Because 'f' was already taken. And 'p'/'push' sounded good. If the option has been set, 'cut' goes into a mode whereby it issues an 'flush' after every 'fwrite' to stdout. Note that my C knowledge has become somewhat rusty, but this does seem to work. Patch file created with "diff --unified cut.c new_cut.c"
Created attachment 153257 [details] Patch for "cut". Contains old cut.c, new cut.c and diff
Hmm, there is still a problem whereby the flush mode is always on irrespective of the whether the flag is given or not? Unfortunately, I have to do some "real work" now.
Thanks for the suggestion and patch, but that sort of change is not necessary. Instead, you can do something like the following, using the small unbuffer script that comes with expect. For your reference, here's a copy: #!/bin/sh # \ exec expect -- "$0" ${1+"$@"} # Description: unbuffer stdout of a program # Author: Don Libes, NIST if {[string compare [lindex $argv 0] "-p"] == 0} { # pipeline set stty_init "-echo" eval spawn -noecho [lrange $argv 1 end] interact } else { set stty_init "-opost" eval spawn -noecho $argv set timeout -1 expect } The solution is to run "cut" via unbuffer -p. For example, for i in $(seq 10); do echo a $i >> k; sleep 1; done & tail -F k | ./unbuffer -p cut -d' ' -f2
Uh wow.. I have to get my mind around this. Good thing is, it generalizes to all programs, but somehow it is really, really ugly ;-) Thanks, -- David