81–90 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
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.
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 not to confuse dependencies: appX depends on libY 1.9; appZ depends on libY 2.0; 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).
C? Y u no Rust?
The same thing already exists in Rust, it’s both a library for in-process loading and a binary, I use it daily and only for the binary: https://github.com/allan2/dotenvy
Earlier quoted context omitted.
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.
Still incredibly helpful. Therapy? Helped me a couple of times on some dark days. It’s not a replacement for it, but it helped me. Search engine? Why not? As long as you verify claims, you’re good, and especially nowadays the answers are preferable to whatever Google thinks should be on the first 10 pages (hint: it’s all crap). Cheap coding labour? Again, as long as you verify. A senior programmer can get a lot more…
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
Earlier 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.
A sourced .env would have to be correct shell syntax for a sourced environment file, yes.
I think direnv already does a good job in this space, and it's already available in your package manager. https://direnv.net/
I don't think direnv and dotenv are really the same — dotenv manages environment variables for a program, whereas direnv manages environment variables for an interactive shell. As an example of the difference, dotenv is useful for running programs inside Docker containers — which do not inherit your interactive shell's environment variables — whereas direnv isn't particularly useful there. Ditto for programs run via…
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…
The xargs idea made me think of using bash as the parser :
bash -c "exec -c bash -c 'source $CONFIG/main.bash; env'"This outputs the env vars to stdout; for the OP's purpose, the output could be sourced :
envFile=$(mktemp /tmp/env.XXXXXX);
bash -c "exec -c bash -c 'source $CONFIG/main.bash; env'" > $envFile;
env $(cat $envFile) sh -c 'echo $API_HOST'
sh -c "env -i sh -c '. $CONFIG/main.sh; env'" > $envFile
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