On Mon, 14 Mar 2022 19:10:43 +0100
Ludovic Bellière <belliere.ludovic@???> wrote:

> Reading stdbuf man page, it tells us that 'dd' is unaffected by its
> settings because 'dd' doesn't use streams:

Yes, I noticed that - but it is the stdout of 'tr' which I have to
modify, and only when I use it with 'dd'. Without 'stdbuf', there are
indeed 4096 Bytes chunks being written to the log file.


> Reading the pipe man page ('man 7 pipe') tells us that there are two
> ends to a pipe: read and write. Each of them are affected by the
> buffer settings. Most likely 'rsync' outputs is being buffered before
> landing on 'tr'.

So I assume that it is 'tr' which recognizes that rsync's output is
already buffered and thus keeps this setting - while the output of 'dd'
comes in another format and 'tr' decides that it would be a good idea
to 4k-buffer it before passing it on?


> Looking at how you use stdbuff, you seem to only
> define the output (write end) of the 'tr' command.

Yes, unbuffering the input of 'tr' (from 'dd') does not have any
effect.


> Lastly, it would be unwise to disable the buffering unless it is only
> done temporarily. You have nothing to gain from it except brevity on
> feedback latency. Instead of disabling buffering altogether, you can
> opt to use line buffers (option 'L') instead of the default 4k block
> buffer. That would, presumably, give you a line by line output.

Thank you for the hint: '-oL' works fine, too, and I am going to adopt
it tomorrow.

Libre Grüße,
Florian