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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Installer Obliterates PATH variable #5534

Closed
vicuna opened this issue Mar 13, 2012 · 15 comments
Closed

Installer Obliterates PATH variable #5534

vicuna opened this issue Mar 13, 2012 · 15 comments

Comments

@vicuna
Copy link

vicuna commented Mar 13, 2012

Original bug ID: 5534
Reporter: adamgolding
Assigned to: @protz
Status: closed (set by @xavierleroy on 2013-08-31T10:48:55Z)
Resolution: fixed
Priority: high
Severity: major
Platform: PC
OS: Windows
OS Version: 7 Ultimate
Category: platform support (windows, cross-compilation, etc)
Monitored by: @protz Bardou

Bug description

After installing OCaml, some pieces of software on my computer would not run because they could not find java--upon inspecting my PATH variable, I found that the only entries present were OCaml entries! It appears OCaml replaces, rather than appends to, the path.

@vicuna
Copy link
Author

vicuna commented Mar 13, 2012

Comment author: @gasche

Please make precise which OCaml installer you used, for example by giving an URL to the installer; they are several different ways to install OCaml for windows.

As you will guess this is a bug in your specific installer script -- no, the OCaml compiler does not eat your PATH for breakfast.

Did you use the new Windows installer by Jonathan Protzenko?
http://protz.github.com/ocaml-installer/
There is a related known bug for this installer ( protz/ocaml-installer#1 ).

@vicuna
Copy link
Author

vicuna commented Mar 14, 2012

Comment author: adamgolding

I'm not sure which URL I used, but the file is this:

ocaml-3.12.1-mingw32

at any rate, I'm about to switch to the cygwin version

@vicuna
Copy link
Author

vicuna commented Mar 14, 2012

Comment author: @gasche

So I think you probably have the installer mentioned above -- strange that you don't remember the blink on the webpage! The problem comes from the Windows installer used (NSIS, I think), not from OCaml itself: the installer has a hard limit on the PATH length and simply empty it when it's too long.

Jonathan is investigating the issue. If anybody know a good (reliable) Windows installer that doesn't have this issue, suggestions are welcome.

Thanks for the bug report.

@vicuna
Copy link
Author

vicuna commented Mar 14, 2012

Comment author: @protz

Yes so just for future reference, it turns out the installer generator that I'm using (namely, NSIS) has a stupid, hardcoded limit on the length of strings it can manipulate. So when the installer tries to prepend the path the the OCaml bin directory to the PATH env variable, if the PATH is already more than 1k long, it simply blasts the value of the PATH variable.

I'm unsure what's the right thing to do here. NSIS does provide very convenient wrappers for i) not appending the path if it's already in the PATH, ii) removing the right path from PATH at uninstall-time, and so on. Duplicating everything in one self-contained C program just because the generated installer can't deal with long strings seems silly, to say the least.

@vicuna
Copy link
Author

vicuna commented Mar 22, 2012

Comment author: @protz

So what I'm about to do (following a suggestion from Alain) is have the installer generate .bat files that do the PATH thingy, then launch ocaml in a shell, or emacs. That way, we won't have these "minor annoyances".

Any objections?

@vicuna
Copy link
Author

vicuna commented Mar 22, 2012

Comment author: @ygrek

Why not use special nsis build (with 8192 chars limitation?). Also it should be possible to call windows api directly from the plugin dll (more work..). Or maybe check that new PATH will be less than 1024 and set it only in such case, otherwise warn user to launch ocaml via bat file (and interested users will be able to set the environment manually looking at bat file).

@vicuna
Copy link
Author

vicuna commented Mar 22, 2012

Comment author: @protz

So yes I'm aware of the other NSIS build, but you're not really solving the problem, just making it harder to happen.

I'll try to see if I can check for the length of the PATH before overriding it, so that I can warn the user that they need to add the path to ocaml to their PATH by themselves. The problem seems to happen pretty frequently though.

The rationale for using .bat files is as follows:

  • either the user is serious, and they're using msys/cygwin already, so they know how to add something to their PATH
  • otherwise, they'll just use the .bat files.

@vicuna
Copy link
Author

vicuna commented Mar 22, 2012

Comment author: @protz

http://trac.haskell.org/haskell-platform/ticket/25 has some interesting insights (apparently the maximum length of an env variable on windows is 8192)

@vicuna
Copy link
Author

vicuna commented Mar 23, 2012

Comment author: @alainfrisch

I strongly support the fact that the OCaml installer does not touch environment variables (PATH or OCAMLLIB). In addition to installing .bat files to start ocaml (the toplevel) and emacs (with proper PATH), it would be good to have one which runs a windows shell cmd.exe.

@vicuna
Copy link
Author

vicuna commented Mar 23, 2012

Comment author: @protz

Well I discussed this with Xavier and we didn't have much opinions in favor of one way or another; .bat files add some burden, I'm not sure I can hide the command-line window that appears (although some answers on stack overflow seem to indicate that I can), and this means that I need to write wrappers for emacs (because there are shell associations with .ml and .mli files that the installer creates) that forward the arguments. Xavier also mentioned that passing the arguments through cmd.exe makes cmd.exe reparse them, which might no be a good idea. At that point, I was really unsure what the best move is.

Xavier, anything you want to add?

@vicuna
Copy link
Author

vicuna commented Mar 23, 2012

Comment author: @alainfrisch

Xavier also mentioned that passing the arguments through cmd.exe makes cmd.exe reparse them, which might no be a good idea.

We are talking of a single argument, the file name to open (when the user double-click on an .ml/.mli file in the explorer), right?

@vicuna
Copy link
Author

vicuna commented Mar 24, 2012

Comment author: @xavierleroy

We are talking of a single argument, the file name to open

All right, but even so, this single argument could contain spaces or other special characters, and who knows what cmd.exe will do with them. .bat files are always a problem, never a solution.

@vicuna
Copy link
Author

vicuna commented Mar 26, 2012

Comment author: Bardou

If you embed the binaries in .bat files, won't we need to add the .bat files to the PATH anyway? To call them from the MinGW shell, for instance.

@vicuna
Copy link
Author

vicuna commented Mar 26, 2012

Comment author: @protz

The whole point of adding .bat files is that the .bat files take care of exporting the right PATH, then launching ocaml. If the user is a power user, they know for sure how to add a directory to their path (using .bashrc, for instance), and then they'll call ocaml directly.

It looks like I'll be able to tweak the PATH correctly in the next iteration of the installer, I just need a few more days to make sure it works fine.

@vicuna
Copy link
Author

vicuna commented Mar 29, 2012

Comment author: @protz

The latest version of the installer (http://yquem.inria.fr/~protzenk/caml-installer/ocaml-4.01.0+dev0-i686-mingw64.exe) is now able to deal with PATHs that are up to 8192 bytes long. In case the PATH is already longer than that, it will not delete it.

I finally didn't go with the .bat files solution.

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

No branches or pull requests

1 participant