On Mon, 14 Mar 2022, Florian Zieboll via Dng wrote:
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
On Mon, 14 Mar 2022 19:10:43 +0100
Ludovic Bellière 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
Reading stdbuf man page, it tells us that 'dd' is unaffected by its
settings because 'dd' doesn't use streams:
NOTE: If COMMAND adjusts the buffering of its standard streams
('tee' does for example) then that will override corresponding
changes by 'stdbuf'. Also some filters
On March 14, 2022 3:38:43 PM GMT+01:00, "Ludovic Bellière"
wrote:
> Hello Florian,
>
> The output isn't going anywhere, it's simply being buffered. It's a
> default when a tool doesn't specify buffering behavior for stdout. In a
> chained pipe, the output will only start being sent once the
Hello Florian,
The output isn't going anywhere, it's simply being buffered. It's a
default when a tool doesn't specify buffering behavior for stdout. In a
chained pipe, the output will only start being sent once the buffer gets
full. That is to avoid heavy use of resources in case the tasks
On March 14, 2022 11:42:16 AM GMT+01:00, Florian Zieboll via Dng
wrote:
>
> Where is it going resp. how do I catch it?
I was able to work around it by putting the 'tr'-logic in the "postprocessing"
logmailer script. This creates some overhead, as the script loops over the
logfile... but
Hallo list,
may I ask for support with redirecting piped / processed stderr to a file?
dd prints it's progress to stderr, I can redirect it to a file:
$ dd if=/dev/zero of=./zeroes bs=4M count=1000 status=progress 2> ./file
Now I want to get rid of the CR and can print to the console as
aitor said on Sat, 12 Mar 2022 20:13:12 +0100
>Hi Joel,
>
>On 12/3/22 19:52, Joel Roth via Dng wrote:
>> Thank for these suggestions. I've been killing dhclient and
>> bringing down the interface, bringing it up and restarting
>> dhclient. which I think does mostly the same thing. I also
>>
