Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

show BORG_* environment variables #8454

Open
SpiritInAShell opened this issue Oct 5, 2024 · 2 comments
Open

show BORG_* environment variables #8454

SpiritInAShell opened this issue Oct 5, 2024 · 2 comments

Comments

@SpiritInAShell
Copy link

SpiritInAShell commented 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 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
Copy link
Member

ThomasWaldmann commented Oct 5, 2024

  • Guess set | grep BORG_ would also solve this.
  • I think we usually have cli arguments taking precedence over env vars.

@SpiritInAShell
Copy link
Author

SpiritInAShell commented Oct 5, 2024

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 ThomasWaldmann changed the title $BORG_* environment variable improvement show BORG_* environment variables Oct 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants