4 ms·

I always treated .env files as "this is the current set of environment variables", containing just NAME="value" pairs. If there are _different_ sets of variabl

I always treated .env files as "this is the current set of environment variables", containing just NAME="value" pairs. If there are _different_ sets of variables, they should not be in that file, but in some different place, like the suggested settings.toml. Or perhaps use a bunch of different files in .envs/whatever.env and symlink them. Let's not make everything complicated :)

noselasd 4y ago
And the nice thing about those NAME="value" pairs is you can now source it directly in shells, or read it with some straight forward, usually built in library in many programming languages and supporting tools
- meitham 4y ago
  Until the value has a bang or any other special character that ends up being expanded by the shell and wasting half a day finding it!
  - lelanthran 4y ago
    > Until the value has a bang or any other special character that ends up being expanded by the shell and wasting half a day finding it! Just how large are your env files?
    - meitham 4y ago
      It's not the size, it's the content of the values in the env files when they contain things outside of your control, like a password with a bang or a dollar sign.
capableweb 4y ago
Hear hear! The author claims "There is no standard" but I think the standard is so simple it hasn't been written down. The standard is what you said, KEY="value" and that's it. Simple, easy to parse, fast and compatible with how environment variables are declared in `/etc/environment` since forever. Having different .env files for different OSes is easy as well. You have one `.env` that provides the default values, then `.env.linux` for linux, `.env.windows` for windows and so on, and on runtime, first read .env, have values from .env.$os overwrite those, and finally have whatever the actual environment has overwrite those. Again, simple and hard to misunderstand.
- jepler 4y ago
  I wish the 'dotenv' configuration language was so simple that it need not be written down! An off-hand comment (also cited by Brett) says that python-dotenv files "should mostly look like Bash files". Sadly, the vague implication that there's a highly compatible, at-least-ascii-safe subset of dotenv files and bash files is .. very far from the truth. Here's a line of bash code that sets the variable X to a single-quote character: X=''\''' (lest you think that's an unduly obtuse way to do it, this is what `git rev-parse --sq-quote` does! If not 'best practice' it's surely at least 'practice that's gotta be supported'!) Here's what python-dotenv gets: Python-dotenv could not parse statement starting at line 1 Similarly, when you use python-dotenv to set a key with the value containing only the single quote dotenv.set_key('.env', 'X', "'") the file is not acceptable to bash: bash: .env: line 1: unexpected EOF while looking for matching `''
  - capableweb 4y ago
    Sounds like a problem of python-dotenv rather than a problem with environment variables. Env vars have been around forever, it's has well established syntax at this point, that X tool doesn't handle it properly doesn't mean the format is wrong.
Towaway69 4y ago
I have had situations where name="value" will give me ""value"" (I.e double double-quotes) in some languages and others give me just the value. It's even more confusing if the value contains a space. It is definitely not consistent.
- tough 4y ago
  You can try using ' instead

noselasd 4y ago

And the nice thing about those NAME="value" pairs is you can now source it directly in shells, or read it with some straight forward, usually built in library in many programming languages and supporting tools

meitham 4y ago
Until the value has a bang or any other special character that ends up being expanded by the shell and wasting half a day finding it!
- lelanthran 4y ago
  > Until the value has a bang or any other special character that ends up being expanded by the shell and wasting half a day finding it! Just how large are your env files?
  - meitham 4y ago
    It's not the size, it's the content of the values in the env files when they contain things outside of your control, like a password with a bang or a dollar sign.

capableweb 4y ago

Hear hear! The author claims "There is no standard" but I think the standard is so simple it hasn't been written down. The standard is what you said, KEY="value" and that's it. Simple, easy to parse, fast and compatible with how environment variables are declared in `/etc/environment` since forever. Having different .env files for different OSes is easy as well. You have one `.env` that provides the default values, then `.env.linux` for linux, `.env.windows` for windows and so on, and on runtime, first read .env, have values from .env.$os overwrite those, and finally have whatever the actual environment has overwrite those. Again, simple and hard to misunderstand.

jepler 4y ago
I wish the 'dotenv' configuration language was so simple that it need not be written down! An off-hand comment (also cited by Brett) says that python-dotenv files "should mostly look like Bash files". Sadly, the vague implication that there's a highly compatible, at-least-ascii-safe subset of dotenv files and bash files is .. very far from the truth. Here's a line of bash code that sets the variable X to a single-quote character: X=''\''' (lest you think that's an unduly obtuse way to do it, this is what `git rev-parse --sq-quote` does! If not 'best practice' it's surely at least 'practice that's gotta be supported'!) Here's what python-dotenv gets: Python-dotenv could not parse statement starting at line 1 Similarly, when you use python-dotenv to set a key with the value containing only the single quote dotenv.set_key('.env', 'X', "'") the file is not acceptable to bash: bash: .env: line 1: unexpected EOF while looking for matching `''
- capableweb 4y ago
  Sounds like a problem of python-dotenv rather than a problem with environment variables. Env vars have been around forever, it's has well established syntax at this point, that X tool doesn't handle it properly doesn't mean the format is wrong.

Towaway69 4y ago

I have had situations where name="value" will give me ""value"" (I.e double double-quotes) in some languages and others give me just the value. It's even more confusing if the value contains a space. It is definitely not consistent.

tough 4y ago
You can try using ' instead