Open SpiritInAShell opened 1 month ago
set | grep BORG_
would also solve this.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.
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 leastBORG_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 theBORG_*
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.)