Unquoted values cannot contain spaces

[onbjerg]

Every .env package I know of for e.g. Node.js, and the OG .env Ruby gem parses the following file correctly:

ABC=foo bar

where $ABC would be foo bar, but it seems to not be the case for dotenv or dotenvy unless you quote the value (see https://github.com/foundry-rs/foundry/issues/2610)

[allan2]

Every .env package I know of for e.g. Node.js, and the OG .env Ruby gem parses the following file correctly:

Funnily, each implementation has their own interpretation of what it means to be correct. More on that below.

An example illustrating the differences between dotenv in Ruby, JS, and Rust

.env

A=foo bar
B="notenough
C='toomany''
export NOT_SET

Ruby:

require 'dotenv/load'  # loading will fail. `Line "export NOT_SET" has an unset variable`
# Output below is with the the fourth line removed.
puts ENV['A']  # foo bar
puts ENV['B']  # "notenough
puts ENV['C']  # toomany'

JS:

const result = require('dotenv').config()  // loading is fine
if (result.error) {
    throw result.error
}
console.log(process.env.A)  // foo bar
console.log(process.env.B)  // "notenough
console.log(process.env.C)  // toomany'

Rust:

use dotenvy::dotenv;  // or dotenv::dotenv

fn main() {
    dotenv().unwrap();  // every single line is a parsing error
}

The dotenv and dotenvy crates are stricter than the Ruby and Node implementations. I'm inclined to leave things as-is since the solutions for values with whitespace are well-understood, i.e. quoting and escaping.

I do think documentation illustrating these differences will be useful though and I will get on that!

[polarathene]

dotenvs is an alternative Rust crate (uses nom to parse), which seems decent to reference.

• It matches the JS output, except for toomany (which omits the trailing ').
• I did notice it trips up on any valid line that has the C or unset export lines preceding it, no error raised which isn't good.

There's also the Rust project dotenv-linter, which might be relevant as a reference of what a linter considers valid? They have their own dotnet-lookup crate as another dotenv file parser, but presently only for internal use instead of publishing it to share with the community.

[aidenfarley]

Is this issue good to be closed?

[onbjerg]

I don't have anything against it being closed, up to the maintainers if they want to keep the behavior as-is or not