Where does Msys put user specific data?

[deech]

I was messing with the PATH setting and now my Msys won't launch saying: Windows cannot find file:'C:\Program'. I'd like to delete my .bashrc or whatever is causing that start over.

I even tried un-installing via uninstall.exe

Any help is appreciated.

[ndmitchell]

What is your current $PATH, as reported by Windows in the "change environment variables" dialog? You should find both a User and System one. My guess is that it's the $PATH variables being automatically translated that is going wrong, rather than a .bashrc (which I've never touched, and have no idea where it lives, or what form it takes).

[dpwright]

I am having the same problem with a pretty fresh install of minGHC 7.8.4. I tried removing all %PATH% entries in both User and System which had spaces in -- which includes minGHC itself of course! No luck; msys won't run whether I launch it by double-clicking the icon or by running the .bat file in a cmd window.

[dpwright]

I haven't got to the bottom of the problem running msys.bat, but I've found a workaround which seems to be working for now, which is just to call sh --login -i myself from a cmd window, skipping the batch file altogether.

Don't know if my problem is the same as the one that @deech was having but if you're still struggling this might let you get on for now?

[ndmitchell]

The Msys we ship with MinGHC wasn't really intended for running directly, only to provide support tools for cabal configure scripts. I just tried mine, from the .bat file, and that didn't work either because the directory has a space in. I tweaked the msys.bat file and got it working, new version at https://gist.github.com/ndmitchell/8b5f018f1269faaf4686. If that works for you two I suggest we ship it instead of the default one, or upgrade to MSYS 2 and see if that fixes it (they just screwed up quoting in a .bat file).

[dpwright]

That will fix the problem with launching the .bat file, though after posting my last comment I ran into another problem which seemed to be space-related, so I ended up uninstalling MinGHC and reinstalling it into C:\ (not Program Files), and that made most of the problems go away. I'm still having some issues -- somehow, somewhere in the LibClang or LLVM build (that's what I'm trying to build at the moment) it's prepending an msys-y path to make to give something like /c/projects/LibClang/buildC:\\MinGHC-7.8.4\\ghc-7.8.4\\mingw\\bin. I don't think that's related to this issue, though, so I'll continue to look into it.

I know it's a bit dramatic and not-windowsy, but would you be averse to setting the default path for MinGHC to C:\MinGHC-x.x.x? Taking it outside of Program Files seems to simplify a lot of these sorts of issues.

[ndmitchell]

The general issue is finding somewhere the user has permissions to write to. I think these might also only be issues if you want to use MSYS as a real MSYS, not just for cabal configure, in which case installing a separate MSYS under C:\MinGHC might be better - we certainly don't do any of the installer setup actions the normal MSYS does.

[dpwright]

Yeah, I hadn't run into any of these issues just running the switcher and then running cabal in a cmd window. LibClang has a modified Setup.hs which actually builds the llvm and clang C libraries, using the normal unix ./configure && make && make install cycle, which is why I started needing to use msys.

llvm and clang on their own are notoriously awkward to build in MinGW, so that coupled with the fact that they're being triggered from within Setup.hs makes it a particularly difficult library to build on Windows. So I certainly don't blame MinGHC for many of the issues I'm having! Still, a working msys environment would be useful for libraries such as this with a more complex build process.

For now, at least, It Works On My Computer with MinGHC in C:\. Sort of.

[akhra]

FWIW I've never run into any such problems, but I've always had the
installation at C:\MinGHC. With that configuration I can use make to
build and install most *x libraries and they Just Work, or at worst, I have
to move stuff from /usr/local up to /usr (though that could probably be
fixed with a directory junction). Installing gtk was just an unzip!

On Tue, Mar 17, 2015 at 5:45 AM, Daniel P. Wright notifications@github.com
wrote:

Yeah, I hadn't run into any of these issues just running the switched and
then running cabal in a cmd window. LibClang has a modified Setup.hs
which actually builds the llvm and clang C libraries, using the normal unix ./configure
&& make && make install cycle, which is why I started needing to use msys.

llvm and clang on their own are notoriously awkward to build in MinGW, so
that coupled with the fact that they're being triggered from within
Setup.hs makes it a particularly difficult library to build on Windows.
So I certainly don't blame MinGHC for many of the issues I'm having! Still,
a working msys environment would be useful for libraries such as this with
a more complex build process.

For now, at least, It Works On My Computer with MinGHC in C:. Sort of.

—
Reply to this email directly or view it on GitHub
#30 (comment).

[snoyberg]

I've raised the possibility of installing to the user's directory instead of "Program Files" in #43, which I believe would address this issue.

[ndmitchell]

We now advise people use Stack instead, MinGHC is no longer supported. I think stack path answers this question.