Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

msiexec returns 1639 with "help" popup #33

Closed
rusty-new-dev opened this issue Oct 31, 2015 · 5 comments
Closed

msiexec returns 1639 with "help" popup #33

rusty-new-dev opened this issue Oct 31, 2015 · 5 comments

Comments

@rusty-new-dev
Copy link

After trying many many many times to get multirust working on Windows without success (with msiexec returning 1639 over and over again with that confusing popup 馃槶), I finally figured out why multirust was not working for me. std::process::Command will quote arguments as needed, except that the way it quote the arguments doesn't work for msiexec. When this:

TARGETDIR=path with space

is given to std::process::Command, It turns it into:

"TARGETDIR=path with space"

but msiexec needs it as:

TARGETDIR="path with space"

Note the position of the double quotes. One workaround is to use MULTIRUST_HOME= to get multirust to use a path without spaces (and any other character that might get std::process::Command into quoting the TARGETDIR= argument). The other is to create a new user account with a folder that does not have any spaces (or characters that might get std::process::Command to quote TARGETDIR=).

PS: Having figured that out, I decided to use msys2 to try create an isolated environment to temporarily test multirust by setting MULTIRUST_HOME=/c/path/to/multirust/home , but that didn't work either ( since msys2 converts path in what they call "mixed mode", it ends up being c:/path/to/multirust/home instead of c:\path\to\multirust\home ). Of course, msiexec (like many Windows commands) barfed on this 馃槶. Maybe multirust could change '/' to '' in paths before passing them to msiexec (or maybe warn the user about it).I won't be surprised if there are other combinations that can make msiexec fail, but these are the only ones I've encountered so far. Sorry for the rant 馃槢.

@Diggsey
Copy link
Contributor

Diggsey commented Oct 31, 2015

Yes, this is an unfortunate consequence of the fact that rust chose to use posix semantics for command lines, while on windows command lines are a single string. The problem affects any programs which do not use CommandLineToArgvW or equivalent for parsing arguments.

Currently the only workaround is to ditch Command altogether and call CreateProcess directly, but I'll open an issue about adding an "unescaped arg" method.

@rusty-new-dev
Copy link
Author

Another way around this issue might be to call MsiInstallProduct instead of running msiexec, but I guess there's no working msi-sys yet.

@Diggsey
Copy link
Contributor

Diggsey commented Jan 3, 2016

For reference the issue is rust-lang/rust#29494

@retep998
Copy link
Member

retep998 commented Mar 9, 2016

@Diggsey Would a working msi-sys with MsiInstallProductW be a functional alternative that can effectively fix this issue?

@Diggsey
Copy link
Contributor

Diggsey commented Mar 9, 2016

This is no longer hugely relevent, since with @brson's changes, multirust-rs no longer installs from the .msi installers. The installation logic is now intrinsic to multirust-rs, so it can just download the .tar.gz distributions!

@Diggsey Diggsey closed this as completed Mar 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants