${workspaceFolder} stripped of separators

[ChrisIdema]

Environment

• OS and version: Windows 10
• VS Code: 1.70.2
• C/C++ extension:
• OS and version of remote machine (if applicable):
• GDB / LLDB version: arm-none-eabi-gdb GNU gdb (Arm GNU Toolchain 11.3.Rel1) 12.1.90.20220802-git
• openocd version: Open On-Chip Debugger 0.11.0 (2021-03-07-12:52)

Bug Summary and Steps to Reproduce

Bug Summary:

I have a project where I try to debug an nRf51 via gdb on windows: https://github.com/ChrisIdema/nrf_blinky_stlink/

When I try to debug using debug configuration nRF51 ST-link cppdbg it fails. The issue is that gdb requires absolute paths and ${workspaceFolder} is stripped of path separators.

Steps to reproduce: My launch.json file contains a configuration with the argument setupCommands. This argument needs absolute paths. I cannot use ${workspaceFolder} since that one isn't escaped in Windows. It works on Linux.

Here are paths that work:

{ "text": "-file-exec-and-symbols C:\\\\git\\\\nrf_blinky_stlink\\\\blinky\\\\build\\\\zephyr\\\\zephyr.elf", "description": "load file", "ignoreFailures": false},
{ "text": "-file-exec-and-symbols C:\\\\\\\\git\\\\nrf_blinky_stlink\\\\blinky\\\\build\\\\zephyr\\\\zephyr.elf", "description": "load file", "ignoreFailures": false},
{ "text": "-file-exec-and-symbols C:/git/nrf_blinky_stlink/blinky/build/zephyr/zephyr.elf", "description": "load file", "ignoreFailures": false},                         
{ "text": "-file-exec-and-symbols C:/git${pathSeparator}${pathSeparator}nrf_blinky_stlink/blinky/build/zephyr/zephyr.elf", "description": "load file", "ignoreFailures": false},

Here are paths that don't work:

{ "text": "-file-exec-and-symbols ${workspaceFolder}/blinky/build/zephyr/zephyr.elf", "description": "load file", "ignoreFailures": false},
{ "text": "-file-exec-and-symbols C:\\git\\nrf_blinky_stlink\\blinky\\build\\zephyr\\zephyr.elf", "description": "load file", 

As you can see separators need to be escaped twice in order to work. Once for json and once for the command line application. So even pathSeparator doesn't work unless you use it twice. Enclosing it in escaped double quotes doesn't solve the problem.

Steps to Reproduce:

1. Use a path that that doesn't work
2. Result: command line program(gdb in my case) responds with No such file or directory

I've noticed there are similar issues raised, but some of them are slightly different, outdated or closed: https://github.com/microsoft/vscode-cpptools/issues/706 https://github.com/microsoft/vscode-cpptools/issues/543

I haven't seen a solution yet (other than using git bash). So I propose the following solution: Create variants of workspaceFolder so you can convert the path of your workspace folder to have the separators you want, regardless of your operating system. For example: workspaceFolderEscaped; same as workspaceFolder, but with \ replaced with \\ or with /, on Linux it has no effect so it can also be used on Linux in theory

Debugger Configurations

https://github.com/ChrisIdema/nrf_blinky_stlink/blob/master/.vscode/launch.json
https://github.com/ChrisIdema/nrf_blinky_stlink/blob/master/.vscode/tasks.json

The configuration "nRF51 ST-link cppdbg" has the problems.

Debugger Logs

: (2305) <-1005-file-exec-and-symbols C:\git\nrf_blinky_stlink/blinky/build/zephyr/zephyr.elf
1: (2313) ->1004^done,threads=[{id="1",target-id="Remote target",frame={level="0",addr="0x00000fa6",func="??",args=[],arch="arm"},state="stopped"}]
1: (2313) ->(gdb)
1: (2313) ->&"\n"
1: (2313) ->^done
1: (2313) ->(gdb)
1: (2314) ->1005^error,msg="C:gitnrf_blinky_stlink/blinky/build/zephyr/zephyr.elf: No such file or directory."

Other Extensions

No response

Additional Information

No response

[sean-mcmanus]

@WardenGnaw ?

[WardenGnaw]

${workspaceFolder} is handled by VS Code, we use them to resolve these variables.

You will need a way for it to use the / path seperators instead of \.

[sean-mcmanus]

@WardenGnaw So the user should file a bug at https://github.com/microsoft/vscode/issues ?

[ChrisIdema]

vscode blames the extension and the extension blames vscode. Other than the ugly workaround I have no solution.

[sean-mcmanus]

@WardenGnaw Did you see https://github.com/microsoft/vscode/issues/158701 ? The VS Code team is saying it's our (the debugger's) issue. Can you explain to them how the debugger is using VS Code to resolve the variable?

[WardenGnaw]

As it is also an issue in the task.json escaping, this is pointing at a VS Code variable resolution issue.

VS Code resolves the variables in resolveDebugConfigurationWithSubstitutedVariables

[virzak]

Definitely an issue unrelated to cpp.

I have a similar issue and this is my solution. This is my ugly workaround if anyone needs it:

"windows": {
  "command": "bash myscript.sh $(echo (\\\"${workspaceFolder}\\\" -replace '\\\\', '/'))"
}

[starball5]

Also related: #908, which was kind of confusingly closed with this comment: https://github.com/microsoft/vscode-cpptools/issues/908#issuecomment-725836064:

In v1.1.0, we removed a layer that converted the launch.json to XML back to JSON which caused escaping issues in setupCommands.

Please reopen the issue if you are still experiencing this problem.

And related to #908, https://github.com/microsoft/vscode/issues/37438.

Related on Stack Overflow: https://stackoverflow.com/q/77661835/11107541, though this time with ${command:cmake.launchTargetPath} instead of ${workspaceFolder}. Someone wrote up a workaround there, but I'm more interested in what's causing the problem and how it's going to be solved for everyone.

Why is this escaping needed? what program is interpreting the backslash in the setup command as an escape character? GDB?

[tdjastrzebski]

Hi All, cmake can be one of the examples of the program which does not like backslashes in passed path params where (forward)slash is expected. This issue described here is a real pain, it is a a problem that has long been begging for a solution.

Best to my knowledge, there is no way to force VSCode to use slash (/) when substituting/emitting ${workspaceFolder} variable instead of platform specific path separator, which on Windows is backslash (\). Consequently, cmd argument value like DSOURCE_PATH=${workspaceFolder}/myproject/src on Windows will (i.e.) result in DSOURCE_PATH=C:\Temp\projects/myproject/src param being passed and then interpreted by cmake, gdb etc. as non-existent path C:Tempprojects/myproject/src.

This issue has been reported many times before and always after while is being closed as "will not fix" or "by design". https://github.com/microsoft/vscode/issues/158701, https://github.com/microsoft/vscode-cpptools/issues/9785, https://github.com/microsoft/vscode-cpptools/issues/908, https://github.com/microsoft/vscode/issues/158701, https://github.com/microsoft/vscode/issues/109300, https://github.com/microsoft/vscode/issues/70926

Please do not ask me for he details of a particular cmake command. This is irrelevant. I know for cmake it could be fixed, but no one wants to be in business of fixing cmake-built community projects before being able to run a build as VSCode task on Windows.

If some tool expects param path using slash as a separator, the param in the correct format must be provided, often there is no way around it - other than using macOS or Linux instead.

Frankly, I do not quite understand why not to add some VSCode switch to force emitting slash as a path separator substituting variables like ${workspaceFolder}. A similar VSCode option (explorer.copyRelativePathSeparator) already exists and defines a separator for copied relative file paths. Not to mention that since many version ago Windows itself (with a few exceptions) does not care which path separator (slash/backslash) is being used.

[ChrisIdema]

Exactly. Since Windows supports both separators giving people the option to use Linux separators will fix the issue once and for all.

[MickBuczek]

I guess that even one additional variable (i.e., ${workspaceFolder} equivalent but with forward slashes) would resolve many similar issues. My case is that the current ${workspaceFolder} is useless for setupCommands for arm-none-eabi-gdb on Windows.

[tdjastrzebski]

@MickBuczek It probably would. To solve this problem, typically I add a variable like myWorkspaceFolder in settings.json with current solution path hardcoded and correct slashes but I admit, such solution is awkward.

As far as I am concerned, some global workspaceFolderPathSeparator setting would be the single most appreciated VS Code improvement I can think of.