Vscode: Can we get a ${dirSep} variable for use in tasks.json and launch.json?

[rkeithhill]

• VSCode Version: 1.18.0
• OS Version: Windows 10 FCU

Steps to Reproduce:

1. You have a tasks.json file with a bunch of tasks and separate OS configurations for the path to the exe defined once at the top of the file.
2. In a few tasks you need to pass the path to an output dir, so you try ${workspaceFolder}/debug which works on Linux/macOS but not on Windows because the underlying utility we use (rcedit) rejects the path.

What I'd like to be able to do is specify ${workspaceFolder}${dirSep}debug and not have to worry about the vagaries of OS dir separators.

Reproduces without extensions: N/A

[dbaeumer]

Alternatively we could mark whole paths so that we can even do smarter tricks with WSL and git bash.

[webia1]

What is the current status? Path seperators are unfortunately not available in vscode/git-bash at all,.. Thank you,..

[dbaeumer]

Nothing has happened so far. As always a PR is welcome.

Regarding my comment here: https://github.com/Microsoft/vscode/issues/38381#issuecomment-344513541 this might be more complicated since this will make the variable resolving shell dependent which is currently not the case.

[culyun]

I'm looking for this feature too - specifically in launch.json. I don't know the underlying technology you're using, but isn't it the shell's job to resolve the path?

With that in mind why not intercept process creation and resolve all slash variants one way or the other using tools like cygpath. Use single quoted arguments to prevent path resolution as needed.

[stefaneidelloth]

Related:

• https://github.com/microsoft/vscode/issues/40288
• https://github.com/Microsoft/vscode/issues/40256
• https://stackoverflow.com/questions/45132566/how-to-fix-jest-no-tests-found-on-windows-10/57522638#57522638

[rioj7]

I have added this variable to the extension Command Variable (v0.6.0)

[stt]

Rather surprised how awkward vscode still is to use for Windows users. Installing and using vscode through WSL just to turn into / is too much effort IMO, and custom extensions to replace them would force everyone else using the same tasks.json to also have the extension which they didn't need in the first place.

Vscode is a great and useful tool but having people world over waste hours fighting it is rather counter productive. If WSL is truly the only way, couldn't the Windows build at the very least hint at WSL if the user is trying to use bash rather than having them discover it through years worth of github issue backlog?

[njmalhq]

Ditto @stt this issue, and its closed cohorts have been rendering vscode significantly less usable for three years. Looks like a lot more energy has gone into closing "related" bugs, rather than fixing the problem.

[culyun]

Is there any traction on this important issue. Seconding @stt + @njmalhq.