Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Dotenv, if it is a Unix utility

github.com

Post reply on HN
Print view View original

71–80 of 108 posts

Re: Show HN: Dotenv, if it is a Unix utility

#71

Post by steezeburger »

kreetx wrote: post #54
cortesoft wrote: post #48

Earlier quoted context omitted.

What happens when, 30 commands later, you execute a command in your shell and didn't remember that message from a day or so ago?

Of you're in the directory, don't you want the env to be loaded? For me, being able to forget it is one of the features.

Not always. I can think of a scenario where I have an env I need to load for some infrastructure stuff, and I may call some commands in a directory that has another .env that's part of what I'm trying to deploy. Generally this scenario is short lived as I'm quickly moving infra commands to automated ci/cd, but I've definitely been in this scenario more than once.

Re: Show HN: Dotenv, if it is a Unix utility

#73

Post by kazinator »

tuyiown wrote: post #58

Please just see this `env -S "$(cat .env)" ` Believe it or not that’s all you need. > S, --split-string=S process and split S into separate arguments; used to pass multiple arguments on shebang lines edit: forgot the quotes around shell substitution

This is now syntax that requires processing by the shell.

The nice thing about utilities like env and dotenv is that they can be easily exec-ed:

  execl("/usr/bin/dotenv", "/usr/bin/dotenv", "command", "arg", (char *) 0);
-S is a fairly recently added option to the GNU Coreutils env (possibly inspired by BSD?). I have a window to an Ubuntu 18 VM where it's not available.

You want $(cat .env) quoted, as in "$(cat .env)" so that the content of the file is reliably passed as one argument.

-S will split on whitespace; but it respects quoting, so spaces can be protected. Basically .env has to be prepared with the features of -S in mind. Of which that thing has quite a few: escape sequences like \n, commenting, environment variable substitution.

Re: Show HN: Dotenv, if it is a Unix utility

#74

Post by kazinator »

tuyiown wrote: post #58

Please just see this `env -S "$(cat .env)" ` Believe it or not that’s all you need. > S, --split-string=S process and split S into separate arguments; used to pass multiple arguments on shebang lines edit: forgot the quotes around shell substitution

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 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.

Re: Show HN: Dotenv, if it is a Unix utility

#75

Post by kazinator »

steezeburger wrote: post #72
prmoustache wrote: post #67

I don't understand what more it does than sourcing a file on your shell would? Anyone can explain?

You can't source an .env file without some munging. All the keys would need `export` in front of them I believe.

A sourced .env would have to be correct shell syntax for a sourced environment file, yes.

Re: Show HN: Dotenv, if it is a Unix utility

#76

Post by kreetx »

steezeburger wrote: post #71
kreetx wrote: post #54

Earlier quoted context omitted.

Of you're in the directory, don't you want the env to be loaded? For me, being able to forget it is one of the features.

Not always. I can think of a scenario where I have an env I need to load for some infrastructure stuff, and I may call some commands in a directory that has another .env that's part of what I'm trying to deploy. Generally this scenario is short lived as I'm quickly moving infra commands to automated ci/cd, but I've definitely been in this scenario more than once.

Got it! I think nested envs become confusing really quickly, so there it is indeed better to do it explicitly.

My assumption overall in this is that most people have just one .env per project (or perhaps in sub-folders per environment, e.g prod, staging, local), but these don't nest. With nested .env files, the mental overhead they bring remove (IMO) most of the benefits, if not more.

Re: Show HN: Dotenv, if it is a Unix utility

#77

Post by ibotty »

tuyiown wrote: post #58

Please just see this `env -S "$(cat .env)" ` Believe it or not that’s all you need. > S, --split-string=S process and split S into separate arguments; used to pass multiple arguments on shebang lines edit: forgot the quotes around shell substitution

This will fail with comments. Of course you can script around that as well (I have done so), but it's not bulletproof. It makes sense to have a dedicated tool for the job.

Re: Show HN: Dotenv, if it is a Unix utility

#78

Post by prmoustache »

steezeburger wrote: post #72
prmoustache wrote: post #67

I don't understand what more it does than sourcing a file on your shell would? Anyone can explain?

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.
Post reply on HN