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.