Tasks no longer work

[weinand]

VS Code Insiders:
macOS

This simple task no longer works in the Insiders:

		{
			"label": "done",
			"type": "shell",
			"command": "echo debugging done",
			"identifier": "done"
		}

The output is:

This was working fine on Friday and is still works in stable.

[weinand]

Actually I can no longer build any of my extensions in Insiders with the build task.

[floooh]

Same problem here, not sure if this is an intended change, but tasks with a command that includes both the command name and arguments in the string no longer work with the Visual Studio Insiders build 2018-03-13T06:03:33.628Z (1126701).

For instance, this doesn't work anymore:

"tasks": [
   ...
   "command":"python fips build",
]

The following workaround works (put the arguments into the separate "args" JSON item:

"tasks": [
   ...
   "command": "python",
   "args": ["fips", "build"]
]

Only tested on OSX.

[IAmHopp]

Can either of you test including a \" at the beginning and end of the command?

I'm on Windows, just wanna see if it's the same issue I'm having.

[floooh]

You mean like this? "command":"\"python fips build\"", Doesn't work here on OSX, same problem.

I've seen similar problems in python's subprocess module, this has a special "shell" argument, which must be true when a command and args are provided in a single string:

args is required for all calls and should be a string, or a sequence of program
arguments. Providing a sequence of arguments is generally preferred, as it 
allows the module to take care of any required escaping and quoting of 
arguments (e.g. to permit spaces in file names). If passing a single string, 
either shell must be True (see below) or else the string must simply name the
program to be executed without specifying any arguments.

I guess something similar has changed in the way VSCode passes commands to the system shell.

[IAmHopp]

Yes, like that, thank you.

Today's build also broke my tasks, but I'm guessing both issues are shell-specific. Mine is solved by the wrapping \"s.

[dbaeumer]

I broke this with the new quoting support. So the only fix I currently can think of is to not quote a command unless it is asked for. Will look into how to best fix this.

As a workaround you can split the command in a command and args which should work again.

[dbaeumer]

@weinand thanks for reporting this. I pushed a fix. Will be in tomorrows insider.