Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unquoted values cannot contain spaces #11

Open
onbjerg opened this issue Aug 22, 2022 · 4 comments
Open

Unquoted values cannot contain spaces #11

onbjerg opened this issue Aug 22, 2022 · 4 comments

Comments

@onbjerg
Copy link

onbjerg commented Aug 22, 2022

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 foundry-rs/foundry#2610)

@allan2
Copy link
Owner

allan2 commented Aug 23, 2022

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
Copy link

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.

huonw added a commit to pantsbuild/pants that referenced this issue Nov 3, 2023
This fixes #20127 by avoiding double quotes in the `.env` file generated
by the code snippet in the IDE set-up docs.

Double quotes aren't supported by the `scie-pants` `.env` loader, and a
line containing them was previously silently ignored (plus all lines
after), but with scie-pants 0.11.0, will be an error. See
pantsbuild/scie-pants#307 and
pantsbuild/scie-pants#319.

The new suggestion has _no_ quotes at all, because there's no other way
to have a line that includes a substitution. To handle source roots with
spaces in their paths, this has to also manually escape them. Supporting
double quotes is effectively a new feature of `scie-pants` launcher (via
scie jump a-scie/jump#166 via `dotenvy`
allan2/dotenvy#11), but for now we can at
least stop suggesting incorrect things.

For instance, with source roots `a b/c` and `def`, this generates:

```
PYTHONPATH=./a\ b/c:./def:$PYTHONPATH
```
WorkerPants pushed a commit to pantsbuild/pants that referenced this issue Nov 3, 2023
This fixes #20127 by avoiding double quotes in the `.env` file generated
by the code snippet in the IDE set-up docs.

Double quotes aren't supported by the `scie-pants` `.env` loader, and a
line containing them was previously silently ignored (plus all lines
after), but with scie-pants 0.11.0, will be an error. See
pantsbuild/scie-pants#307 and
pantsbuild/scie-pants#319.

The new suggestion has _no_ quotes at all, because there's no other way
to have a line that includes a substitution. To handle source roots with
spaces in their paths, this has to also manually escape them. Supporting
double quotes is effectively a new feature of `scie-pants` launcher (via
scie jump a-scie/jump#166 via `dotenvy`
allan2/dotenvy#11), but for now we can at
least stop suggesting incorrect things.

For instance, with source roots `a b/c` and `def`, this generates:

```
PYTHONPATH=./a\ b/c:./def:$PYTHONPATH
```
WorkerPants pushed a commit to pantsbuild/pants that referenced this issue Nov 3, 2023
This fixes #20127 by avoiding double quotes in the `.env` file generated
by the code snippet in the IDE set-up docs.

Double quotes aren't supported by the `scie-pants` `.env` loader, and a
line containing them was previously silently ignored (plus all lines
after), but with scie-pants 0.11.0, will be an error. See
pantsbuild/scie-pants#307 and
pantsbuild/scie-pants#319.

The new suggestion has _no_ quotes at all, because there's no other way
to have a line that includes a substitution. To handle source roots with
spaces in their paths, this has to also manually escape them. Supporting
double quotes is effectively a new feature of `scie-pants` launcher (via
scie jump a-scie/jump#166 via `dotenvy`
allan2/dotenvy#11), but for now we can at
least stop suggesting incorrect things.

For instance, with source roots `a b/c` and `def`, this generates:

```
PYTHONPATH=./a\ b/c:./def:$PYTHONPATH
```
huonw added a commit to pantsbuild/pants that referenced this issue Nov 3, 2023
…20146)

This fixes #20127 by avoiding double quotes in the `.env` file generated
by the code snippet in the IDE set-up docs.

Double quotes aren't supported by the `scie-pants` `.env` loader, and a
line containing them was previously silently ignored (plus all lines
after), but with scie-pants 0.11.0, will be an error. See
pantsbuild/scie-pants#307 and
pantsbuild/scie-pants#319.

The new suggestion has _no_ quotes at all, because there's no other way
to have a line that includes a substitution. To handle source roots with
spaces in their paths, this has to also manually escape them. Supporting
double quotes is effectively a new feature of `scie-pants` launcher (via
scie jump a-scie/jump#166 via `dotenvy`
allan2/dotenvy#11), but for now we can at
least stop suggesting incorrect things.

For instance, with source roots `a b/c` and `def`, this generates:

```
PYTHONPATH=./a\ b/c:./def:$PYTHONPATH
```

Co-authored-by: Huon Wilson <[email protected]>
huonw added a commit to pantsbuild/pants that referenced this issue Nov 3, 2023
…20145)

This fixes #20127 by avoiding double quotes in the `.env` file generated
by the code snippet in the IDE set-up docs.

Double quotes aren't supported by the `scie-pants` `.env` loader, and a
line containing them was previously silently ignored (plus all lines
after), but with scie-pants 0.11.0, will be an error. See
pantsbuild/scie-pants#307 and
pantsbuild/scie-pants#319.

The new suggestion has _no_ quotes at all, because there's no other way
to have a line that includes a substitution. To handle source roots with
spaces in their paths, this has to also manually escape them. Supporting
double quotes is effectively a new feature of `scie-pants` launcher (via
scie jump a-scie/jump#166 via `dotenvy`
allan2/dotenvy#11), but for now we can at
least stop suggesting incorrect things.

For instance, with source roots `a b/c` and `def`, this generates:

```
PYTHONPATH=./a\ b/c:./def:$PYTHONPATH
```

Co-authored-by: Huon Wilson <[email protected]>
@aidenfarley
Copy link

Is this issue good to be closed?

@onbjerg
Copy link
Author

onbjerg commented Apr 18, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants