\" doesn't work correctly in tasks.json

[imba-tjd]

My OS: Windows LTSB 2015 x64
VS Code Version: 1.14.2

When the path doesn't contain a space, it can be compiled normally.
When the path contains a space, I try to use \" in tasks.json to make the path a string, but it is useless. Just the same as no \".
Forget that red wavy line because I didn't configure c_cpp_properties.json.

[Lixire]

Does it work if you move \"${file}\" to args:?

[imba-tjd]

Nope, it has no change.

[dbaeumer]

@imba-tjd which shell are you using. Cmd, PowerShell or bash ?

[imba-tjd]

@dbaeumer powershell.
Besides, just now I type "terminal.external.windowsExec": "C:\\Windows\\System32\\cmd.exe in settings.json. Then I press ctrl+`, but it still shown powershell in terminal. Is this correct? = =

[dbaeumer]

@imba-tjd the setting to control the integrated shell to use is: "terminal.integrated.shell.windows"

[dbaeumer]

@imba-tjd where is gcc installed ?

[imba-tjd]

@dbaeumer Actually, I installed Clang 4.0.1 pre-build version for windows x64 and MinGW-w64 7.1.0. And merge mingw into clang's directory. So the path of gcc is c:\llvm\bin. My host system is 1703, virtual system is ltsb 2015. VS Code version is 1.15.1. I can still reproduce this problem by running task. But if I manually type the command in terminal, it works fine from the beginning.

But personally I don't think this issue is connected to any external program or extensions. Because even I create this program:

using System;

namespace PrintPara
{
    class Program
    {
        static void Main(string[] args)
        {
            foreach (var item in args)
            {
                Console.WriteLine(item);
            }
        }
    }
}

And in tasks.json I write:

{
    "version": "2.0.0",
    "tasks": [
        {
            "taskName": "Compile",
            "command": ".\\printpara.exe",
            "type": "shell",
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "args": [
                "\"${file}\""
            ]
        }
    ]
}

The result is still the same. It will split the argument by sapces and ignore quotes.

[dbaeumer]

This works for me with a simple dir command executed in cmd.exe. The example is

tasks.json

{
	// See https://go.microsoft.com/fwlink/?LinkId=733558
	// for the documentation about the tasks.json format
	"version": "2.0.0",
	"tasks": [
		{
			"taskName": "dir",
			"type": "shell",
			"command": "dir",
			"args": [
				"\"${file}\""
			]
		}
	]
}

Where $file is in a directory with space.

However it doesn't work with PowerShell. @imba-tjd which shell are you using: cmd, PowerShell or same bash implementation?

[dbaeumer]

@imba-tjd just saw that you are using PowerShell. Need to understand what makes this different under PowerShell.

[dbaeumer]

You can configure the task to always run in cmd.exe since there the quoting with " works. Something like this:

{
	// See https://go.microsoft.com/fwlink/?LinkId=733558
	// for the documentation about the tasks.json format
	"version": "2.0.0",
	"tasks": [
		{
			"taskName": "dir",
			"type": "shell",
			"options": {
				"shell": {
					"executable": "C:\\WINDOWS\\System32\\cmd.exe",
					"args": [
						"/d", "/c"
					]
				}
			},
			"command": "dir",
			"args": [
				"\"${file}\""
			]
		}
	]
}

[imba-tjd]

@dbaeumer Yeah, configuring like that doesn't have this problem. So it's clear the issue exists, right? I know little about powershell and vs code so I can't help much.
And I suggest the document should mention about adding \" if the command contains a blank after this issue is solved.

[dbaeumer]

So I read about PowerShell and the right quoting for powershell is ' not ". Since we are open to the shell a user is using there is little VS Code can do to enforce the right quoting in case a argument contains spaces. So this works in PowerShell

{
	// See https://go.microsoft.com/fwlink/?LinkId=733558
	// for the documentation about the tasks.json format
	"version": "2.0.0",
	"tasks": [
		{
			"taskName": "dir",
			"type": "shell",
			"command": "dir '${file}'",
			"problemMatcher": []
		}
	]
}

In your concrete example which calls gcc which I assume is an executable you could even do the following:

{
	// See https://go.microsoft.com/fwlink/?LinkId=733558
	// for the documentation about the tasks.json format
	"version": "2.0.0",
	"tasks": [
		{
			"taskName": "Compile",
			"type": "process",
			"command": "gcc",
			"args": [
				"${file}"
			],
			"problemMatcher": []
		}
	]
}

Please note that this uses a task of type process that mean VS Code does start gcc directly without starting PowerShell first. This bypasses shell interpretation which is always complicated to escape if arguments have spaces.

I will keep the item open to see if there is more VS Code can do in terms of smartness or guiding the user to the rights quotes.

[imba-tjd]

@dbaeumer OK, I konw it. Thank you.

[dbaeumer]

Here is what we should do:

• keep the idea that the user of the tasks.json should do the quoting since he knows best what to do.
• if a variable is resolved (e.g. ${file}} and the resolved value contains a space we should escape the space. Only downside is that cmd.exe doesn't support space escaping.

[DollarAkshay]

@dbaeumer Thank you. You are a hero

[dbaeumer]

I added support that you now can control the quoting in task 2.0. You can now for example write something like this:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "echo",
            "type": "shell",
            "command": "dir",
            "args": [
                "fo lder"
            ],
            "problemMatcher": []
        }
    ]
}

In this case the task framework will quote the fo lder arg using the strong quoting rule of the shell used to execute the task. If users want to enforce a certain quoting they can do the following:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "echo",
            "type": "shell",
            "command": "echo",
            "args": [
                {
                    "value": "$(3 * 2)",
                    "quoting": "weak"
                }
            ],
            "problemMatcher": []
        }
    ]
}

which when executed in PowerShell prints 6

[dbaeumer]

Marking as dup of #45576 since it contains the change set to fix this.