Repository: conan-io/conan

Issue:
run_in_windows_bash runs commands inside bash --login, which clobbers the environment
When msys2 commands are run inside `run_in_windows_bash`, they are run inside `bash --login`, which overrides many environment variables e.g. `PKG_CONFIG_PATH`:

https://github.com/conan-io/conan/blob/develop/conans/client/tools/win.py#L611

This prevents the `PKG_CONFIG_PATH` functionality of `AutoToolsEnvironment.configure()` working correctly.

Why `--login` used here? It seems incorrect.

@lasote - I believe you introduced this originally?


Discussion:
I'm not even convinced these commands should be running in bash. `env` would be the better choice - it's a very light-weight command that will simply read the shebang and pass through to the appropriate executor.
Thanks for the feedback @jhol. I'm terribly afraid of changing it honestly. But indeed I should take a look. 
Have you tried to use the `env` parameter of the `run_in_windows_bash`? https://docs.conan.io/en/latest/reference/tools.html#tools-run-in-windows-bash
Hi @lasote , thanks for your response.

The context of this, is that my client is a company who previously had a python-based proprietary framework similar to Conan, which they are now deprecating. We are targeting Linux x86_64, ARM, and Windows (with a mixed approach using both Msys2 and Visual Studio).

With our background of several years experience with the proprietary framework, we have a system that we can compare to Conan.

My opinion is that no Conan recipe should be forced to be more complicated or less featureful than our proprietary framework's recipes.

In the proprietary framework, it took several years of trial and error to get the AutoTools default behavior exactly right (particularly on Windows), but in the end most recipes could be built for multiple platforms with an extremely minimal recipe. My hope is that Conan can eventually match this, and in my testing so far, it's not far off except for a couple of issues: this one and #4334.

In the meantime, I am planning to monkey-patch Conan's `run_in_windows_bash` to take out `--login` as a temporary measure, so I will be able to confirm if it solves our issues. Our gstreamer recipes are particularly badly affected, because of their heavy reliance on `pkg-config`, so hopefully it will solve everything.

My advice would be to drop the `--login` bash argument. To my understanding, this is designed to spawn a fresh user session with an environment which is populated by executing `.bashrc` and friends. I don't see why it would appropriate to use it here.

Does Conan have a policy on backwards compatibility?

Perhaps one approach would be to deprecate `run_in_windows_bash` altogether, and replace it with `run_in_windows_env` that will execute the command in Msys2's `/usr/bin/env`. `run_in_windows_bash` could stay around for a few releases - but marked deprecated using a decorator of some kind that would print a warning. Or keep it forever if you prefer.

As for `AutoToolsEnvironment`? I can't see any reason why it is beneficial to run `./configure` inside `bash --login`. However, it is a breaking change, and there's a chance someone might be negatively affected. It seems like this would be a somewhat common occurance while Conan is still in active development.

(I don't really see the value in the `AutoToolsEnvironment.configure` `win_bash` parameter - in my opinion this behavior should be automatic. All our recipes call it like this: `autotools.configure(..., win_bash=settings.os_build == 'Windows'`)
Hi, thanks so much for your additional feedback!

 >Does Conan have a policy on backwards compatibility?

Yes, we cannot break anything in the 1.X versions. But I'm sure we could find a way, let's think about it.
> In the meantime, I am planning to monkey-patch Conan's run_in_windows_bash to take out --login as a temporary measure, so I will be able to confirm if it solves our issues. 

Please, let me know how it goes!
The monkey patch did indeed fix the issue. `--login` argument should be removed from `client.tools.run_in_windows_bash`
what if we add argument `login` to the `tools.run_in_windows_bash` (default=True)?
Yes, I think that would be a good solution, keep the current behavior, allow to opt-out, and maybe annotate for changing that default in Conan 2.0

Resolving patch:
diff --git a/conans/client/tools/win.py b/conans/client/tools/win.py
--- a/conans/client/tools/win.py
+++ b/conans/client/tools/win.py
@@ -575,7 +575,8 @@ def unix_path(path, path_flavor=None):
     return None
 
 
-def run_in_windows_bash(conanfile, bashcmd, cwd=None, subsystem=None, msys_mingw=True, env=None):
+def run_in_windows_bash(conanfile, bashcmd, cwd=None, subsystem=None, msys_mingw=True, env=None,
+                        with_login=True):
     """ Will run a unix command inside a bash terminal
         It requires to have MSYS2, CYGWIN, or WSL
     """
@@ -637,7 +638,8 @@ def get_path_value(container, subsystem_name):
         to_run = 'cd "%s"%s && %s ' % (curdir, hack_env, bashcmd)
         bash_path = OSInfo.bash_path()
         bash_path = '"%s"' % bash_path if " " in bash_path else bash_path
-        wincmd = '%s --login -c %s' % (bash_path, escape_windows_cmd(to_run))
+        login = "--login" if with_login else ""
+        wincmd = '%s %s -c %s' % (bash_path, login, escape_windows_cmd(to_run))
         conanfile.output.info('run_in_windows_bash: %s' % wincmd)
 
         # If is there any other env var that we know it contains paths, convert it to unix_path
diff --git a/conans/model/conan_file.py b/conans/model/conan_file.py
--- a/conans/model/conan_file.py
+++ b/conans/model/conan_file.py
@@ -247,13 +247,13 @@ def package_info(self):
         """
 
     def run(self, command, output=True, cwd=None, win_bash=False, subsystem=None, msys_mingw=True,
-            ignore_errors=False, run_environment=False):
+            ignore_errors=False, run_environment=False, with_login=True):
         def _run():
             if not win_bash:
                 return self._conan_runner(command, output, os.path.abspath(RUN_LOG_NAME), cwd)
             # FIXME: run in windows bash is not using output
             return tools.run_in_windows_bash(self, bashcmd=command, cwd=cwd, subsystem=subsystem,
-                                             msys_mingw=msys_mingw)
+                                             msys_mingw=msys_mingw, with_login=with_login)
         if run_environment:
             with tools.run_environment(self):
                 if OSInfo().is_macos:


Test patch:
diff --git a/conans/test/unittests/util/tools_test.py b/conans/test/unittests/util/tools_test.py
--- a/conans/test/unittests/util/tools_test.py
+++ b/conans/test/unittests/util/tools_test.py
@@ -1017,8 +1017,9 @@ def __call__(self, command, output, log_filepath=None,
             self.assertIn('path\\to\\mybash.exe --login -c', conanfile._conan_runner.command)
 
         with tools.environment_append({"CONAN_BASH_PATH": "path with spaces\\to\\mybash.exe"}):
-            tools.run_in_windows_bash(conanfile, "a_command.bat", subsystem="cygwin")
-            self.assertIn('"path with spaces\\to\\mybash.exe" --login -c', conanfile._conan_runner.command)
+            tools.run_in_windows_bash(conanfile, "a_command.bat", subsystem="cygwin",
+                                      with_login=False)
+            self.assertIn('"path with spaces\\to\\mybash.exe"  -c', conanfile._conan_runner.command)
 
         # try to append more env vars
         conanfile = MockConanfile()