Send user interaction requests to stdout, not stderr
For full, incremental, compressed and encrypted backups or archives
Brought to you by:
edrusb
Menu
▾
▴
#219 Send user interaction requests to stdout, not stderr
I have had a hard time figuring out why dar behaved so strange in my environment. Every now and then, the process stopped for no apparent reason. When I hit Return, dar would continue and stop some time later, again for no apparent reason.
Yesterday, I finally found the reason: dar stopped for user interaction. A "Found negative date..." message was printed, but not on stout (where the names of the archived files appear) but on stderr (which I had redirected to a log file).
So you get an input prompt to an output channel that you have redirected, and dar is happily waiting for a human's response.
From my point of view, a message that requires user interaction is not an error message but an input prompt. And input prompts should be sent to stdout.
Hi Uwe,
dar may read and write archives on stdout where from the use of stderr for out-of-band messaging.
If you ignore "error-like" messages by redirecting stderr to log file, file that you don't read, this is normal you don't get the message.
If dar had output this message to stdout and you would have redirected output messages to a log file to only see the stderr showing (which is much more common, IMHO) you would have complained this error-like message not to show on stderr, right?
However your feedack, and thank you for that, show that there is the lack of documentation on how dar uses stdin, stdout and stderr. I will fix that, taking your remark as a feature request.
Sorry, you didn't quite get the point...
My problem was that I had to figure out why the dar process suddenly stopped for no apparent reason. So if you have any other idea to prevent this situation, please go ahead...
Last edit: Uwe Mock 2025-06-08
this is not another idea, this is the lack of information on how dar is using stderr and stdout and the fact you redirected stderr to a file that led you to this situation. With that information you can now avoid this situation and also control what messages dar outputs to stdout (-v/-va/-vt/-vm/-vd and -q options), disable dar interactions (-Q option) and also avoid or not to redirect stderr to a file if you prefer user interaction with dar... there are plently of possibility, this is your choice.
But, you will probably be disappointed: I will not change the way dar uses stdout and stderr, this is working that way for 25 years or so and until you, nobody complained about that... and I don't feel doing wrong that way.