I wouldn't follow this approach because if you run `. .env;` you .env gets evaluated as a bash script, not as a configuration file. This means that you can get runtime errors in the .env file, and nobody wants that.
Sourced environment scripts in the Unix environment are standard operating procedure. E.g. for toolchains.
The .env being evaluated as a shell script means that it's in a widely used language, with a widely known syntax. You can look at it and know what it's going to do.
The .env being a data format to some uncommon utility; that's anyone's guess.
For instance, suppose we want a newline character in an environment variable. Does the given "env file" format support that? How?
There is one de-facto standard format: the /proc/<pid>/environ kernel output format on Linux. The variables are null-terminated strings, so it is effectively a binary format. It represents any variable value without requiring quoting mechanisms.
The .env being evaluated as a shell script means that it's in a widely used language, with a widely known syntax. You can look at it and know what it's going to do.
The .env being a data format to some uncommon utility; that's anyone's guess.
For instance, suppose we want a newline character in an environment variable. Does the given "env file" format support that? How?
There is one de-facto standard format: the /proc/<pid>/environ kernel output format on Linux. The variables are null-terminated strings, so it is effectively a binary format. It represents any variable value without requiring quoting mechanisms.