3 ms·
Also, if we are going to involve the shell, we could also just make .env a shell fragment and do this: sh -c '. .env; <cmd>' There is a way to pass command
by kazinator 3y ago
Also, if we are going to involve the shell, we could also just make .env a shell fragment and do this:
sh -c '. .env; <cmd>'
There is a way to pass commands to it which are reliably executed, like thisL
sh -c '. .env; "$@"' -- command arg1 arg2 arg3.
The non-option arguments passed to the shell are available as `"$@"`. A command consisting of nothing but `"$@"` basically executes the arguments. We can use `exec`, speaking of which:
sh -c '. .env; exec "$@"' -- command arg1 arg2 arg3.
What I'm getting at is that this form is fairly easily exec-able;
execl("/bin/sh", "/bin/sh", ". .env; exec \"$@\"", "--", "command",
"arg1", "arg2", "arg3", (char *) 0);
The command and arguments can be arbitrary strings, not subject to any shell mangling.
- cholindo 3y agoI 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.
- kazinator 3y agoSourced 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.