I like the idea of using dotenv files, but I dislike having to use different language-specific libraries to read them.<p>To solve this, I created a small utility that lets you prefix any command with "dotenv" to load the ".env" file.<p>This is how I imagine dotenv would work if it had started as a UNIX utility rather than a Node.js library.
I think direnv already does a good job in this space, and it's already available in your package manager.<p><a href="https://direnv.net/" rel="nofollow">https://direnv.net/</a>
Please just see this<p>`env -S "$(cat .env)" <cmd>`<p>Believe it or not that’s all you need.<p>> S, --split-string=S
process and split S into separate arguments; used to pass multiple arguments on shebang lines<p><i>edit: forgot the quotes around shell substitution</i>
Compare with dotenvx - <a href="https://github.com/dotenvx/dotenvx">https://github.com/dotenvx/dotenvx</a>
This is my current tool of choice.
I just remembered. Adding a -f <file> option to the GNU Coreutils env utility has previously been discussed:<p><a href="https://lists.gnu.org/archive/html/coreutils/2021-10/msg00001.html" rel="nofollow">https://lists.gnu.org/archive/html/coreutils/2021-10/msg0000...</a><p>It came up in the mailing also this March. I saw the posting in my inbox and proposed that a null-terminated format be handled, which is exactly like /proc/<pid>/env:<p><a href="https://lists.gnu.org/archive/html/coreutils/2024-03/msg00140.html" rel="nofollow">https://lists.gnu.org/archive/html/coreutils/2024-03/msg0014...</a><p>If that feature were available, this becomes<p><pre><code> env -f .env command arg ...</code></pre>
There is also shdotenv that allows you to load different .env file formats and convert between them, e.g. for UNIX shell.<p><a href="https://github.com/ko1nksm/shdotenv">https://github.com/ko1nksm/shdotenv</a>
<p><pre><code> export $(cat .env | xargs)
</code></pre>
Agree with the premise but this can be achieved with actual Unix concepts no need for anything else.<p>The language runtime dotenv projects are banned in my engineering org.
Thanks to OP and other posters - various ideas useful in different cases.<p>The xargs idea made me think of using bash as the parser :<p><pre><code> bash -c "exec -c bash -c 'source $CONFIG/main.bash; env'"</code></pre>
This test .bash file contains multiple source-s of other .bash files, which contain a mix of comments, functions, set and env vars - just the env vars are exported by env.
This seems useful e.g. for collating & summarising an environment for docker run -e.<p>This outputs the env vars to stdout; for the OP's purpose, the output could be sourced :<p><pre><code> envFile=$(mktemp /tmp/env.XXXXXX);
bash -c "exec -c bash -c 'source $CONFIG/main.bash; env'" > $envFile;
env $(cat $envFile) sh -c 'echo $API_HOST'
</code></pre>
# For Bourne shell, use env -i in place of exec -c :<p>sh -c "env -i sh -c '. $CONFIG/main.sh; env'" > $envFile
This looks good and neater than my solution in my .zshrc:<p>envup() {<p><pre><code> local file=$([ -z "$1" ] && echo ".env" || echo ".env.$1")
if [ -f $file ]; then
set -a
source $file
set +a
else
echo "No $file file found" 1>&2
return 1
fi</code></pre>
}<p>You can also specify `envup development` to load .env.development files should you want. Obviously this will pollute the current shell but for me it is fine.
This is interestingly similar to a little tool I wrote called sops-run [0], which manages encrypted secrets for cli tools using Mozilla’s sops [1]. Biggest upshot is that you can use it more confidently for secrets with encryption at rest. Built it when I was trying out CLI tools that wanted API keys, but I didn’t want to shove them into my profile and accidentally upload them into my dotfiles repository. Do need to finally get back to making this a package, being able to install it with pip(x) would be really nice.<p>[0] <a href="https://github.com/belthesar/sops-run">https://github.com/belthesar/sops-run</a><p>[1] <a href="https://github.com/getsops/sops">https://github.com/getsops/sops</a>
Doesn’t this already exist as <a href="https://www.npmjs.com/package/dotenv-cli" rel="nofollow">https://www.npmjs.com/package/dotenv-cli</a> ?
I wrote my own some time ago: <a href="https://github.com/supriyo-biswas/dotfiles/commit/39585b42c24ae2d18112d142cf6081354eb29c77">https://github.com/supriyo-biswas/dotfiles/commit/39585b42c2...</a>
Since loading dotenv files happens together with executing code I I have decided to trust my .env files just like I trust the rest of my code not to delete my entire system and therefore I source them.