Args not working in tasks.json using - "_runner":"terminal"

[gdxn96]

• VSCode Version: 1.12.2
• OS Version: Windows 10
• Terminal: Bash for Windows

{
    "version": "0.1.0",
    "options": {
        "cwd": "${workspaceRoot}"
    },
    "_runner": "terminal",
    "tasks": [
        {
            "taskName": "Install Pip Dependancies",
            "command": ".env/bin/python",
            "isShellCommand": true,
            "args": ["-m", "pip", "install", "-r", "requirements/dev.txt"],
            "showOutput": "always"
        }
    ]
}

Running this task does not act as expected, it opens the terminal as it should, then it opens a python interpreter, ignoring all my nice args. Have I done something wrong or is it a bug? I've deleted all my other tasks for legibility.

[kieferrm]

I tried that on macOS with 1.12.2 and insiders. Works in both cases without issues.

[dbaeumer]

@gdxn96 which Bash system to you use. The Windows Subsystem for Linux ?

[dbaeumer]

I can reproduce using Ubuntu bash.exe. The shell args constructed look like this:

@Tyriar you once told me that under Windows I must pass one string as a shell arg in case of additional arguments. Is there anything else I need to consider. Must the command passed to echo in this case be quoted ?

[dbaeumer]

Please note that to easier reproduce I modified the command from .env/bin/python to echo.

[dbaeumer]

The code works as expected using cmd.exe or powershell.

[gdxn96]

Sorry yes, Windows Subsystem for Linux is whats causing the issue

[Tyriar]

@dbaeumer so the issue here seems to be related to us not giving bash.exe what it's expecting. Needs some experimentation.

[dbaeumer]

@Tyriar assigning you as well. If you give me some hints I could look into this as well.

[Tyriar]

@dbaeumer I would expect either as args or the single string should work. Not sure what's sent now but maybe for bash.exe on Windows you need a conditional that uses the string[] approach?

[giovdk21]

Hi,
I've the same issue; this is with the insiders build (2017-06-09) on Windows using bash.

{
    "version": "2.0.0",
    "tasks": [
        {
            "taskName": "Test 1",
            "type": "shell",
            "command": "uname",
            "isShellCommand": true,
            "echoCommand": true,
            "args": ["-a"],
            "showOutput": "always"    
        }
    ]
}

Expected result: Linux HostName 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
Actual result: Linux

[dbaeumer]

@Tyriar I tried both using as single string or a string[]. Both result in the same behavior under Windows of not running the task correctly. What I noticed is that the winpty-agent closed but the electron process started with --type=terminal still hangs around afterwards when passing the args separately:

When passing the args as one string the execution fails with:

The terminal process terminated with exit code: 3221225477

Can you please investigate. I ran out of ideas / options.

[giovdk21]

For a temporary workaround to this one, please see also: #22663 (comment)

[dbaeumer]

@Tyriar please see #30417 (comment). It contains a work around by quoting the command line. Is this what I am supposed to do for bash under Windows?

[0not]

@dbaeumer According to the bash man page, the argument to bash -c should be quoted. Anything after the string to be executed is passed in as parameters.

-c string
If the -c option is present, then commands are read from string. If there are arguments 
after the string, they are assigned to the positional parameters, starting with $0.

For example, "command": "\"echo $0\" Hello" prints "Hello" as expected.

It appears that the command does need to be quoted when passed to bash -c, but I don't know enough about the task system to say if that's feasible. I just figured I'd pass this information on.

[giovdk21]

@dbaeumer & @0not could you please have a look at my previous comment or here?

The workaround I implemented works in a similar way but basically I'm collecting all the shell arguments with a powershell script and then calling C:\Windows\System32\bash.exe -c "$args_str"

This not only fixes it but it also allows for other parameters to be appended at the end. For example one extension (solargraph) is defining a command that it needs to run and then appending different arguments depending on the action it wants to perform.

Another thing to consider is that the path passed from the task / extension is in the windows format, so my workaround also tries to convert that into a linux path.

[dbaeumer]

It is correct that the arg passed to -c should be quoted but somehow this is done by the terminal correctly when running bash under Linux and Mac OS but obviously not under Windows. We need to understand what is different in the xterm code and whether quoting it for Windows is the right thing to do.

[0not]

I believe I've found a solution, but I don't know how correct it is. In src/vs/workbench/parts/tasks/electron-browser/terminalTaskSystem.ts change line 475 from shellLaunchConfig.args = Platform.isWindows ? shellArgs.join(' ') : shellArgs; to shellLaunchConfig.args = Platform.isWindows && basename !== 'bash.exe' ? shellArgs.join(' ') : shellArgs;. Several lines before this Windows is treated specially with three options (powershell, bash, or cmd), but on this line the only differentiation is made between Windows and other (presumably bash on Linux/Mac). The logic for isWindows should really be not bash.

I would create a pull request for this, but embarrassingly, I don't know how and I don't have time tonight. I've tested this solution by building vscode on Windows 10, but I don't know of any unforeseen side effects.

[Tyriar]

@dbaeumer On Windows you use the different escaping method (string), I'm assuming since bash.exe redirects to actual bash on Ubuntu it requires the same format (string[]).

You could try see if it's bash.exe inside %windir%\(sysnative|system32|syswow64) then use the string[] method?

[dbaeumer]

@Tyriar #30417 shows the same problem for bash from git install (so no Linux Subsystem). So should I use string[] for git bash as well. Would be good to understand what the terminal does so I can implement the right fix on my side.

[Tyriar]

@dbaeumer all the examples in the issue that introduced the string format appear to be cmd.exe (#19078, microsoft/node-pty#41), maybe it needs to only apply to cmd.exe? I don't have much knowledge into this area other than cmd.exe doesn't want the args in the "proper" argv format. It needs some experimentation to figure out what's going on.

The formatting is done on the string | string[] here, after that it's handed off to winpty which is largely a black box to me. That function was added in microsoft/node-pty@ed3c9da, before that arguments didn't work at all on Windows (fixed chjj/pty.js#137).

[dbaeumer]

Fixed by fixing #30417