@f0x In theory it could, but most software doesn't.
If we can coax the software to print its configuration file to the log on startup, at least it will indirectly let you know, because the configuration value in question will be missing. If it always prints the config on startup by default, this can even happen before we considered that the configuration part wasn't working.
In theory if the environment variable is prefixed, it might be possible to directly warn about unknown environment variables and/or low
levenshtein distance between the env var's name and a known configuration variable name.
I bet folks have been scared to implement this kind of logic for env-var-based config because of how the environment variables are often all thrown into the same global namespace, so there's a possibility of collisions with other programs running on the same machine.
The warning message for the unknown env var(s) would have to warn you that "this warning itself might be spurious" 🙃 that classic aged 30-40 years old technology flavor
@f0x I wish this kind of logging behavior would be more commonplace but everyone seems to think is weird or there's something wrong with it 🙁
@forestjohnson it's iffy for authentication in env variables (which are always iffy imo), but all software should print the rest of their config on startup tbh
@forestjohnson yeah it's such a docker thing really...
NixOS solves this super easily, you can just use builtins.toFile <filename> <contents> which makes sure that string is available as a (config) file to the program you're running
@f0x https://nixos.wiki/wiki/NixOS_on_ARM
There are already quite some community supported SBCs 👀
@forestjohnson yeah, nixos is the best! https://git.pixie.town/f0x/nixos great system orchestration
@f0x thats the really messed up thing about it 💀