.env doesn't load at all on Windows

[webbertakken]

I've used dotenv packages in many languages, but this time I got quite confused.

Reason:

1. It doesn't load the .env file at all on windows. (fully reproducible) (branch dotenvy)
2. It's completely silent, so no errors are shown whatsoever. (addressed in https://github.com/dotenv-rs/dotenv/issues/73)

Stacktrace:

I've added .expect("Failed to load .env file") instead of ok() which yields the following output:


```console Finished dev [unoptimized + debuginfo] target(s) in 0.04s Running `C:\Users\Webber\Repositories\learning-rust\ultimate-rust-2\target\debug\frogger.exe` thread 'main' panicked at 'Failed to load .env file: LineParse("\u{feff}RUST_LOG=trace", 0)', exercise\logging\src\main.rs:12:14 stack backtrace: 0: rust_begin_unwind at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library\std\src/panicking.rs:584:5 1: core::panicking::panic_fmt at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library\core\src/panicking.rs:142:14 2: core::result::unwrap_failed at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library\core\src/result.rs:1814:5 3: core::result::Result::expect at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52\library\core\src/result.rs:1064:23 4: frogger::main at .\src\main.rs:12:5 5: core::ops::function::FnOnce::call_once at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52\library\core\src\ops/function.rs:248:5 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. error: process didn't exit successfully: `C:\Users\Webber\Repositories\learning-rust\ultimate-rust-2\target\debug\frogger.exe` (exit code: 101) ```

It seems that this is caused by a Zero Width No-Break Space (BOM, ZWNBSP) character: https://www.compart.com/en/unicode/U+FEFF at the start of the file (which isn't visible in the editor.

I can confirm that removing the BOM character fixes the issue.

[allan2]

The error is there but .ok() discards it.

UTF-8 with BOM is not supported in this crate. I don't think it should be because BOM in UTF-8 is not recommended by the Unicode spec.

You'll have to remove the character.

[webbertakken]

UTF-8 with BOM is not supported in this crate. I don't think it should be because BOM in UTF-8 is not recommended by the Unicode spec.

Nobody is asking you to "support" writing new files as BOM (nor is the answer you're referring to suggesting that). But you also can't expect users to know what BOM is in the first place. Windows users can't help Windows creating the .env file like that. That's how the OS presented the file to me when creating it in Rider (my IDE). In the editor the character isn't even visible. I had to look up how to manually remove it. See also the second answer on the same question about ignoring the sequence (more relevant to reading files).

Respectfully disagree with your assessment. I consider the package erroring over a BOM character to be a needless bug and I don't see why the library couldn't strip it or ignore it, or convert to the desired encoding.

[allan2]

Thanks for the helpful reply! I agree now that ignoring the BOM makes sense.

[mrtolkien]

This is marked as completed, but has it been fixed? I still can't seem to get it to work on Windows, and there's no BOM character in my file.

EDIT: This was indeed not linked to a BOM character in my file but to \ and %20 in paths being buggy in windows, my bad. The .env file did get read mostly properly.