Hacker News new | past | comments | ask | show | jobs | submit login

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 <.env)'
source: [1]

--

1: https://stackoverflow.com/a/60406814/855105


That will break if there's comments in the file, or if any one of the variables' values contain spaces. You can use `set -a` to load .env into an existing shell instance instead:

    loadenv() {
        set -a
        source ./.env
        set +a
    }


Cool! This answers a question someone had in this thread.

... except I'm thinking this may `set +a` if the environment already had `set -a`, which maybe could cause problems? I wonder if it would make sense to record the existing status of "-a" (allexports) an set it / unset it as necessary.


You could do that, and it'd still be POSIX-shell comptible:

    loadenv() {
        case "$-" in
            *a*) source ./.env ;;
            *) set -a; source ./.env; set +a ;;
        esac
    }
Although I have yet to see a long shellscript utilise `set -a` globally :)


Very nice! Thanks for the suggestion. Seems more Unix-esque. Are there any important drawbacks of this version compared to the dedicated tool? (dotenv or dotenvx)


I can't believe I've never thought of doing this until now.


You'd need to `set -a` or pass the `-a` as a flag to have them auto-exported though, so:

    sh -ac '. ./.env; ./prog'
Also if you use the `.` builtin it's a good idea to specify the path with a slash in it, so that `.` doesn't search $PATH first.


That would, but unless each line in your .env file is prefixed with "export", those env vars won't get passed into any subprocesses you run.


Now that is unixy!


Seems to work.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: