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

51–60 of 108 posts

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

#51

Post by dotancohen »

jmprspret wrote: post #18
spullara wrote: post #17

Earlier quoted context omitted.

GPT-4: The code provided has a few potential issues, including security vulnerabilities: Buffer Overflow and Memory Allocation Errors: The malloc function in read_file does not check if the memory allocation fails (it checks if buffer is NULL instead of buffer). This can lead to a null pointer dereference if malloc fails and returns NULL. There's a possibility of buffer overflow or improper handling if the file size…

GPT-4 is not a static code analyser

These LLMs are not a lot of things that people think they can use them for, apparently. Therapist, search engine, cheap coding labour, the list goes on.

These LLMs produce syntacticly valid language, no more. And information contained within is a by-product and not necessarily factual nor correct.

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

#52

Post by malicka »

colimbarna wrote: post #49
macintux wrote: post #43

Earlier quoted context omitted.

That’s reasonable, but my point stands: your original proposal is insufficient to be treated as equivalent.

env $(cat .env) my-cmd-wanting-dotenv would, though, wouldn't it? ETA: the main difference between `env` and `dotenv` seems to be that `env` gets its arguments from the command line, whereas `dotenv` gets its arguments from a file. I think that's a fair difference, but I might also think that perhaps `env` should expand its offering to include some kind of `-f filename` option so that it can focus on the notion of "a…

Several people, including you, are proposing using env rather than sourcing; is that somehow preferable to something like this?

    (. .env; my-cmd)

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

#53

Post by colimbarna »

colimbarna wrote: post #49
macintux wrote: post #43

Earlier quoted context omitted.

That’s reasonable, but my point stands: your original proposal is insufficient to be treated as equivalent.

env $(cat .env) my-cmd-wanting-dotenv would, though, wouldn't it? ETA: the main difference between `env` and `dotenv` seems to be that `env` gets its arguments from the command line, whereas `dotenv` gets its arguments from a file. I think that's a fair difference, but I might also think that perhaps `env` should expand its offering to include some kind of `-f filename` option so that it can focus on the notion of "a…

Further addition, I haven't investigated dotenv deeply, but I suppose it would be a command that specialises in making sure the contents of .env are just environmental variables that get defined. The `env` command as I wrote it is probably not the sort of thing you want to just trust on a file in a git repo shared with colleagues. Anyway, like my ETA above suggests I'm in two minds about whether env and dotenv should be the same thing with different arguments or not.

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

#54

Post by kreetx »

cortesoft wrote: post #48
TheRoque wrote: post #12

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

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.

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

#55

Post by colimbarna »

malicka wrote: post #52
colimbarna wrote: post #49

Earlier quoted context omitted.

env $(cat .env) my-cmd-wanting-dotenv would, though, wouldn't it? ETA: the main difference between `env` and `dotenv` seems to be that `env` gets its arguments from the command line, whereas `dotenv` gets its arguments from a file. I think that's a fair difference, but I might also think that perhaps `env` should expand its offering to include some kind of `-f filename` option so that it can focus on the notion of "a…

Several people, including you, are proposing using env rather than sourcing; is that somehow preferable to something like this? (. .env; my-cmd)

See my comment sibling to yours for some concerns with `env $(cat file)`; I would have these and then some with sourcing the file even in a subshell. You can do whatever you want in a shell script which can have effects outside of the subshell.

Another advantage of env is that you can type `man env` and learn something useful; sourcing and subshells via syntax is a little bit harder.

Finally, I think the major point of this branch of the discussion is to explicitly decorate a command with a special environment. Starting up a subshell isn't the same thing. It might have the same effect, but you can see that you're creating a subshell, running a builtin in the subshell, and then running a command in the subshell. It is something of a difference between declarative (dotenv/env) and imperative (sourcing in a subshell) approaches, and inherits all the pros and cons of the imperative approach.

If it works for you, I make no recommendation against it.

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

#56

Post by sureglymop »

whalesalad wrote: post #32
netcraft wrote: post #31

Earlier quoted context omitted.

I tend to agree, and we do this a lot actually. But it gets a little more complicated if you have several .env files. Would love to hear more about why dotenv is banned at your org though.

Because I banned it haha. There should not be more than one .env file. Our projects have a .env.example that has any overrides a dev might want to override but this list is kept intentionally very short. Meanwhile .env is noted in gitignore. I absolutely hate seeing an entire application configured with environment variables. Some? Sure, where it makes sense. Most? No, those should be in version control, secrets asid…

To add to that, SOME_SECRET env vars should be banned (or at least overridable) in favor of SOME_SECRET_FILE env vars. I usually just put an example of the env vars into the readme or link to the file in the source code handling that directly.

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

#58

Post by tuyiown »

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

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

#59

Post by imtringued »

forrestthewoods wrote: post #47
fyrn_ wrote: post #27

Earlier quoted context omitted.

Kubernetes / containderd / docker apps are much more convenient to configure through ENV vars, as they easily pass through the sandbox layer (whatever that may be) files are not so easy to make work. Because that's how prod works devs want to be able to recreate prod to run locally, hence the cambrian explosion of tools like this.

What a tragic state of affairs. It's a shame that running modern software requires carefully packaging a virtual environment and then injecting a bunch of ugly global env vars. I still think Docker shouldn't exist. Programs should simply bundle their dependencies. Running a program should be as simple as download, unzip, run. No complex hierarchical container management needed. Alas I am not King.

Docker is "programs bundling their dependencies".

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

#60

Post by kilroy123 »

emmanueloga_ wrote: post #28
mongol wrote: post #6

Would not sh -c '. .env; echo $MY_VAR' do the same thing? (I am not in front of a shell at the moment.)

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

I can't believe I've never thought of doing this until now.
Post reply on HN