-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
incompatible_windows_bashless_run_command: enables Bash-less "bazel run" on Windows #8240
Comments
This flag enables Bash-less "bazel run" for simple cases (no `--run_under`, no `--script_path`). When enabled, "bazel run //foo:bin" no longer requires Bash, and works with `--shell_executable=""`. Bash is still required with --run_under="foo" and with --script_path=<path>. Fixes bazelbuild#8229 See bazelbuild#8240
This flag enables Bash-less "bazel run" for simple cases (no `--run_under`, no `--script_path`). When enabled, "bazel run //foo:bin" no longer requires Bash, and works with `--shell_executable=""`. Bash is still required with --run_under="foo" and with --script_path=<path>. Fixes bazelbuild#8229 See bazelbuild#8240 Change-Id: I36b9951674bf8651216178d6b34f28a496e724b9
Windows: add --incompatible_windows_bashless_run_command This flag enables Bash-less "bazel run" for simple cases (no `--run_under`, no `--script_path`). When enabled, "bazel run //foo:bin" no longer requires Bash, and works with `--shell_executable=""`. Bash is still required with `--run_under="foo"` and with `--script_path=<path>`. Fixes #8229 See #8240 Closes #8241. PiperOrigin-RevId: 247183428
To "bazel run" a binary, the RunCommand creates an ExecRequest and sends it to the Bazel client, which then fulfills the request. In PR bazelbuild#8241, RunCommand merged all command line arguments and added that to the request as a single argv entry. The client uses the first argv element as the executable, but if all arguments are joined into one string then argv0 contains the whole argument vector as a single string. Unfortunately the test didn't catch this because it didn't attempt passing any arguments. Fixes bazelbuild#8229 See bazelbuild#8240
To "bazel run" a binary, the RunCommand creates an ExecRequest and sends it to the Bazel client, which then runs the binary as the client's subprocess. In PR #8241, RunCommand merged all command line arguments and added that to the request as a single argv entry. The client uses the first argv element as the executable, but if all arguments are joined into one string then argv0 contains the whole argument vector as a single string. Unfortunately the test didn't catch this because it didn't attempt passing any arguments. Fixes #8229 See #8240 Closes #8287. PiperOrigin-RevId: 247590904
To "bazel run" a binary, the RunCommand creates an ExecRequest and sends it to the Bazel client, which then runs the binary as the client's subprocess. In PR bazelbuild#8241, RunCommand merged all command line arguments and added that to the request as a single argv entry. The client uses the first argv element as the executable, but if all arguments are joined into one string then argv0 contains the whole argument vector as a single string. Unfortunately the test didn't catch this because it didn't attempt passing any arguments. Fixes bazelbuild#8229 See bazelbuild#8240 Closes bazelbuild#8287. PiperOrigin-RevId: 247590904
I believe the 0.27 tag should be removed here because this flag doesn't seem to exist in that version // @laurentlb |
@keith : I'm curious, why does it seem so? The flag exists in 0.27.0 -- search for |
This flag is only available with |
Aah, thanks! |
Ah thanks! Interesting problem.
On Wed, Jul 3, 2019 at 01:31 László Csomor ***@***.***> wrote:
Aah, thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8240?email_source=notifications&email_token=AACFJ3XCIXTXL7URWOWVIMLP5RPWJA5CNFSM4HK6IDGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZDWODA#issuecomment-507995916>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AACFJ3T2GN6CQFPKIR5VQ5TP5RPWJANCNFSM4HK6IDGA>
.
--
--
Keith Smiley
|
Current status: every Bazel CI downstream project except rules_cc pass with this flag flipped. Using the same binary the CI used (https://buildkite.com/organizations/bazel/pipelines/bazel-at-head-plus-downstream/builds/1077/jobs/b8e6756c-fad0-4ef6-955c-6bca217137f7/artifacts/1d1a1a17-0818-43f8-818d-b5c7a39bac8b), testing rules_cc works on my machine. |
Update: the test breakage is legitimate. It indicates an escaping bug in Bazel. I have a bugfix in https://github.com/laszlocsomor/bazel/tree/fix-GOOD-bashless-run-caller-escapes that I need to clean up before sending out. |
There are two axes of variables: - server mode vs. batch mode (--[no]batch) - Windows only: Bash-less vs. Bash-ful bazel run (--[no]incompatible_windows_bashless_run_command) To "bazel run" a target, Bazel first builds the target then creates a run request. The request is a protobuf that contains the command line (argv) and environment (envvars, cwd). In server mode (--nobatch), the Bazel server sends the run request to the client, and the client executes the program (with CreateProcessW on Windows / execv on Unixes). In batch mode (--batch), the Bazel server itself executes the program using ProcessBuilder. In Bash-ful bazel run mode the run request is for "bash -c <program> <args>...", while in Bash-less more it is for "<program> <args>...". The argument escaping must be different in both cases, because bash.exe uses Bash-style quoting/escaping while most native Windows programs use the MSVC style. Fixes the issue mentioned in bazelbuild#8240 (comment)
Does windows.md need updating? It says:
|
Only after Bazel 1.0.0 came out -- it will flip |
Remove this flag and every occurrence of it. It was flipped in Bazel 1.0, so nobody should be using it in production. Fixes #8240 RELNOTES[INC]: The --[no]incompatible_windows_bashless_run_command flag is no longer supported. It was flipped in Bazel 1.0 PiperOrigin-RevId: 289835848
Fixes bazelbuild/bazel#8240 RELNOTES[INC]: Windows: --incompatible_windows_bashless_run_command is now true by default, meaning "bazel run //foo:bin" will run the binary as a subprocess of the Bazel client. (When the flag is false, the binary is executed as a subprocess of Bash.) PiperOrigin-RevId: 266097847
Description
Related bug: #8229
The option
--incompatible_windows_bashless_run_command
enables Bash-less "bazel run" on Windows. This flag has NO effect on other platforms.When disabled,
bazel run //:foo_bin
runs the binary through Bash, and fails with--shell_executable=""
. Bazel will:bash -c <joined_args>
When enabled,
bazel run //:foo_bin
does not require Bash and works with--shell_executable=""
. Bazel runs the binary directly (instead of throughbash -c
), and escapes the arguments Windows-style (the same as enabled by #7454). But Bash is still required when using--run_under=foo
or--script_path=<path>
, even when--incompatible_windows_bashless_run_command
is enabled.Migration recipe
None, as of 2019-05-06.
We don't expect any breakages when this flag is enabled. However if it breaks your build, please let us know so we can help fixing it and provide a migration recipe.
Rollout plan
false
.true
.The text was updated successfully, but these errors were encountered: