caddyserver
Fail when environment variables were expected but not provided
Hi. This is a continuation of #2815.
tldr; I know we can use default environment variables to fall back on, but I'm looking for something similar to bash's set -u: (Treat unset variables as an error when substituting), which keeps being a lifesaver.
The big problem/question is, what are we going to do about it? It's too late, by the time most placeholders are evaluated, to do anything with the error. Fail the request whose handler uses the placeholder? I'm not really sure how useful it will be since placeholders are evaluated at runtime.
I'm probably missing a ton context, but I was simply thinking that when we try to substitute an env var before parsing, such as the one declared in this example, and that variable does not exist in the environment, then we could behave just like we would if that config file contained a syntax error (outright fail to start or exit).
Ah, you mean Caddyfile placeholders? {$VAR} is evaluated when the Caddyfile is adapted to JSON. {env.VAR} is what it gets adapted to and is evaluated at runtime.
The problem is that sometimes an empty variable is expected. So we can't always crash in that case.
Is there a reason why Caddy uses {$VAR} instead of ${VAR}?
Otherwise...
Why not use the ${VAR:?VAR is unset or empty} / ${VAR?VAR is unset} syntax to fail with the provided error message?
They're specified by POSIX sh, and also used in the Compose spec.
Because Caddy is neither POSIX nor Docker. The syntax was chosen to roughly align with placeholders syntax in Caddy which is typically {something.like.this}
Why do you need POSIX/Docker syntax?
I don't need it. I was just wondering if it was considered, as it'd be familiar to many people, and is used in many tools. And it also has well-specified parameter expansions that neatly solves this case.
On the other hand, only PHP seems to use {$var}