You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
The text was updated successfully, but these errors were encountered:
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.
ThomasWaldmann
changed the title
$BORG_* environment variable improvement
show BORG_* environment variables
Oct 5, 2024
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.)The text was updated successfully, but these errors were encountered: