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.

No worries, frohe Weihnachten!

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

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.

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 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).

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.

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.

Do you have any ideas how to handle this?

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.

Do you have any ideas how to handle this?

How does the current mechanism display a value with a trailing new line? I don't necessarily have an opinion on how exactly this should look like, but it should be obvious that it's really the configuration that contains the newline, not the print-config output.

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.

Do you have any ideas how to handle this?

How does the current mechanism display a value with a trailing new line? I don't necessarily have an opinion on how exactly this should look like, but it should be obvious that it's really the configuration that contains the newline, not the print-config output.

This is how it currently looks if there is a trailing newline in a docker secrets file. The printed output also spans multiple lines.
Not super obvious to be honest, but is is there. We could also add a hint in the docs where it talks about docker secret files and recommend to check for trailing spaces or newlines.