Uncommenting MSYS2_PATH_TYPE=inherit in msys2.ini does not have any effect

[marcoxa]

Describe the bug

I am trying to inherit the W10 PATH in MSYS2, however, uncommenting MSYS2_PATH_TYPE=inherit in msys2.ini does not have any effect. The MSYS2 path is unchanged from the minimalistic starting one. The same happens with mingw32.ini and mingw64.ini.

My guess is that there is some inconsistency that crept in the msys2_shell.cmd script.

Note that this is a fresh MSYS2 installation.

Any clues about how this is happening?

Thanks

Marco

[jeremyd2019]

I believe those ini files only apply to the msys2-launcher exes, not to msys2_shell.cmd batch script.

[lazka]

You need to pass -use-full-path to msys2_shell.cmd

[marcoxa]

You need to pass -use-full-path to msys2_shell.cmd

I don't launch from the command line. I am not sure what gets invoked "out of the box" by double clicking on the shortcut (o) or from the Start menu, but I would expect that a .ini file should work; both from the CLI or from the GUI.

(o) I know I can find out. But (1) I am lazy and (2) time is a tyrant (oo)
(oo) Yes, I also develop and maintain FOSS. I know the drill etc etc, YMMV etc etc :) :)

[lazka]

ok, thanks, I think the shortcut just calls msys2_shell.cmd, so you'd have to edit the shortcut

[marcoxa]

ok, thanks, I think the shortcut just calls msys2_shell.cmd, so you'd have to edit the shortcut

Yes. I know.

But that is not what I want. I want the uncommenting of the MSYS2_PATH_TYPE in the .ini to work as expected.

Moreover, if I clicked on the actual program and not on the shortcut I would have a different behavior.

[lazka]

Understood. Thy are currently two different things https://packages.msys2.org/package/msys2-launcher?repo=msys&variant=x86_64 and the installer, so not that easy.

[marcoxa]

I urge you to unify them. Users do not like surprises.

[mingwandroid]

MSYS2 is open source, instead of urging others to do something, perhaps you could try to fix this? It would be very welcome.

[marcoxa]

Look. I understand you may have felt that the word "urge" was a tad strong. Having said that, as I said before, I know the drill for FOSS.

It would take me quite an investment in time to be able to fix this, even if the fix may be three lines of code. Alas, time is a tyrant.

As it is it is an open bug. Just keep it as such until it gets fixed.

All the best

[TaoK]

OK, I have to agree with @marcoxa here - this behavior is extremely surprising and prone to causing many people headaches:

• There's an ini file, it's documented, it has the "inherit" option I need right there, commented.
• When I edit it (uncomment the line) and double-click on the "msys2.exe" file right next to it everything behaves as expected, I now get the path behavior I needed in this window
• I finish what I was doing, go do other things
• Sometime later, I open msys2 again the way I always have, the "normal" windows way: Windows key, type "msys", hit enter.
• The resulting window seems to have "forgotten" the change I made before - and I can spend a good long while understanding that these are different ways of opening msys2, and that the "ini" file is simply not supported for the standard windows shortcut...

[marcoxa]

Yep. This is a bug. No other ways to describe it.

[PerthGoat]

This definitely should not be defined behavior, it got me too

[vale46]

OK, I have to agree with @marcoxa here - this behavior is extremely surprising and prone to causing many people headaches:

* There's an ini file, it's documented, it has the "inherit" option I need right there, commented.

* When I edit it (uncomment the line) and double-click on the "msys2.exe" file right next to it everything behaves as expected, I now get the path behavior I needed in this window

* I finish what I was doing, go do other things

* Sometime later, I open msys2 again the way I always have, the "normal" windows way: Windows key, type "msys", hit enter.

* The resulting window seems to have "forgotten" the change I made before - and I can spend a good long while understanding that these are different ways of opening msys2, and that the "ini" file is simply not supported for the standard windows shortcut...

a proposed solution is by appending "-use-full-path" to the windows command script target shortcut, which sit in this directory:
c:\Users\<user-name>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\MSYS2 64bit\. I'm also able to achieve the same behavior by creating user environment variable MSYS2_PATH_TYPE=inherit in Windows directly, but doing the same in msys2.ini didn't work.

However, I see ORIGINAL_PATH enviroment variable has the W10 inherited paths; which I expected to be appended to PATH. Is this expected behavior?

Should note that I have Cygwin installed side-by-side with MYS2, which I installed recently to build Emacs. Although I've taken care in .bashrc/.bashrc_profile to ensure which application (MSys or Cygwin) is launching at startup, but honestly, I've not dug deeper to figure out if Cygwin and MSYS2 can in fact co-exist, without tripping each other.

[coreysnodgrass]

Maybe the fix is to add the environment variable and change the shortcut to "-use-full-path" in the windows installer for msys2 that way it would just come that way by default?

Also, adding MSYS2_PATH_TYPE with a value of inherit and uncommenting MSYS2_PATH_TYPE in the msys2.ini in the directory worked for me. I'm not sure if you need both and I'm satisfied with just leaving it because it works now, lol.

[AntumDeluge]

Uncommenting the line in the associated .ini file works for me, when executing the msys2.exe/mingw32.exe/mingw64.exe executable. However, this does not work if executing mintty directly. In that case, the solution was to add MSYS2_PATH_TYPE="inherit" to the beginning of /etc/profile.

[julie777]

I just found out that the shortcut created in the start menu during installation is a special terminal shortcut with a terminal tab. It doesn't read config file in C:\msys64\mingw64.ini. If I just run "C:\msys64\mingw64.exe" it does read the config file and MSYS2_PATH_TYPE=inherit works.

[pcarstens]

I have a Visual Studio Code setup where the integrated terminal is configured to use C:\msys64\usr\bin\bash.exe.
Setting MSYS2_PATH_TYPE to "inherit" as a Windows environment variable has worked to enable the inheritance feature.
Setting it in any of the INI-files or .bash_profile did not.

[marcoxa]

Wow. Almost 2 years and still open :)

[terrehbyte]

Respectfully, work seems to be landing in relevant repositories to address the inconsistencies around when the .ini files do and don't apply as observed with the start menu shortcuts:

msys2/msys2-installer#50

There's no release with that PR at the moment, but hopefully it'll help.

[tswain555]

Hi Peeps; I am having a similar issue. Only when I run under > M$ DOS < it can't find libint-8.dll
Works in MSYS2 NP.
Which brings me to "Tony's Law of Programmer/Sesame St. equivalency which says...
"Every Programmer will eventually devolve into singing the song one of these things is not like the other " ;)

[AntumDeluge]

I am having a similar issue. Only when I run under > M$ DOS < it can't find libint-8.dll Works in MSYS2 NP.

You probably need to add MSYS2 paths to system's PATH variable.

[sskras]

I came here from the comments on this S.O. answer:
https://stackoverflow.com/questions/45404631/msys2-not-finding-windows-programs-despite-msys2-path-type-inherit/50992294#50992294

I worked around the issue by running msys2_shell.cmd -use-full-path, too.

Any summary about what's happening?

[ypmessiah]

Seems to me like this happens because msys2.exe isn't a shell. It's an external launcher that configures /etc/profile based on how msys2.ini is configured.

For whatever reason if you launch msys.exe from an external terminal (i.e. cmder, new windows terminal, IDE) it doesn't function as intended, and thus bash starts with MSYS2_PATH_TYPE=inheric commented out, which causes this issue.

[marcoxa]

Thank you @Xaffen. It looks like this is the first message that at least hints at a diagnosis of the possible issue.

[elieux]

This ticket has devolved into multiple people complaining about multiple things AFAICT. The inconsistency between using msys2.exe (and friends) and the Start menu shortcuts seems to have been resolved in msys2/msys2-installer#50.

If you still suffer from a related issue, please create a new ticket and describe it there.

[devRabbani]

Best option is to create new system variable and add MSYS2_PATH_TYPE as the variable name and inherit as the variable value.

[edwardbeckett]

Look. I understand you may have felt that the word "urge" was a tad strong. Having said that, as I said before, I know the drill for FOSS.

It would take me quite an investment in time to be able to fix this, even if the fix may be three lines of code. Alas, time is a tyrant.

As it is it is an open bug. Just keep it as such until it gets fixed.

All the best

You really should consider how disrespectful the tone of your message is... The sentiment you are expressing basically states, "It doesn't take a lot of time and effort to make a request asking someone to refactor the code to function the way you expect it to work - yet, you don't have the time or the inclination to do it for the good of not only yourself but also the open source community...

[marcoxa]

Dear @edwardbeckett

as you may have noticed, this thread has been going for some time now.

It appears that my original issue (2020) was finally resolved (in 2023).

However, since I read your comment, I had an urge to respond, just because I feel that many people who work on FOSS seem not to understand that many FOSS users (who also happen to contribute to FOSS (*)) have limited time (and, at my age, patience :) cfr., TOWANDA!).

If you re-read the whole thread, you would have found out that my original assessment was essentially right (and other people agreed). Bottom line, I know what I get when I deal with FOSS; but it appears that many FOSS enthusiasts have time management issues, and forget that the F stands for Free as in "Liberty" and not as in "Beer".

So, here I state my present and future standard response to comments like "it's FOSS, you should contribute": TOWANDA!

Cheers

MA

(*) Hey, I just contributed to Emacs 30.x. Don't tell me you are a VS Code or (worse) vim user! (insert image of Munch's "Scream" here) :) :) :) :)

Look. I understand you may have felt that the word "urge" was a tad strong. Having said that, as I said before, I know the drill for FOSS.
It would take me quite an investment in time to be able to fix this, even if the fix may be three lines of code. Alas, time is a tyrant.
As it is it is an open bug. Just keep it as such until it gets fixed.
All the best

You really should consider how disrespectful the tone of your message is... The sentiment you are expressing basically states, "It doesn't take a lot of time and effort to make a request asking someone to refactor the code to function the way you expect it to work - yet, you don't have the time or the inclination to do it for the good of not only yourself but also the open source community...