91–100 of 108 posts
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.
Earlier quoted context omitted.
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.
> Programs should simply bundle their dependencies. awww. i don't think it's OK in any way to download libc6/msvcrt as many times as I download __any__ software. even more, is there a strong difference between dependency and runtime environment? if sensible people does not bundle the whole python distribution to a "stuff.py" then why bundle libopenssl.so to a webserver application? IMO, a saner approach would be just…
Programs should rely on the global runtime environment as little as possible
> if sensible people does not bundle the whole python distribution to a "stuff.py"
Unfortunately Python deployment is such a such an unmitigated disaster that it's a leading cause of Docker images.
Deploying a portable copy of Python is about 9 megabytes compressed. This is significantly preferable to multi-gigabyte Docker images.
> people are quick to declare that appX and appZ are incompatibe as they can not run on the same system due to "conflicting dependencies". but who said you have to seach libY in /usr/lib*/libY.so? if you need different versions of a lib, just install them in separate dirs and make your apps find the right one (eg. by setting RPATH or versioned .so filenames).
You make a strong and compelling argument as to why programs should bundle their dependencies and not rely on the system environment.
Users should not have to perform any witchcraft to launch a program. Download and run. No further steps should be necessary.
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?
envup() {
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
fiYou 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.
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.
Earlier quoted context omitted.
It’s the same as forgetting you put something in your .profile or .bashrc, no? In any case, both forgetting the env config and using the same shell for days in a row seem like two things that probably don’t coincide too often.
I never close my shell, I never reboot my laptop unless necessary - an uptime of 6+ months is normal. So my experience may be different.
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
loadenv() {
set -a
source ./.env
set +a
}export $(cat .env | xargs) Agree with the premise but this can be achieved with actual Unix concepts no need for anything else. The language runtime dotenv projects are banned in my engineering org.
Your example has the downside of making the environment variables sticky, however, so it's not achieving the same thing.
source export $(cat .env | xargs)
unset $(cat .env | cut -d= -f1)
The last one unsets the environment variables that were set by the first command, ensuring they are not persisted beyond the current shell session.
If you are worried about forgetting to execute it, there are a couple of ways to work around it, depending on your case.