I have a backup script which I'm asking now to (offer to) call a git pull script before actually running the syncs (when run interactively). The syncs are done thusly:
rsync aiSP --delete
The backup contains this redirection:
exec 2> "${const_logfile}"
The git pull script has these two lines:
printf '%s\n' "Shall we pull all the gits? "
read -rep "(You will have to enter your git password for each one.) (y or N) " -n1
When rsync runs, all of its progress output shows in the terminal (and doesn't get stuffed into the log file). Any error in rsync is added to the logfile.
When the git pull script is called by the backup script the printf line displays in the terminal, but the read text gets stuffed into the log file (and not displayed). This doesn't happen when that script is called directly.
So I pulled that line of redirect code into a test script that contained only that and the git pull script call, so I'm certain that's the culprit. Finally, I added the redirect code directly into the git pull script and called that directly, and the read text again failed to show in the terminal and was sent to the log file.
I would expect the printf text and the read text to go the same route?
I'm sure there's a simple explanation. Or complex. Enlighten me, please.
EDIT:
Raj was helpful; thanks, Raj!
However, there is more I'd like to understand; so, if anyone knows of an article that talks about what qualifies as these extraordinary messages (as Raj has called them) and why it's useful to send them to stderr, I'd love to read more about this.
Also, someone following along may like to know about the -p aspect of read (from here):
-p prompt Display prompt on standard error, without a trailing newline, before attempting to read any input. The prompt is displayed only if input is coming from a terminal.
read
command's-p
option in theSHELL BUILTIN COMMANDS
section ofman bash
: "Display prompt on standard error"