Re: Possible bug with grep/sed/tail?

[Jim Meyering]

Pádraig Brady <address@hidden> 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...