Add "print-config" subcommand

[le-lenn]

Addresses #628

Approach

I looked into how shouterrr pretty-prints its verify function and tried to find the best poor-mans approach to it.

I wanted to add a little bit of formatting, because without any formatting, the output is pretty hard to read. So I landed on a basic regex based formatter.
I played around with coloring the output as well, but I ended up with a lot of code for a nice-to-have, so I removed it again.

[m90]

Just wanted to let you know I will need some more time in order to do a proper review here. I'm very happy the PR is here in any case.

[le-lenn]

No worries, frohe Weihnachten!

btw I’m not too happy with the flag parsing, I think my implementation could be improved

[m90]

This looks good, I left some comments inline, let me know what you think.

There's one bigger question left for me in this: should there also be an option that "resolves" configuration values as deeply as possible, i.e. reads Docker secrets, expands shell variables, and renders config options that are templates? Or should this be the default even?

[le-lenn]

This looks good, I left some comments inline, let me know what you think.

There's one bigger question left for me in this: should there also be an option that "resolves" configuration values as deeply as possible, i.e. reads Docker secrets, expands shell variables, and renders config options that are templates? Or should this be the default even?

I was under the false impression that sourceConfiguration() would resolve all config values as deeply as possible already. Thanks for the hint! I think the default should be to resolve as deeply as possible, since the "resolved" values are the ones being used in the end.

I'll have a go to see if I can resolve without adding too much complexity.

[m90]

I was under the false impression that sourceConfiguration() would resolve all config values as deeply as possible already.

I would think it'd be a good thing to at least evaluate how much effort modeling things like this would be.

[le-lenn]

I was under the false impression that sourceConfiguration() would resolve all config values as deeply as possible already.

I would think it'd be a good thing to at least evaluate how much effort modeling things like this would be.

I added some simple logic to resolve env vars when BackupFilenameExpand is set.

This is an AI analysis of what it would take to resolve all env variables:

• Additional resolution happens later during runtime, not during sourcing:
  - applyEnv is only called in runScript, so conf.d‑provided env vars are not present for
  os.ExpandEnv in show-config (cmd/backup/run_script.go, cmd/backup/config.go).
  - Backup filename template ({{ .Extension }}), optional ExpandEnv, and strftime are applied in
  script.init (cmd/backup/script.go).
  - EMAIL_* → derived NotificationURLs and NotificationLevel validation also happen in
  script.init (cmd/backup/script.go).
  - Azure endpoint templates are resolved when the Azure backend is created (internal/storage/
  azure/azure.go).

  Complexity to “resolve more”:

  • Low/medium: extract a pure “resolve for display” helper to apply applyEnv, the backup filename
    template (extension + strftime using time.Now()), and ExpandEnv for the 3 fields. This is mostly
    moving logic out of script.init and would add some time‑dependent output.
  • Medium/high: include derived NotificationURLs and NotificationLevel validation. That requires
    sharing more of script.init or duplicating logic, and deciding how to surface warnings in show-
    config.
  • High: fully match runtime resolution (e.g., Azure endpoint template via backend constructors).
    That likely needs a refactor to split “config resolution” from “resource instantiation” in
    script.init to avoid side effects (sender setup, docker client, storage client creation).

[m90]

I'm not sure this is needed as I would expect the returned error to be printed as well on exit? Or is that not happening and the mechanism is broken?

Also applies below.

[m90]

What happens when no configuration directory is present and configuration is provided via env vars only? Does it fall back to env? Sorry, it's been a while since I have written this 😅

[m90]

This is great, but I feel it might be worth it doing this properly (going the "High" complexity route) while we're at it.

Would you feel comfortable implementing this? In case not, I can also do this and we'll rebase this PR off the updated revision.

[m90]

Started working on this in #705

[m90]

This seems to work as intended, maybe you can have a quick look and a sanity check before I merge? The only thing I did not hoist into the resolve method is replacing the time formatting tokens in the backup filename, I found that happening at resolution time to be unexpected, so this still lives in init. I would also not expect this to be shown in the ouptut of print-config.

Another thing that connects this PR: the resolve method now returns a list of warnings which would be nice to print out here as well I believe?

[le-lenn]

Unfortunately, I’ll be on vacation for the coming days.

but I took a quick look at the code at my phone and really like the approach!

If you want you can merge and I’ll base this PR on the new resolve mechanism.

[le-lenn]

and for code review, have you taken a look at coding agents like Claude code and Coderabbit for automatic PR reviews? I’ve seen some quite impressive reviews from AI that caught a bunch of easy to miss bugs.

If you want, you could take a look at some PRs on “dozzle” and “pocket-id”. These projects use AI for automatic code review and it seems to be quite useful

[m90]

I merged the PR, so feel free to rebase whenever you're back and have the time. In the meantime, enjoy the vacation!

[m90]

I had another look at the original issue: #628 which made me think we should check how the output handles trailing newlines here. Just writing this down so we don't forget.