Minimize PATH polution

[3noch]

I'm not sure how far we can go with this, but git's ancillary tools overlap with Windows built-in tools. For example, the packaged git's ./usr/bin folder has echo, find, [.exe (??), dir, etc. These overlap with the standard Windows commands with the same name (except for [...that's just weird). Does git actually need these on the path to work? Even if it does, we need to figure out a way to stop these from polluting the PATH. I have simple Windows scripts that don't work when MinGHC paths are set.

[elieux]

[ is a command line program for testing conditions (writing conditions in shell, like if [ "$file" = 'ghc' ]; then stuff; fi, can include running this program) and it's more or less an alias for test.

I wonder, is running Windows scripts inside an MSYS environment necessary?

[3noch]

Ah, thanks. I wonder how well that works on Windows...

I'm not sure if I've missed your point, but currently git's ./usr/bin directory is added to the Windows PATH by the installer. So any time you open up a terminal you have a truckload of MSYS tools ready to help or hinder you. In my case and probably many others, they hinder.

[elieux]

Global PATH for all applications? That'd be unfortunate.

[3noch]

Yes

[elieux]

It'd be nicer if the PATH was always altered locally. If I understand it correctly, these tools are only needed for installing/building packages which sounds like something that could be mandated to be done in a special shell (or at least require launching some environment preparation script).

[3noch]

MSYS itself is not so bad. It's Git's usr/bin that really messes with Windows.

[elieux]

I'm looking at the contents of minghc-7.10.1-x86_64.exe and I don't see any other MSYS than the one included in the Git for Windows archive (which is actually MSYS2). Am I missing something?

[3noch]

You're right. I wonder if we're piggybacking on Git's MSYS now. @snoyberg?

[snoyberg]

Yes, I dropped the custom-hacked-together msys1 that was there previously and rely on the msys2 provided by Git. In case you're wondering, the reason I went the route of using Git is:

• I wanted to include Git so that tools like stackage-update could use it
• It was the only portable version of msys2 I could find
• The download size was almost identical to running the msys2 installer and packaging that up

[elieux]

I made a relevant post over at #43 (comment)

[elieux]

And to get back to the issue at hand, what are the reasons for including usr/bin from GfW in PATH?

[snoyberg]

Unless I'm mistaken, it's necessary for installing the network package or anything else with an autoconf script.

[elieux]

Could installing packages be restricted to only after the user enters a special environment (including that PATH change; either using a script, or a dedicated terminal window)? It seems reasonable to me, as installing packages is not done very often. The gains from having a clean PATH the rest of the time seem pretty high.

[snoyberg]

I think people will be very frustrated by cabal install foo not just working.

[elieux]

Then maybe an installer option?

Anyways, one can avoid the most obvious conflicts (echo, find, ...) by renaming these binaries and providing shell wrappers in their place. For example, echo.exe could be renamed to msys2-echo.exe and an echo file containing #!/usr/bin/bash + /usr/bin/msys2-echo.exe "$@". This way, Windows doesn't see anything executable with the name echo, while make and bash and others will see an executable echo script.

[ndmitchell]

I think MSYS1 (or at least our version of it) managed to avoid things like find/echo, so the only things that changed were things that weren't there before (rm, mv, cp, ls). Having it replace the Windows versions of expected utilities is a bit unfortunate. We should still be able to have a working network install and not break most .bat files.

[3noch]

It could be as easy as moving Git's MSYS lower in precedence somehow, although that seems fraught with potential problems.

[ndmitchell]

Remember there is the system path and the user path that get merged to form one path. I think the user patch takes preference, and that's what we edit, so putting something after the default system things is probably impossible (but I don't guarantee it).

[3noch]

True, I don't think echo is actually a binary anywhere, but built into the shell.

[3noch]

But that means echo might not actually be a problem.

[3noch]

I'm not advocating this approach, but if we added to HCLM PATH we could precede/succeed (I forget which one) C:\Windows\System32 and C:\Windows\SysWOW64. But that seems worse in a different way.

[ndmitchell]

Writing to HCLM requires admin, which the latest movement of directory was designed to avoid.

[3noch]

Roger

[elieux]

echo and [ happen to be built into both sh and Bash, so their executables could be maybe just removed, if MinGHC doesn't need them anywhere else. The wrapper solution I proposed earlier covers more cases, though.

[3noch]

Another terrible hacky idea: wrap cabal itself with a batch/vbs script that loads proper tools into the PATH:

cabal.bat

@echo off
setlocal
call %~dp0\set-msys-env.bat
real-cabal-somewhere.exe %*

[ndmitchell]

I'm not 100% convinced that is a terrible idea... The only problem is that the user can install their own cabal.exe, and we couldn't wrap that. To do it robustly you'd need to have a different executable, e.g. something like clique.exe which did the transition, and encourage the user to run that instead. Ultimately, you only want git on the PATH for doing stackage stuff, and MSYS on the path for running autoconf configure scripts, but to limit it to that you are starting to rewrite Cabal.

[3noch]

Yeah, custom cabal installs is the tough part. Provided their cabal is lower precedence, we could search for it ourselves on the PATH and/or look in the normal places.

[3noch]

Sounds like the best idea so far is to cripple MSYS a bit and rename some of its tools...

[akhra]

Remember there is the system path and the user path that get merged to form one path. I think the user patch takes preference, and that's what we edit, so putting something after the default system things is probably impossible (but I don't guarantee it).

Actually, the user path comes last. This seems like a terrible design in general, but it does play in your favor here.

[3noch]

Hmm, if that's true then why are my scripts breaking? I need to look into that. Perhaps I'm running "minghc.bat" from the script which is why it's breaking.

[3noch]

Since we're using MSYS2, I went ahead and closed #20.

[3noch]

So we only mask find and other system tools in a shell that has run a minghc batch script. One possible fix would merely modify the line that adds the MSYS directory and add it to the end of PATH instead of the beginning. That would pose problems if the user has their own tools that mask MSYS tools.

[ndmitchell]

We now advise people use Stack instead, MinGHC is no longer supported. Stack neatly avoids PATH pollution.