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
Comments
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? |
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 |
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. |
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. |
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? |
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). |
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:
|
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) |
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. |
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? |
Comment author: @alainfrisch
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? |
Comment author: @xavierleroy
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. |
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. |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: