borgbackup / borg

Deduplicating archiver with compression and authenticated encryption.
https://www.borgbackup.org/
Other
11.22k stars 743 forks source link

show BORG_* environment variables #8454

Open SpiritInAShell opened 1 month ago

SpiritInAShell commented 1 month ago

Have you checked borgbackup docs, FAQ, and open GitHub issues?

Yes

Is this a BUG / ISSUE report or a QUESTION?

Question/Suggestion

System information. For client/server mode post info for both machines.

Your borg version (borg -V).

any 1.2/1.4/2.x known to me

Describe the problem you're observing.

Suggestion

in the spirit of --show-rc and --show-version, add something like --print-env to print all $BORG_* environment variables that are being taken in effect. (Exceptions: at least BORG_PASSPHRASE)

"in effect" means: if BORG_REPO is set, print it, unless a repo is specified on commandline.

Abstract reason: borg is configured both by commandline parameters and environment variables (where the CLI overrides envars). Log output does enumerates all CLI parameters, but not the BORG_* vars.

Even when scripting: logging of the command line together with eg. all variables starting with '^BORG_' still does not implicitly clarify which of those variables are taken "in effect" by borg (I could parse and log "what I THINK is taken in effect" but that does not tell me what borg "thinks")

It would be at least convenient. Especially for debugging a mis-behaving configuration. But maybe even in productive environments the admin could see (in stdout/stderr/debug log/...) exactly which variables where in effect each run, to faster understand different behavior between runs/configurations. (Honestly, a falsly set environment variable can be as disruptive as a hastly set global in many programming languages. --print-env would clarify this.)

ThomasWaldmann commented 1 month ago
SpiritInAShell commented 1 month ago

First, I want to say that this is not at all a requirement for good user experience, only a suggestion for convenience. No harm done when not added to the feature list.

  • Guess set | grep BORG_ would also solve this.

    • I think we usually have cli arguments taking precedence over env vars.

Yes, that is both true. Still the borg output (stdout/stderr) does not contain the information, which settings outside of commandline are in effect. If it was part of the log, the log output would be "a complete single entity" containing all the information of that run without adding the output of set | grep ^BORG_

Also, to know what variable was in effect at that special run, I would have to parse the log for commandline string + the variable list and determine for every variable set whether eg -r | --repo | --repo= was used and overridden.