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.
Show HN: Dotenv, if it is a Unix utility
101–108 of 108 posts
Re: Show HN: Dotenv, if it is a Unix utility
#102Earlier quoted context omitted.
Also, if we are going to involve the shell, we could also just make .env a shell fragment and do this: sh -c '. .env; ' 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…
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//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.
Re: Show HN: Dotenv, if it is a Unix utility
#103I just remembered. Adding a -f option to the GNU Coreutils env utility has previously been discussed:
https://lists.gnu.org/archive/html/coreutils/2021-10/msg0000...
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//env:
https://lists.gnu.org/archive/html/coreutils/2024-03/msg0014...
If that feature were available, this becomes
env -f .env command arg ...Re: Show HN: Dotenv, if it is a Unix utility
#104I think direnv already does a good job in this space, and it's already available in your package manager. https://direnv.net/
I‘m a happy user of direnv. Hard to imagine my life without it. The only problem is not to forget to include it to .gitignore.
Re: Show HN: Dotenv, if it is a Unix utility
#105Earlier quoted context omitted.
There are like a couple dozen different ways to do this... I have this on my .bashrc: alias loadenv='export $(xargs source: [1] -- 1: https://stackoverflow.com/a/60406814/855105
That will break if there's comments in the file, or if any one of the variables' values contain spaces. You can use `set -a` to load .env into an existing shell instance instead: loadenv() { set -a source ./.env set +a }
Cool! This answers a question someone had in this thread.
... except I'm thinking this may `set +a` if the environment already had `set -a`, which maybe could cause problems? I wonder if it would make sense to record the existing status of "-a" (allexports) an set it / unset it as necessary.
Re: Show HN: Dotenv, if it is a Unix utility
#106Earlier quoted context omitted.
As far as I'm aware of, Direnv's behavior is not hidden at all. Whenever you cd into the directory, you get a message listing all the new en var activated. And when you change the .envrc, you get another message saying that direnv has been deactivated. I never had happen to me "oh shoot !! I forgot this env var was activated because I'm in this dir".
I don't think "hidden" and "explicit" are true antonyms. From your description, direnv is implicit and noisy, whereas dotenv seems to be (unless you embed it in a script) explicit and quiet.
Well basically, you cd in the shell, and then it shows:
"direnv: loading ~/dev/foo/.envrc
direnv: export +DATABASE_URL"
Is this "implicit" to you ? Because to me it's pretty explicit. But yeah it's automatic, if you don't want this behavior, you don't install direnv. Just to be clear, implicit is "suggested but not communicated directly", and to me, this is communicated directly, so I don't see why it would be implicit...
Re: Show HN: Dotenv, if it is a Unix utility
#107Earlier quoted context omitted.
You can't source an .env file without some munging. All the keys would need `export` in front of them I believe.
That doesn't seem like a huge barrier compared to shipping a dotenv binary compiled specifically to all deployment arch.
It's not a huge barrier, but it's still a barrier. I have lots of infra using Helm/K8s, sometimes Docker. These .env files don't have `export` keywords in them.
So your suggestion is to munge these for local development. And you're okay with that barrier? That's terrible dx, and it adds surface area for bugs.
Re: Show HN: Dotenv, if it is a Unix utility
#108Earlier quoted context omitted.
That will break if there's comments in the file, or if any one of the variables' values contain spaces. You can use `set -a` to load .env into an existing shell instance instead: loadenv() { set -a source ./.env set +a }
Cool! This answers a question someone had in this thread. ... except I'm thinking this may `set +a` if the environment already had `set -a`, which maybe could cause problems? I wonder if it would make sense to record the existing status of "-a" (allexports) an set it / unset it as necessary.
You could do that, and it'd still be POSIX-shell comptible:
loadenv() {
case "$-" in
*a*) source ./.env ;;
*) set -a; source ./.env; set +a ;;
esac
}