Path translation missing when launching NT Processes with Arguments

[dimenus]

Win 10 Professional : [Version 10.0.16232.1000]

WSL doesn't seem to do any translation of arguments passed to an NT process. I would expect it to. Is this intended? MSYS2 for example, does translate arguments. See the screenshots below along with MRE code.

#include <stdio.h>
int main(int argc, char const *argv[])
{
	for(int i = 0; i < argc; ++i) {
		printf("arg[%d]: %s\n", i, argv[i]);
	}
	return 0;
}

[benhillis]

Thanks for posting. Investigating this is on my backlog of future interop improvements.

[iz0eyj]

@benhillis:
Would it be possible to have a switch (environment variable?) Telling the WSL to handle all "/" as if they were "\" in system calls? This might solve the problem once and for all.
I realize that it would not be a standard solution, but not even the use of "\" in the paths was a brilliant choice, so ...

[Lyncredible]

I would like to use the Windows version of Sublime Text as my git editor, and this feature would be super helpful. Currently it does not work because Sublime doesn't understand how to save a file to /mnt/c/...

I also want to do atom . or code . to launch Atom/VS Code editors using current working directory as an project. That is not possible today.

[luser]

Speaking from years of experience doing Firefox builds inside an msys shell (and cygwin before that), I can say that automatic path translation is more of a headache than it's worth. It's really hard to get right, and when it doesn't work it's super frustrating. As a simple example, this issue is about passing -I/mnt/c/... to cl.exe. For that to be translated properly the system would have to know how to parse cl.exe's commandline arguments!

I'm currently working on getting the Firefox build working inside of WSL, invoking cl.exe and other tools from WSL bash. It's much easier to make things work without any magic path translation--I just convert the paths in places I need to Windows format, or use relative paths wherever possible (because those will work fine in both environments).

So consider this a vote against doing this, or at the very least making it opt-in.

[Brian-Perkins]

Windows Insider Build 17046 contains new 'wslpath' functionality that supports path translations. See the release notes for more details.