Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
...
>> Then you can use it e.g., to watch *interactively* filtered tail -f output.
>> For example, watch for warnings in build output like this:
>>
>> make >& log & line-buffer tail -F log | grep warning:
>
> grep --color warning.*
For me, "grep" is already a function that uses --color ;-)
>> but that's not quite right, since it hangs forever.
>> Add --pid=$! to make tail stop when the parent (make) process dies:
>>
>> make >& log & line-buffer tail -F log --pid=$! | grep warning:
>
> That's a tip and a half.
> I'll certainly be using that,
> Though I'll probably auto-compile the lib like:
>
> [ ! -x "$line_buffer_so" ] && line-buffer-init()
Good idea. I've adjusted mine like this:
line_buffer_so=$HOME/lib/line-buffer.so
# Create the .so file if it doesn't exist.
line-buffer-init()
{
test -x "$line_buffer_so" && return
local setvbuf='__attribute__ ((constructor)) void
f () { setvbuf (stdout, NULL, _IOLBF, 0); }'
echo "$setvbuf" | gcc -s -include stdio.h -x c - -fPIC -shared \
-o "$line_buffer_so"
}
line-buffer-init
alias line-buffer="LD_PRELOAD='$line_buffer_so' "
# test with this:
# (while :; do printf 'x\ny\n'; sleep 1; done) |line-buffer grep x
> Of course this solution depends on gcc and LD_PRELOAD etc.
The mixed blessing of shared libraries...
> What about adding buffer control to all coretuils filters.
> Is that still a desired feature do you think?
I don't relish the idea of adding an option or feature
to each and every filter in coreutils. Especially
considering that this approach solves the problem --
albeit with requirement on gcc and LD_PRELOAD.
Maybe we can relax that requirement...
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
