#97 64-bit msys2 is not running my .bashrc or .bash_profile.

[Dan]

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

[Alexx83]

It need work without any steps.

[Dan]

I'm sorry, I don't understand what you mean.

Perhaps, "It should work without any steps," meaning that it should work (even though it doesn't)?

My msys32 bashrc loads fine, but msys64 does not. I could try a clean install, which I assume would work, but I wondered what could be wrong. I cannot reinstall bash, as far as I can tell, because it is part of the base system.

[Ray Donnelly]

I would try to diagnose what is wrong in the following order:
bash -x
strace
procmon
.. and compare outputs against your working 32bit MSYS2 using meld (or beyond compare)

[Dan]

I should have mentioned, bash --login works fine. It is only upon launching msys2 that bash doesn't load the bashrc. The cmd file that launches msys2 does call bash --login, so I am mystified as to why it doesn't load bashrc.

At that time, it must not know where HOME is, but I can't imagine why.

[Dan]

I modified the start cmd script to use (-x):

start %WD%mintty -i /msys2.ico /usr/bin/bash --login -x %*

I then compared the output. Everything is identical until the 64-bit abruptly stops, but the 32-bit continues, starting with the following lines:

+ '[' -f /home/adipose/.bashrc ']'
+ source /home/adipose/.bashrc

I will see if I can get strace working from the start script.

[Ray Donnelly]

Great, thanks for looking into this.

[Dan]

The strace was basically identical with all 32's replaced with 64's. It even appeared to be loading the .bashrc...

[Ray Donnelly]

This sounds strangely familiar to when I tried to investigate the same problem months ago.

[Dan]

Another clue: mingw64_shell.bat and mingw32_shell.bat load the .bashrc. The only real difference between those and msys2_shell.bat, is the variable MSYSTEM.

[Dan]

Not that it is correct, but setting the variable MSYSTEM to MSYS2 instead of MSYS, fixes the issue. I don't know what else it breaks, though.

[Dan]

Removing /usr/local/bin from the MSYS2_PATH in /etc/profile, fixes the issue:

MSYS2_PATH="/usr/bin:/bin"

I don't even have a /usr/local path, so I don't really understand why that's a big issue.

[crumpet75]

I am having the same issue but removing /user/local/bin from variable msys2_path in /etc/profile did not help.

I am starting msys2 with mingw64_shell.bat, which starts bash using /usr/bin/bash --login. I added some logging to /etc/profile, /etc/bash.bashrc, ~/.bash_profile, ~/.profile.

The following get sourced/executed:
/etc/profile
/etc/bash.bashrc

Whereas with cygwin (bash is started with --login), I see:
/etc/profile
/etc/bash.bashrc
* ~/.bash_profile

This seems to be a bug with msys2.

[crumpet75]

FYI... it seems a similar issue is being asked about here: http://stackoverflow.com/questions/24099179/msys2-does-not-source-profile

[Dan]

Your path is too long. Remove some things from your path to make it less than ~1000.

[crumpet75]

Thanks for the suggestion. I temporarily edited %PATH% and checked it in cmd.exe. (I tried editing directly in cmd.exe but also did it through control panel.) It is under 80 chars. I also edited /etc/profile so that existing $PATH is not appended to end.

Unfortunately it does not help. ~/.bash_profile is not sourced as expected...

[Dan]

try this

[crumpet75]

That worked.

After edit to fstab:

$ cat /etc/fstab
# For a description of the file format, see the Users Guide
# http://cygwin.com/cygwin-ug-net/using.html#mount-table

# DO NOT REMOVE NEXT LINE. It remove cygdrive prefix from path
none / cygdrive binary,posix=0,noacl,user 0 0

d:/Users/dparker /home/dparker ntfs binary,posix=0,user 0 0

The $PATH length didn't seem to be an issue. (Before msys2 loads, I count my %PATH% in cmd.exe to be 1040 chars. I put /etc/profile back to its out of the box state... and it seems the fstab edit makes it work.

It seems like the msys2 installer should be adding this mount point to the fstab for users. Otherwise many people will have the same issue.

Thanks for the tip.

[Dan]

I don't have such a line, and never needed one. But I discovered that a path > 1024 chars caused issues in msys64 (msys32 was ok).

I don't know the exact cause but it seems your issue was slightly different than mine.

[crumpet75]

Yes it could be a different issue. It is strange that I don't have a problem with > 1024 chars in msys64.

One thing that occurred to me over the weekend is that maybe the reason I need to add a line to the fstab is because my $HOME and %userprofile% is on a different drive than my %windir%==c:\windows... just a thought that may help developers.

(I am happy that with your help that I figured out a solution though - thanks.)

[Dan]

Yeah I thought about the drive letter issue, but it should just be based on %USERPROFILE% or %HOMEDRIVE%+%HOMEPATH%.

[Ray Donnelly]

What happens if you make one?

[Dan]

If I create /usr/local/bin, and leave it in the path, it does not load .bashrc.

[crumpet75]

As mentioned above... MSYS2_PATH="/usr/bin:/bin" didn't help me... and when I revert MSYS2_PATH back and mkdir -p /usr/local/bin, I don't see an improvement. ~/.bash_profile does not load on msys2. But it does load on cygwin.

[Dan]

It appears to be a simple length issue.

Replacing /usr/local/bin with /path567890 causes no problems.

Replacing /usr/local/bin with /path5678901 causes it to fail.

I have a fairly long path (1004 characters before prepending msys paths). Is there a 1024 limit on the PATH variable?

[Dan]

Even a 2048 length path has no issues in msys32, though.