[bug] self.win_bash and msys2, internal commands not found

[lasote]

While testing this PR: #12095

I saw that I couldn't run any command belonging to msys2 (installed packages there) located in /usr/bin, but there were tests that work because they use the @pytest.mark.tool_msys2 that is putting the C:/msys64/usr/bin in the path in the conftest.py.

I think that is very confusing because a recipe trying to run a command like autoconf in msys2 doesn't find it, nevertheless, we have 2 conf to "set up" the environment: tools.microsoft.bash:subsystem and tools.microsoft.bash:path. So we could:

0. Ignore this and expect the user to have the c:/mysys2/../usr/bin in the path.
1. Somehow declare the PATH to the folder "/usr/bin" before running the command
2. Have a conf for that path? Looks like too much.

PD: I haven't tested it this happens in other subsystems.
PD: This is failing in develop2 too.

[jellespijker]

@lasote I have a feeling it might be related to: #11980 (which has a proposed fix: #11980) or more likely #11986

[lasote]

Yes, thanks, #11986 is the one. I see that you closed the issue because of using of msys2 conan center package. But I still think there is a bug in Conan, working with a local msys2 installation should also work.

[jellespijker]

Agreed. My proposed solution was making sure the parent directory of the bash.exe from the conf value was added to the msys2 generated file. But that caused some issue at the time: #11987

[memsharded]

I am checking this, and this works:

[settings]
arch=x86_64
os=Windows
compiler=gcc
compiler.version=6
compiler.libcxx=libstdc++11

[conf]
tools.microsoft.bash:subsystem=msys2
tools.microsoft.bash:path=C:/ws/msys64/usr/bin/bash.exe
tools.env.virtualenv:auto_use=True

[buildenv]
PATH=+(path)C:/ws/msys64/usr/bin

from conan import ConanFile


class HelloConan(ConanFile):
    name = "hello"
    version = "0.1"

    # Binary configuration
    settings = "os", "arch"

    win_bash = True

    def build(self):
        self.run("ar")

The winbash might be redundant here, of course, not strictily necessary