Windows paths surprising - Erlang interprets paths differently than the cmd.exe shell or WSL bash

Questions / Help
1

While investigating a failed local win32 build, I found that Erlang interprets paths differently than the cmd.exe shell or WSL bash. These path glitches are significant to application developers as well as Erlang devs I believe—it could be documented, or maybe even worthy of improving in the win32 file implementation?

Comparing Erlang and bash:

erl:

> file:set_cwd("/mnt/c/Users/spam").
{error,enoent}

> file:set_cwd("/Users/spam").
ok

> file:set_cwd("c:/Users/spam").
ok

> file:set_cwd("c:\\Users\\spam")
ok

bash:

# ls -d /mnt/c/Users/spam
/mnt/c/Users/spam

# ls -d /Users/spam
ls: cannot access '/Users/spam': No such file or directory

# ls -d c:/Users/spam
ls: cannot access 'c:/Users/spam': No such file or directory

# ls -d c:\\Users\\spam
ls: cannot access 'c:\Users\spam': No such file or directory

Erlang only misses one case “/mnt/c/Users/spam” but it happens to be the only one recognized by WSL bash. I’m proposing that we make the file module more robust by correctly interpreting that style of path.

As an example of why this matters to real users, I ran into this bug when running make test from bash in a Windows directory under /mnt/c/ with ERL_TOP set to start with this path. It starts well, but Erlang eventually crashes in a test script when attempting file operations:

Error! Failed to eval: ts:compile_datadirs(“/mnt/c/Users/spam/erlang-otp/lib/common_test/test_server/variables…”,“*_SUITE_data”).

My workaround was to symlink ln -s /mnt/c/Users /Users and then set ERL_TOP to begin with “/Users/…” which is obscure enough that I’m suspecting there’s something wrong with how I created my local environment.

1 Like
2

When doing stuff in wsl you need to keep track if you are running the windows erl.exe or the unix erl binary.

If you run windows executable erl.exe you are in windows land and there is no path “/mnt/c/Users/spam” on windows, i.e. in cmd.exe you can’t go to /mnt/c/Users/spam.

If you run the unix erl executable you are running in unix land and thus there is no
C:/Users/spam only the mounted /mnt/c/Users/Spam.

2 Likes
3

Thanks, that helps me understand—so my issue is very niche and has to do with attempting to cross-compile and test the windows executable from inside of WSL, most users of erl.exe will only be interacting with the other path styles.

I’ll see if I can write a small patch to take advantage of w32_path.sh when test scripts pass a path to erl.exe .

1 Like