Re: Modify buffering of standard streams via environment variables (not LD_PRELOAD)?

["Pádraig Brady" <P@draigBrady.com>]

On 19/04/2024 01:16, Zachary Santer wrote:
> Was "RFE: enable buffering on null-terminated data"
> 
> On Wed, Mar 20, 2024 at 4:54 AM Carl Edquist <edquist@cs.wisc.edu> wrote:
>>
>> However, if stdbuf's magic env vars are exported in your shell (either by
>> doing a trick like 'export $(env -i stdbuf -oL env)', or else more simply
>> by first starting a new shell with 'stdbuf -oL bash'), then every command
>> in your pipelines will start with the new default line-buffered stdout.
>> That way your line-items from build.sh should get passed all the way
>> through the pipeline as they are produced.
> 
> Finally had a chance to try to build with 'stdbuf --output=L --error=L
> --' in front of the build script, and it caused some crazy problems. I
> was building Ada, though, so pretty good chance that part of the build
> chain doesn't link against libc at all.
> 
> I got a bunch of
> ERROR: ld.so: object '/usr/libexec/coreutils/libstdbuf.so' from
> LD_PRELOAD cannot be preloaded: ignored.
> 
> And then it somehow caused compiler errors relating to the size of
> what would be pointer types. Cleared out all the build products and
> tried again without stdbuf and everything was fine.
> 
>>From the original thread just within the coreutils email list, "stdbuf
> feature request - line buffering but for null-terminated data":
> On Tue, Mar 12, 2024 at 12:42 PM Kaz Kylheku <kaz@kylheku.com> wrote:
>>
>> I would say that if it is implemented, the programs which require
>> it should all make provisions to set it up themselves.
>>
>> stdbuf is a hack/workaround for programs that ignore the
>> issue of buffering. Specifically, programs which send information
>> to one of the three standard streams, such that the information
>> is required in a timely way.  Those streams become fully buffered
>> when not connected to a terminal.
> 
> I think I've partially come around to this point of view. However,
> instead of expecting all sorts of individual programs to implement
> their own buffering mode command-line options, could this be handled
> with environment variables, but without LD_PRELOAD? I don't know if
> libc itself can check for those environment variables and adjust each
> program's buffering on its own, but if so, that would be a much
> simpler solution.
> 
> You could compare this to the various locale environment variables,
> though I think a lot of commands whose behavior differ from locale to
> locale do have to implement their own handling of that internally, at
> least to some extent.
> 
> This seems like somewhat less of a hack, and if no part of a program
> looks for those environment variables, it isn't going to find itself
> getting broken by the dynamic linker. It's just not going to change
> its buffering.
> 
> Additionally, things that don't link against libc could still honor
> these environment variables, if the developers behind them care to put
> in the effort.

env variables are what I proposed 18 years ago now:
https://sourceware.org/bugzilla/show_bug.cgi?id=2457

cheers,
Pádraig