unquoted .env vars with spaces not parsed correctly

[devanoneth]

Component

Forge

Have you ensured that all of these are up to date?

• [X] Foundry
• [X] Foundryup

What version of Foundry are you on?

9b0575e 2022-08-04T00:10:43.515642Z

What command(s) is the bug in?

forge script

Operating System

macOS (Intel)

Describe the bug

I have a .env file in the root of my project, and it contains RPC_URL=XXX.

When running vm.createSelectFork(vm.envString("RPC_URL")); in a script, I get the error:

VM::envString("RPC_URL")
    │   └─ ← "environment variable not found"

I expected that this would work. Is this not the expected use?

Of course before Foundry shipped dotenv support, I was using my solenv library and it worked fine.

Thanks!

[onbjerg]

Where are you running forge script? I can't reproduce it: this works fine for me.

FOO=bar

in .env in root of project

forge script script/Contract.s.sol

executes fine and it contains this line:

vm.envString("FOO")

Edit: Also added a contract with a function that takes the string and returns it back, and it works as expected:

[devanoneth]

Okay, I debugged it a bit more and found out it's because I had a variable set above RPC_URL which has spaces in it. I realized variables with spaces are not parsed correctly, they need to be wrapped in quotes.

FYI, in the very commonly used dotenv package for NodeJS, it parses anything after the = until a line break. I guess the dotenv rust crate parses it differently. I just wouldn't be surprised if this stumps other developers who are so used to the JS ecosystem around Ethereum. Maybe worth adding an example .env to the book or template?

[onbjerg]

Wow, that's very surprising to me. I think I should just look for another .env crate because that is part of the actual "spec" and every other .env package supports that

Thanks for debugging :)

[Genysys]

I think we solved something similar in the telegram chat by adding an export to env vars .i.e export FOO=BAR

https://t.me/foundry_support/19661

[onbjerg]

@Genysys This was before .env was supported - now .env autoloads and works w/o having to source it manually :smile:

[onbjerg]

Closing as a wontfix since there are no .env crates that support this currently, will revisit if one pops up, otherwise we are just going to document this behavior.