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

Windows: don't shell out to `cmd.exe` #2190

Open
laszlocsomor opened this Issue Dec 6, 2016 · 11 comments

Comments

Projects
None yet
8 participants
@laszlocsomor
Copy link
Contributor

laszlocsomor commented Dec 6, 2016

Description of the problem / feature request / question:

cmd.exe doesn't support UNC paths so we can't shell out to tools through it and use long paths.

Example where this occurs: WindowsFileSystem.createDirectoryJunction

Related issue: #2181

Environment info

  • Operating System: Windows 10
@laszlocsomor

This comment has been minimized.

Copy link
Contributor

laszlocsomor commented Dec 6, 2016

This issue is actually blocking #2181 .

@laszlocsomor laszlocsomor added P2 and removed P1 labels Dec 6, 2016

@laszlocsomor

This comment has been minimized.

Copy link
Contributor

laszlocsomor commented Dec 6, 2016

P2, because there is a workaround: use --output_user_root=<something short>.

You can even create a virtual drive:

subst d: c:\some\path\where\bazel\can\put\stuff

then just use --output_user_root=/d/.

@laszlocsomor

This comment has been minimized.

Copy link
Contributor

laszlocsomor commented Dec 6, 2016

Re: #2190 (comment) and WindowsFileSystem.createDirectoryJunction, that's actually a bad example, because mklink is a built-in command of cmd.exe, so we'll have to implement the junction creation in JNI anyway.

The CommandBuilder however suffers from this limitation.

@abergmeier-dsfishlabs

This comment has been minimized.

Copy link
Contributor

abergmeier-dsfishlabs commented Dec 6, 2016

Isn't this rather a bug?

@dslomov dslomov added this to the 0.5 milestone Dec 6, 2016

@petemounce

This comment has been minimized.

Copy link
Contributor

petemounce commented Jan 26, 2017

Generally don't use cmd, because MS announced that they will (finally!!) be deprecating it (over some time): http://www.osnews.com/story/29502/Microsoft_replaces_cmd_with_PowerShell_in_new_Windows_10_build

@dslomov dslomov modified the milestones: 0.6, 0.5 Feb 14, 2017

@laszlocsomor

This comment has been minimized.

Copy link
Contributor

laszlocsomor commented Feb 14, 2017

@petemounce : AIUI they aren't deprecating cmd, just making it non-default. So cmd will be around... *in ghastly voice* foreveeeeeeer.

@petemounce

This comment has been minimized.

Copy link
Contributor

petemounce commented Feb 14, 2017

Sure. Still don't use it. :p

@meteorcloudy meteorcloudy added P3 and removed P2 labels Feb 28, 2017

@dslomov dslomov modified the milestones: 0.6, 0.5 Apr 4, 2017

@dslomov

This comment has been minimized.

Copy link
Contributor

dslomov commented Jul 24, 2017

Powershell is very very slow to start (as in, >10x slower than cmd.exe as @philwo measured)
So we avoid using powershell as a shell.
See https://docs.google.com/document/d/1z6Xv95CJYNYNYylcRklA6xBeesNLc54dqXfri0z0e14/ for some plans

@dslomov dslomov modified the milestones: 0.7, 0.6 Jul 24, 2017

@davido

This comment has been minimized.

Copy link
Contributor

davido commented Aug 19, 2017

Another reason to not shell out to cmd.exe is 8191 command line limit: #3579.

@laszlocsomor

This comment has been minimized.

Copy link
Contributor

laszlocsomor commented Dec 14, 2017

This is the only non-test place I found where Bazel shells out to cmd.exe:

return new String[] { "CMD.EXE", "/S", "/E:ON", "/V:ON", "/D", "/C",

I have a hunch (that I need to verify) that you can CreateProcess with other executables than .exe files, so automatically using cmd may be unnecessary:

// Automatically enable CMD.EXE use if we are executing something else besides "*.exe" file.
// When use CMD.EXE to invoke a bat/cmd file, the file path must have '\' instead of '/'

laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Apr 12, 2018

Windows: launcher no longer depends on cmd.exe
See bazelbuild#2190

Change-Id: If665af264a23be0219c75ae087dd25db74d5e386

laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Apr 12, 2018

Windows: java launcher no longer calls cmd.exe
See bazelbuild#2190

Change-Id: If665af264a23be0219c75ae087dd25db74d5e386

bazel-io pushed a commit that referenced this issue Apr 12, 2018

Windows: java launcher no longer calls cmd.exe
See #2190

Closes #5005.

Change-Id: If665af264a23be0219c75ae087dd25db74d5e386
PiperOrigin-RevId: 192575414

laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Apr 12, 2018

CommandBuilder: remove useShell and setWorkingDir
Remove the .useShell method, expect callers to
just pass the shell interpreter if they need it.
This removes the argument vector transformation
heuristic, and stops shelling out to cmd.exe on
Windows. See bazelbuild#2190

Also remove the .setWorkingDir method because
callers always had to set the working directory.
Instead, the CommandBuilder constructor takes the
working directory.

Change-Id: I545e01c811daaf34913cb585492923da81aa02ee

@bazel-io bazel-io closed this in 073ea09 Apr 12, 2018

@laszlocsomor laszlocsomor reopened this Apr 17, 2018

@laszlocsomor

This comment has been minimized.

Copy link
Contributor

laszlocsomor commented Apr 17, 2018

PR #5007 was rolled back in 8358148.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment