4 ms·
On my phone so can’t double test, but can’t you get this by adding “export” in front of every line in your env file and then source before running command? I s
by wodenokoto 2y ago
On my phone so can’t double test, but can’t you get this by adding “export” in front of every line in your env file and then source before running command?
I suppose if you don’t want it to stay after execution i believe you can:
> $(source .env; my command)
I’m sure there is a fairly straightforward way to encrypt and decrypt a local file
- bogdan 2y agohttps://github.com/getsops/sops https://github.com/getsops/sops
- newzisforsukas 2y agoBeing able to source the file is the main benefit of using a .env file, IMO. Otherwise, you can just use any format for config management.
- ruined 2y agodotenv has features that include conditional selection and ordered merging of env files, which are configurable by dotenv's runtime and buildtime APIs.
- wodenokoto 2y agoAt least merging can happen by sourcing .env files in order (last to be sourced has priority) But I do agree that at some point you want a tool to orchestrate these things and guide your usage so you don’t have to reinvent the same lines of code all the item
- eternauta3k 2y agoNow take that a step further with Environment Modules and you can source them from any shell or scripting language: https://modules.readthedocs.io/ https://modules.readthedocs.io/ (without creating a subinterpreter)
- gkfasdfasdf 2y agoIf in bash, you can use the 'allexport' option and source the .env without having to add 'export' in front of every line: #!/bin/bash set -o allexport . .env set +o allexport cmd
- politelemon 2y agoTIL thanks!