1) There's a few ways you could skin this proverbial cat:

option 1:

A bit python specific but you can use python-dotenv[1] for Python; and `source` that file in bash for shell support.

option 2:

Alternatively you could just pass environmental variables between applications (that's kind of the point of them).

option 3:

You could still use a dot env file and import that in other languages as TOML. This is a really nasty hacky way of doing things though because you'd need to read that file in, then prefix a key at the start of the file (eg "[vars]") to adhere to the TOML standard before you could run it through a TOML parser. I wouldn't personally recommend this approach but it would work as a lazy solution.

2) Sure there is, `envsubst`[2]

hello.tmpl:

    This is an exmaple
    Hello, ${HELLO_NAME}!

hello.env:

    HELLO_NAME="wodenokoto"

hello.sh:

    #!/bin/sh

    source hello.env
    envsubst < hello.tmpl > hello.txt

Run hello.sh and it will create a file called hello.txt:

    This is an exmaple
    Hello, wodenokoto!

One caveat is that this is part of the gettext package which doesn't always ship with every distro. But it's a pretty small package (small enough that I don't have any issue installing it into a docker container for one CI pipeline).

[1] https://pypi.org/project/python-dotenv/

[2] https://linux.die.net/man/1/envsubst

> just pass environmental variables between applications

That would require me to 1) somehow ensure that shell is sourcing the the environment variables from a file, and 2) we are back to all the hackery mentioned in the article [1]

[1] https://wiki.bash-hackers.org/howto/conffile

You don't need a shell script to initialise an application with specific environmental variables. systemd and docker will both do this (and both supports the same env file too). AWS lambda supports environmental variables, so does most CI/CD solutions. It's a pretty standard way to do things in UNIX/Linux. In fact if you're having to resort to "hacks" to get environmental variables loaded then that might be a symptom of a bigger problem with your orchestration rather than an issue with Bash / Python.

Also that was just one of three options I listed; and there will be a plethora of other alternatives I've not mentioned too.

Thank you for your patience in answering my woes.

You’ve given me a lot of food for thought and some good ideas on how to attack some of my problems.

Maybe I’m misunderstand the points here but shouldn’t point 1 be covered by environment variables mostly?

And for point 2, basically the same thing, you can set variables to have a default value and then try to read the environment.

export variable=${variable:-“some_default”}