Menu
▾
▴
#97 64-bit msys2 is not running my .bashrc or .bash_profile.
For some reason, my 64-bit msys2 is not running my .bashrc or .bash_profile.
It may have to do with changing my install folder from c:/msys2 to c:/msys64
Everything else works fine, though. How can I "rebase" the main folder?
$ echo $HOME /home/adipose $cat /etc/passwd adipose:*:1050885:1049089:U-DOM\adipose,S-1-5-21-1827800536-843062299-1905203885-2309:/home/adipose:/usr/bin/bash $ cat /etc/fstab none / cygdrive binary,posix=0,noacl,user 0 0
Maybe! I'm coming round to the idea that MSYS2 provides enough stuff now that we should perhaps set the PATH so that your existing stuff doesn't get found...
These days it causes nothing but more problems .. Perhaps an option on the installer about whether to overwrite or append would be best?
BTW, I know this isn't the right place but I pushed some qt5-static fixes in the last hour for cmake usage.
Right now, I wouldn't want anything in my Windows path to be seen by MSYS2, but if I started using it like I currently use cygwin, that would change.
Are any of these things open source? If so we can add PKGBUILDs ;-)
No, I don't have any cygwin projects, I just use it as a unix utility shell.
I'm checking out the qt5 patches to see if it makes any difference on my failed lto build :)
Hmm. I think qt5 lto isn't quite ready yet..
Actually sprucing up the qt5-git and qt5-static-git (if we have that? I'm on my phone only now) pkgbuilds would be a good idea I think. Lto will work there before a released version.
Check if your MSYSTEM exists and its value.
In my case
$MSYSTEM==MINGW64. The number of chars in$PATHbefore I started msys2 was1040chars... so I am not sure the problem is always caused by>1024chars in$PATH. But I did find that adding a line to/etc/fstabas suggested earlier in the thread helped. Perhaps there are multiple causes to this problem.I tried cutting down my path since it was 2000+ chars and got it to work but then went back to experiment a little more.
In cutting down my path, I removed all the directories with spaces in them. Turns out this was the key to fixing it on my system. When I put a path with spaces back in, it stopped working.
I used this in my path as an example:
C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-StaticI thought it might have been the parens so I tried replacing those but it didn't help. I also tried using single quotes and double quotes around the path but neither of those helped.
I replaced it with another path of the same length but without spaces to see if it was the length.
d:\ProgramFilesxxxxxxx\ATI-Technologies\ATI.ACE\Core-StaticIt worked fine with that one which makes me think the length isn't an issue.
I then tried clearing my whole path and setting it to just one entry with spaces in it:
C:\Program Files;It still has the problem with this one by itself.
So, long story short (kinda), I thought the path just needed to have spaces escaped.
I added this line to the /etc/profile
This is it in context:
So far it has worked for all the different examples I have tried it with. I'm curious to see if this works for others.
** FYI, I originally tried all the other things in this thread but removed them all so this is the only change I made from the base install.
I tried this but unfortunately it didn't work.
This bug is unfortunately meaning I'm having to stick to the original MSYS for now, so any other suggestions are very much welcome :-)
On Mon, Nov 10, 2014 at 1:25 PM, Ed Morley edmorley@users.sf.net wrote:
Unlucky! I did try to investigate this once and after a few hours of
head scratching it turned out that the problem vanished
mid-investigation :-(
All I can think is to compare with procmon or strace a working vs
not-working install. Does your 32bit install do things correctly?
Related
Tickets:
#97The latest release (msys2-x86_64-20141113.exe) seems to have fixed this for me now :-)
as your path is too long you should try a tool named LongPathTool for that..