Hi Those that know and love the bash shell understand that when it starts a non-interactive version (like when you run a command or use the --login argument) it sources the /etc/profile and ~/.bash_profile to set up the environment when one starts an interactive shell bash sources the profile, and then also the .bashrc file. The best practice guidance is that all definitions for CLI things .. aliases, function definitions etc .. should go in the .bashrc because they are only of interest in an interactive shell. so .. far, all good - the kicker is that in an MSYS2 bash shell the standard .bashrc does nothing. It stops dead at line that tests for it running interactively: [[ "$-" != *i* ]] && return 0 for those that are not fluent in bash, this means test that the env var "-" is not equal to the letter i , for interactive, and if that is true, then go on to execute the other side of the AND (&&) and thus return .. stopping the script Now one might ask, why is a shell script that should only run in an interactive shell testing for the non-interactive state .. and if that is so, stopping? the answer is .. there is an exception for remote execution. If one uses ssh to open a remote shell the dash env var, the "-", has a value other than "i", even tho it is running in an interactive mode. The explanations that I found say that connections for data transfer via ssh will be messed up by text being sent back down the channel .. as would be done by an echo statement emitting a status or error message to the user from the .bashrc file. SO .. that test that stops the .bashrc from running is there to prevent feedback messing up an unattended data transfer Here is the thing .. Msys shells run as if they were remote logins. So the two normal checks fail, the one i showed for the dash env var, and the other standard test for the PS1 env var being defined. If one wants to use aliases and functions in an MSYS2 shell there are two things to change to get things working 1 add a bit of code to the .bash_profile, or the /etc/profile, that will source the users .bashrc 2 edit the bash_completion.sh script in /etc/profiles.d to remove the test for ${PS1} being defined (line 2 in the file) Item 1 is something you should not need to do, and is a deprecated action .. but hey, it solves the problem Item 2 should also not need to be done, but without it /etc/profile does not complete, so your ~/bash_profile does not run and so none of the stuff you want set for your interactive shell is ignored. this issue will be of interest to those using the Msys2 based process to build the app on WIndows .. I noticed because i am using the Msys2 shell inside Visual Studio Code and it is ignoring my include file settings .. the app builds thanks to CMake taking control of the build environment, but the editor complains about missing libintl.h, fontconfig.h and source code files that i know are installed .. just not visible to the VSC app, even tho the Msys2 shell knows exactly where they all are. VSC is a good tool for finding how a big tangled mess of source code works .. but only if all the connections can be traced to their sources .. which is why i have been stressing over how pacman works, and how VSC needs to be configured .. i am getting there .. but still a LOT of blanks to fill in sorry for all the ear bending, and thanks for the patient, helpful answers -- jeff is vulcan_ in the cloud