4 ms·

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 argument

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 configurable sub-environment for a command" and we can avoid subtle distinctions.

malicka 2y ago
Several people, including you, are proposing using env rather than sourcing; is that somehow preferable to something like this? (. .env; my-cmd)
- colimbarna 2y ago
  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.
colimbarna 2y ago
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.

malicka 2y ago

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

colimbarna 2y ago
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.

colimbarna 2y ago

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.