# inside double quotes still treated as inline comment

[Devtronyx]

v14.2.0
SOME_KEY={"field1":"some value", "field2": "stops here#this is discarded"}
When above line is parsed generates the following output
SOME_KEY: {"field1":"some value", "field2": "stops here
which in turns gives a SyntaxError: Unexpected end of JSON input

[motdotla]

Thank you for raising this. We are looking into it. Anyone else this is happening to, please +1.

[jonathan-reisdorf]

@Devtronyx interesting. In this case, even though it's a json this is read as a string. You'd have to quote the entire value in order to properly parse this (in your case since you already use the double quotes I suggest to use the single ones as wrapper):

SOME_KEY='{"field1":"some value", "field2": "does not stop here#this is not discarded"}'

[kirillgroshkov]

Broke us too.

I don't know though what's more "correct" behavior - to require a space before # to treat it as comment or not.

[jonathan-reisdorf]

Quick collection of patterns I noticed in other tools since yesterday:

vscode: syntax highlighting suggests: unquoted # is treated as comment, with or without space

Github: seems to look for space character

FOO=bar#baz
FOO=bar #baz
FOO="bar#baz"
FOO="bar #baz"
FOO='bar#baz'
FOO='bar #baz'

python-dotenv started out where we are but with version 0.10.3 they introduced a check for space character

unix (GNU coreutils) env I've already shared here: #568 (comment)

@kirillgroshkov you wrote "Broke us too". Did you mean that you were also using unquoted json in your .env and it broke and you were expecting it not to break, or in general that you had to adapt your .env because of the recent change because you had an unquoted string with # in it?

I'm wondering if perhaps I should have mentioned the change also here: https://github.com/motdotla/dotenv#what-rules-does-the-parsing-engine-follow 🤔

[mrliptontea]

Just ran into this. It's very common for generated secrets to include # so something like:

VAR_WITH_SPECIAL_CHARS=space slash/other@#1!=

But unfortunately:

--- Expected
+++ Received

 {
-  VAR_WITH_SPECIAL_CHARS: "space slash/other@#1!="
+  VAR_WITH_SPECIAL_CHARS: "space slash/other@"
 }

[motdotla]

@mrliptontea yes, it is very common. We are working on the long term solution for this. Until then, you can do:

1. Put quotes (single or double) around the value. Example: VAR_WITH_SPECIAL_CHARS="space slash/other@#1!="
2. Downgrade to 13.x for now

P.S. If option 1 is a hassle because you have a large team that would all need to update their .env files with quotes, consider using https://sync.dotenv.org. It streamlines the syncing process of .env files between your team members. You will no longer need a .env.example file.

[jonathan-reisdorf]

@mrliptontea even Github highlights the #1!= part of your example as a comment 😬

@motdotla given that the change seems to have broken things for so many, I've created a new PR: #603

[motdotla]

Thank you @jonathan-reisdorf.

Patch is in 14.3.2 https://github.com/motdotla/dotenv/blob/master/CHANGELOG.md#1432-2022-01-25

[motdotla]

So patch is in 14.3.2 with thanks to @jonathan-reisdorf.

That said.. v15.0.0 IS going to implement the rule (and breaking change):

# marks the beginning of a comment (unless when the value is wrapped in quotes)

So our recommendation is to start quoting any values containing #. I'm sorry about that. I realize it is an annoyance. We really went back and forth deliberating this one. Long term we think it drives clarity of behavior and we're updating our README examples to use quotes - so that the muscle memory becomes more likely.

PR is here #608 and will likely go out as a release tomorrow or the next day.

[rmclaughlin-nelnet]

@motdotla According to OWASP a password can contain any of the following characters https://owasp.org/www-community/password-special-characters. How do you suggest storing passwords, in a way that dotenv can correctly parse them?