run_shell quoting broken on Windows

[mboes]

Description of the problem

Quoting of the command in ctx.actions.run_shell() does not work the same way on Windows and on Unix.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Consider the following BUILD file:

load(":args_test.bzl", "args_test")
args_test(name = "y")

with args_test.bzl:

def _impl(ctx):
    foo = ctx.actions.declare_file("foo")
    ctx.actions.run_shell(
        outputs = [foo],
        command = '${1+"$@"}',
        arguments = ['echo', 'a', 'b', 'c'],
    )
    return [DefaultInfo(executable = foo)]

args_test = rule(
    implementation = _impl,
    test = True,
)

On Linux, we get "a b c" printed on the console, before Bazel complains that executing the command did not create the file "foo". But on Windows, Bash complains that program '$' does not exist. Clearly, the quoting of the command doesn't work the same way.

Now for something even more odd. If instead of ${1+"$@"}, the command becomes ${1+"$@"} (mind the extra whitespace character), then the Windows behaviour matches the Linux one. That is, it takes there being at least one whitespace character in the command for the quoting to kick in properly. Now, it's very hard to debug these quoting issues because quotes are never displayed in the --verbose_failures output (not pasted here because hard to extract from my Windows VM).

More bizarre still, say the arguments read:

        arguments = ['echo', 'a', 'b"123"', 'c'],

Then the output is as follows on Linux:

a b"123" c

but the following on Windows:

a b\123" c

That is to say, the first quote gets replaced with a backslash...

The same odd behaviour can also be seen when rerouting the output of the command to a file (e.g. foo).

What operating system are you running Bazel on?

Linux NixOS 18.09 and Windows Server 2016

What's the output of bazel info release?

0.20.0

[gdeest]

Confirmed on Bazel 0.21.

bash.exe"-3.1$ ../bazel-0.21.0-windows-x86_64.exe build ...
Starting local Bazel server and connecting to it...
INFO: Invocation ID: f4135611-0c23-42cd-a339-729892e69d29
INFO: Analysed target //:y (13 packages loaded, 234 targets configured).
INFO: Found 1 target...
ERROR: C:/users/user/repro/BUILD:2:1: error executing shell command: 'C:/Users/user/scoop/apps/msys-rev13/current/bin/bash.exe -c ${1+"$@"}  echo a b c' failed (Exit 127)
"C:/Users/user/scoop/apps/msys-rev13/current/bin/bash.exe": $: command not found
Target //:y failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 58.901s, Critical Path: 0.10s
INFO: 0 processes.
FAILED: Build did NOT complete successfully

[laurentlb]

cc @laszlocsomor

[laszlocsomor]

My unconfirmed suspicion is a bug in the Windows process creation logic.

[laszlocsomor]

Reason for this suspicion is my recent discovery about the broken escaping of CreateProcess arguments, while I was debugging #7072.

[laszlocsomor]

@gdeest and @mboes , could it be that you are using MSYS1 or some custom Bash, instead of using MSYS2 64-bit? Do you see the same behavior if you install MSYS2 (https://www.msys2.org/) to c:\tools\msys64, set BAZEL_SH=c:\tools\msys64\usr\bin\bash.exe, run bazel shutdown, then try the build again?

[gdeest]

@laszlocsomor I am indeed using MSYS1 (because MSYS2 is not compatible with Docker, which is required for CI). AFAIK, @mboes is using MSYS2 64-bit.

I'll try with MSYS2 and report with the results.

[laszlocsomor]

@gdeest : did you get a chance to try with MSYS2?

[mboes]

I am using MSYS2. Still seeing the bug there.

[laszlocsomor]

This is a plain old Bazel bug. There was even a TODO to fix it... I have a fix pending.

[laszlocsomor]

I'm raising the priority, because the underlying bug is that argument escaping is similarly broken for all subprocesses, not just for run_shell.

[laszlocsomor]

Closing this, because it's fixed at HEAD, see #7454. That bug will be closed when the flag's default value is flipped to true at HEAD.