Re: Possible bug with grep/sed/tail?

[Jim Meyering]

Brian Dessent <address@hidden> wrote:
> Jim Meyering wrote:
>>   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"
>
> Note that I named the function 'f()' for brevity in the example, but for
> a general solution I worry that it should have a name that cannot clash
> with any other global symbol in the program or any of its libraries.
> One way of achieving this is to put it in an anonymous namespace, which
> obliges the compiler to give it a guaranteed-unique name:
>
>   local setvbuf='namespace { __attribute__ ((constructor)) void
>     f () { setvbuf (stdout, NULL, _IOLBF, 0); } }'
>   echo "$setvbuf" | gcc -s -include stdio.h -x c++ - -fPIC -shared \
>                         -o "$line_buffer_so"

Nice.
For my personal use, relying on g++ is fine.
But if we end up adding a tool like Pádraig's proposed "stdbuf",
I am inclined to use only C.  Why?  It's not that C++ support isn't
mature, it's just that adding a requirement in _coreutils_ (even if
only for this one program) on not just LD_PRELOAD but also on C++...
seems like opening pandora's box.  Any target system must already
have LD_PRELOAD support, so that may help by eliminating some of
the older candidates.

Guaranteed namespace anonymity would be nice, but initially it will be
ok to sacrifice that, as long as we choose a function name that is long
and random.

At least for starters, I'd rather build the new program only when gcc
is available with __attribute__((constructor)) support.  Or some other
C compiler, as long as we know how to do the same things with it.
Keep it simple.  This is the *GNU* coreutils package, after all,
so it's ok if certain extra-value features are initially available
only on systems with GNU tools.

>> # test with this:
>> # (while :; do printf 'x\ny\n'; sleep 1; done) |line-buffer grep x
>
> Is that really a valid test?  Doesn't the stdout of grep need to be a
> pipe?

You're right.  It's not.  Now I have this:

  # test with this:
  # (while :; do printf 'x\ny\n'; sleep 1; done) |line-buffer grep x|sed s/x/./
  # Or, more realistically, grep for warnings in build output:
  # make >& log & line-buffer tail -F log --pid=$! |grep -i warning

Thanks!

>> > Of course this solution depends on gcc and LD_PRELOAD etc.
>>
>> The mixed blessing of shared libraries...
>
> Well, __attribute__((constructor)) is gcc-specific but it was another
> shorthand used for brevity to squeeze things into one line.  The ctor
> could however just as well be implemented in plain ISO C++.  Naturally
> the specific set of required options to produce a shared library does
> tend to be compiler specific though.
>
> I'd be more concerned about the portability of LD_PRELOAD, which tends
> to be a feature of ELF systems.  Cygwin does provide an emulation of
> LD_PRELOAD however, so the example at least does work there as well,
> modulo s/-fPIC// and s/.so/.dll/.