On Tue, Jan 17, 2023 at 11:37 PM <eshwayri@gmail.com> wrote:
The output() function. This line:
printf "%s\n" "${m}"
It will fail if there is no attached TTY,
Are you sure it requires an attached _TTY_? Not merely stdout? It indeed requires a TTY in certain cases (see readdbpassword) but not in the common ones.
which will set the exit code to 1, which in turn will trigger the cleanup() function notifying the engine that the backup failed. This ironically happens when it should be writing "Done."
Doesn't it use 'output' much earlier, thus failing much earlier? E.g. here: output "Start of engine-backup with mode '${MODE}'"
and exiting after a successful backup. Fix I used was to change it to:
printf "%s\n" "${m}" >> "${LOG}"
This is redundant - 'output' already writes to the log.
You can't assume attached TTY
Well, if we want to be able to input passwords safely, we need a tty. For common cases, we indeed do not, and do not assume it. We do indeed assume stdout. Almost all 'normal' programs do. E.g.: $ date >&- date: write error: Bad file descriptor $ echo $? 1 When needing to run such programs without stdout, you usually wrap them, e.g.: $ (date > /dev/null) >&- $ echo $? 0
since a lot of people like me want to run this as part of a pre/post script to an automated backup program.
Please clarify your case. If it's a shell script that's calling engine-backup, can't this script redirect the output? E.g. to /dev/null, if you never look at it? If you provide this script directly to some backup program that does not provide an stdout (meaning, executes it with FD 1 closed), you indeed have to handle this somehow. I'd personally do this by creating a trivial one-line wrapper script and point the backup program to the wrapper. That said, I'd consider such behavior a bug in the calling backup program. I'd expect such a program to provide an stdout to the pre-/post- programs it calls, keep the output sent there, and log it to its own logs. When things fail, it will be so much easier for the user to investigate stuff if you can see the engine-backup output in the caller's log. (But admit that when I was a sysadmin and used such programs, I always wrote my own wrappers around them, and not vice-versa. I realize this isn't always the best choice or even possible). Hope this helps. If you still think there is a real bug, please provide more details. Thanks and best regards, -- Didi