Make the bash_program() helper in gix-testtools a little more robust
#1864
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Feb 26, 2025
EliahKagan
force-pushed
the
run-ci/bash-program
branch
from
68121af to
69182bd
Compare
EliahKagan
force-pushed
the
run-ci/bash-program
branch
from
69182bd to
7c0af6a
Compare
EliahKagan
force-pushed
the
run-ci/bash-program
branch
from
7c0af6a to
bbd5a66
Compare
|
The 90 failures when the non-shim This is the case for the failures in the first two groups: both the group labeled that way, but also the group where the direct cause was the inability to run that script because its associated lock timed out while it was being run unsuccessfully by so many other tests. The other groups are not causally related to that fixture, but seem to relate to symlinks. Full details are in this gist. As noted in the gist readme, the results are in two plain text files: grouped and full raw output. I think the grouped view is more useful, but when I made it deliberately omitted details, which I think are sometimes significant. The grouped view is also shown here, split into groups by placing each in its own code block but otherwise the same as in the gist: The other piece of information that I think it is interesting and relevant enough to include here is the full output from the That is the direct cause of 72 test failures and, in the manner described above, the close indirect cause of 8 others. I am not yet clear on why this happens. I assume it is due to the wrong commands being run, probably from my other MSYS2 installation that is not part of Git for Windows (as in #1862 (comment), except less weird here) or other things being wrong in the environment. If so, then preferring the shim should fix it and #1862 should be ready to go (as should this, one it is made to use the shim again). But I want to look for other possible causes of failure, in case there is another problem that might affect #1862. (If there is another problem, it might affect this PR too, but I think this is lower stakes since it only affects |
EliahKagan
added a commit
to EliahKagan/gitoxide
that referenced
this pull request
Mar 16, 2025
The change in the previous commit of switching to the non-shim `bash.exe` in `(git root)/usr/bin` causes problems, because the environment may not be correct for shell commands and scripts. In particular, the `PATH` might not enable standard POSIX tools to be found, or the tools that are found may interoperate incorrectly with the shell. The latter caused failures in GitoxideLabs#1862 in an analogous choice of `sh.exe`, which were addressed by preferring the shim when available. See: - GitoxideLabs#1862 (comment) Here, 90 tests started to fail when the test suite was run locally from PowerShell (i.e. not a Git Bash environment) on a Windows 10 system that, in addition to a full Git for Windows installation, contains a separate non-GfW MSYS2 installation whose `bin` directories are in `PATH` even in non-MSYS2 environments. The failures were described, and most of them investigated, as follows: - GitoxideLabs#1864 (comment) - https://gist.github.com/EliahKagan/3c5eebd091e66d8c912fddbce0a064cd - https://gist.github.com/EliahKagan/17066ad1f7b0aa98e4fdf4642abe1d93 Most failures, including all those that were unintuitive, were directly or indirectly due to the `make_remote_repos.sh` fixture script encountering the error: fatal: bad config line 10 in file ./config This happened due to the same incorrect behavior of `>>`, when used by a shell that links to one `msys-2.0.dll` running a program that links to a different `msys-2.0.dll` of another version or build, as caused the failure encountered with the non-shim in GitoxideLabs#1862. (It may be the handful of other failures are also caused by this `>>` problem, but as of now that has not been examined.) This commit temporarily instruments that fixture script so that, when tests are run, the observations and analysis in the last gist above can be confirmed. (These changes are also shown there.)
EliahKagan
added a commit
to EliahKagan/gitoxide
that referenced
this pull request
Mar 16, 2025
The change in the previous commit of switching to the non-shim `bash.exe` in `(git root)/usr/bin` causes problems, because the environment may not be correct for shell commands and scripts. In particular, the `PATH` might not enable standard POSIX tools to be found, or the tools that are found may interoperate incorrectly with the shell. The latter caused failures in GitoxideLabs#1862 in an analogous choice of `sh.exe`, which were addressed by preferring the shim when available. See: - GitoxideLabs#1862 (comment) Here, 90 tests started to fail when the test suite was run locally from PowerShell (i.e. not a Git Bash environment) on a Windows 10 system that, in addition to a full Git for Windows installation, contains a separate non-GfW MSYS2 installation whose `bin` directories are in `PATH` even in non-MSYS2 environments. The failures were described, and most of them investigated, as follows: - GitoxideLabs#1864 (comment) - https://gist.github.com/EliahKagan/3c5eebd091e66d8c912fddbce0a064cd - https://gist.github.com/EliahKagan/17066ad1f7b0aa98e4fdf4642abe1d93 Most failures, including all those that were unintuitive, were directly or indirectly due to the `make_remote_repos.sh` fixture script encountering the error: fatal: bad config line 10 in file ./config This happened due to the same incorrect behavior of `>>`, when used by a shell that links to one `msys-2.0.dll` running a program that links to a different `msys-2.0.dll` of another version or build, as caused the failure encountered with the non-shim in GitoxideLabs#1862. (It may be the handful of other failures are also caused by this `>>` problem, but as of now that has not been examined.) This commit temporarily instruments that fixture script so that, when tests are run, the observations and analysis in the last gist above can be confirmed. (These changes are also shown there.)
EliahKagan
force-pushed
the
run-ci/bash-program
branch
2 times, most recently
from
e35cf14 to
55f6be2
Compare
EliahKagan
added a commit
to EliahKagan/gitoxide
that referenced
this pull request
Mar 16, 2025
The change in the previous commit of switching to the non-shim `bash.exe` in `(git root)/usr/bin` causes problems, because the environment may not be correct for shell commands and scripts. In particular, the `PATH` might not enable standard POSIX tools to be found, or the tools that are found may interoperate incorrectly with the shell. The latter caused failures in GitoxideLabs#1862 in an analogous choice of `sh.exe`, which were addressed by preferring the shim when available. See: - GitoxideLabs#1862 (comment) Here, 90 tests started to fail when the test suite was run locally from PowerShell (i.e. not a Git Bash environment) on a Windows 10 system that, in addition to a full Git for Windows installation, contains a separate non-GfW MSYS2 installation whose `bin` directories are in `PATH` even in non-MSYS2 environments. The failures were described, and most of them investigated, as follows: - GitoxideLabs#1864 (comment) - https://gist.github.com/EliahKagan/3c5eebd091e66d8c912fddbce0a064cd - https://gist.github.com/EliahKagan/17066ad1f7b0aa98e4fdf4642abe1d93 Most failures, including all those that were unintuitive, were directly or indirectly due to the `make_remote_repos.sh` fixture script encountering the error: fatal: bad config line 10 in file ./config This happened due to the same incorrect behavior of `>>`, when used by a shell that links to one `msys-2.0.dll` running a program that links to a different `msys-2.0.dll` of another version or build, as caused the failure encountered with the non-shim in GitoxideLabs#1862. (It may be the handful of other failures are also caused by this `>>` problem, but as of now that has not been examined.) This commit temporarily instruments that fixture script so that, when tests are run, the observations and analysis in the last gist above can be confirmed. (These changes are also shown there.)
EliahKagan
added a commit
to EliahKagan/gitoxide
that referenced
this pull request
Mar 16, 2025
The change in the previous commit of switching to the non-shim `bash.exe` in `(git root)/usr/bin` causes problems, because the environment may not be correct for shell commands and scripts. In particular, the `PATH` might not enable standard POSIX tools to be found, or the tools that are found may interoperate incorrectly with the shell. The latter caused failures in GitoxideLabs#1862 in an analogous choice of `sh.exe`, which were addressed by preferring the shim when available. See: - GitoxideLabs#1862 (comment) Here, 90 tests started to fail when the test suite was run locally from PowerShell (i.e. not a Git Bash environment) on a Windows 10 system that, in addition to a full Git for Windows installation, contains a separate non-GfW MSYS2 installation whose `bin` directories are in `PATH` even in non-MSYS2 environments. The failures were described, and most of them investigated, as follows: - GitoxideLabs#1864 (comment) - https://gist.github.com/EliahKagan/3c5eebd091e66d8c912fddbce0a064cd - https://gist.github.com/EliahKagan/17066ad1f7b0aa98e4fdf4642abe1d93 Most failures, including all those that were unintuitive, were directly or indirectly due to the `make_remote_repos.sh` fixture script encountering the error: fatal: bad config line 10 in file ./config This happened due to the same incorrect behavior of `>>`, when used by a shell that links to one `msys-2.0.dll` running a program that links to a different `msys-2.0.dll` of another version or build, as caused the failure encountered with the non-shim in GitoxideLabs#1862. (It may be the handful of other failures are also caused by this `>>` problem, but as of now that has not been examined.) This commit temporarily instruments that fixture script so that, when tests are run, the observations and analysis in the last gist above can be confirmed. (These changes are also shown there.)
EliahKagan
force-pushed
the
run-ci/bash-program
branch
from
55f6be2 to
e0b422a
Compare
|
As described and analyzed in this gist (see also dd585a3), most of the failures--specifically, those in the first two groups listed above in #1864 (comment), pertaining to It becomes malformed when the fixture script attempts to append to it with I had not expected that this specific mechanism would be being the failures here. I am still not sure if it is behind all of them. I investigated those failures because they comprise most of the local failures observed here, and because they were not intuitive. The other failures are intuitive, and most seem to be related to symlinks which one would expect could have problems when using the wrong version of POSIX tools on Windows. But a cursory look suggests they might also be due to this The failures that worried me and made me wonder if I was missing something that couldn't be addressed by preferring the shim have been investigated. It seems to me that it is not necessary to investigate the other failures before moving forward with #1862 or this PR. The problem here is fixed, by using the shim first. Details can be seen in the diff. Before marking either of #1862 or this as ready, I will want to make sure that the local tests all pass with the changes here, both without Edit: As shown in this other gist, with the version that prefers to use the shim, this did not break anything in the local tests. I ran the test suite four times, for the four relevant combinations of whether the changes from #1862 were included in the test and whether generated archives were allowed to be used. All runs were from PowerShell (to test the environment that failed when the shim was not preferred). Both as this PR stands, and if it is replayed atop the changes from #1862:
So the local results look good. Regarding:
Really this and #1862 could be merged in either order with no rebasing or anything else done in between. I think it might be slightly easier to understand the history if #1862 is merged first, since some of the changes here to Even more minor than that is that it might help slightly when looking at the commit history if this is rebased after #1862 is merged, but that is extremely minor since they are touching different parts of the code entirely. It is only for conceptual reasons that it could potentially be slightly confusing for their commits to appear interleaved when linearized. If #1862 is merged first, I could rebase this and I think the new capabilities discussed in #1883 would allow me to merge it myself as well. (Actually, from the UI it looks like GitHub would allow me to merge #1862 or this already.) |
EliahKagan
changed the title
bash_program() helper in gix-testtools more robustbash_program() helper in gix-testtools a little more robust
|
Thanks a lot for sharing. Also, it's great to see these PRs become mergeable.
|
Yes, I would say it shouldn't be possible for |
EliahKagan
added a commit
to EliahKagan/gitoxide
that referenced
this pull request
Mar 18, 2025
Now that Git for Windows 2.49.0 has a stable release, this changes the upgrade step that was added to `test-fixtures-windows` in 4237e5a (GitoxideLabs#1870), so that it downloads an installer from the release marked as "latest", rather than the release that has the newest tag. The release marked "latest" is usually a stable release in projects that have any stable releases, and in particular it is a stable release in Git for Windows. This is *not* needed to switch from the release candidate to the stable release for 2.49.0. The download logic already in place currently gets the stable release automatically, because it is the newest tag. Nonetheless, there are three reasons to prefer the "latest" tag to get the stable release, now that the stable release is available. In descending order of significance, they are: - We upgrade to work around GitoxideLabs#1849, for which 2.49.0 is preferable to 2.48.1 (which the Windows runner images currently have). Continuing to take the newest tag will eventually take a pre-release for the next version. That would probably work, but it is not currently a goal. There is sometimes a delay between when a stable release of Git for Windows comes out and when the stable runner images are released with it. (Pre-release runner images exist, but they are not run on GitHub-hosted runners.) So even assuming this upgrade step is to be removed once it is no longer needed, it could easily end up remaining long enough for a new Git for Windows pre-release to come out. - An update may potentially be released for an earlier minor version (y in x.y.z), in which case the tag for it would be newer and we would downgrade instead. Now that the release marked "latest" is usable here, we can use it and avoid that. - If we decide to eventually deliberately test pre-releases, the step added in GitoxideLabs#1849 would probably not be usable in that form, because it could take either the next pre-release or a patch to an ealier release per the above points, and also for the separate reason that this CI job is not necessarily where we would want to test that. (As one example, there is currently no CI testing of the Git for Windows SDK, even though supporting it is an explicit goal discussed in GitoxideLabs#1758, GitoxideLabs#1761, GitoxideLabs#1862, and GitoxideLabs#1864. If that is added, it may be a more opportune way to test prereleases.)
EliahKagan
added a commit
to EliahKagan/gitoxide
that referenced
this pull request
Mar 18, 2025
Now that Git for Windows 2.49.0 has a stable release, this changes the upgrade step that was added to `test-fixtures-windows` in 4237e5a (GitoxideLabs#1870), so that it downloads an installer from the release marked as "latest", rather than the release that has the newest tag. The release marked "latest" is usually a stable release in projects that have any stable releases, and in particular it is a stable release in Git for Windows. This is *not* needed to switch from the release candidate to the stable release for 2.49.0. The download logic already in place currently gets the stable release automatically, because it is the newest tag. Nonetheless, there are three reasons to prefer the "latest" tag to get the stable release, now that the stable release is available. In descending order of significance, they are: - We upgrade to work around GitoxideLabs#1849, for which 2.49.0 is preferable to 2.48.1 (which the Windows runner images currently have). Continuing to take the newest tag will eventually take a pre-release for the next version. That would probably work, but it is not currently a goal. There is sometimes a delay between when a stable release of Git for Windows comes out and when the stable runner images are released with it. (Pre-release runner images exist, but they are not run on GitHub-hosted runners.) So even assuming this upgrade step is to be removed once it is no longer needed, it could easily end up remaining long enough for a new Git for Windows pre-release to come out. - An update may potentially be released for an earlier minor version (y in x.y.z), in which case the tag for it would be newer and we would downgrade instead. Now that the release marked "latest" is usable here, we can use it and avoid that. - If we decide to eventually deliberately test pre-releases, the step added in GitoxideLabs#1849 would probably not be usable in that form, because it could take either the next pre-release or a patch to an ealier release per the above points, and also for the separate reason that this CI job is not necessarily where we would want to test that. (As one example, there is currently no CI testing of the Git for Windows SDK, even though supporting it, in general and for running the test suite, is an explicit goal discussed in GitoxideLabs#1758, GitoxideLabs#1761, GitoxideLabs#1862, and GitoxideLabs#1864. If that is added, it may be a more opportune way to test prereleases.)
EliahKagan
added a commit
to EliahKagan/gitoxide
that referenced
this pull request
Mar 18, 2025
The change in the previous commit of switching to the non-shim `bash.exe` in `(git root)/usr/bin` causes problems, because the environment may not be correct for shell commands and scripts. In particular, the `PATH` might not enable standard POSIX tools to be found, or the tools that are found may interoperate incorrectly with the shell. The latter caused failures in GitoxideLabs#1862 in an analogous choice of `sh.exe`, which were addressed by preferring the shim when available. See: - GitoxideLabs#1862 (comment) Here, 90 tests started to fail when the test suite was run locally from PowerShell (i.e. not a Git Bash environment) on a Windows 10 system that, in addition to a full Git for Windows installation, contains a separate non-GfW MSYS2 installation whose `bin` directories are in `PATH` even in non-MSYS2 environments. The failures were described, and most of them investigated, as follows: - GitoxideLabs#1864 (comment) - https://gist.github.com/EliahKagan/3c5eebd091e66d8c912fddbce0a064cd - https://gist.github.com/EliahKagan/17066ad1f7b0aa98e4fdf4642abe1d93 Most failures, including all those that were unintuitive, were directly or indirectly due to the `make_remote_repos.sh` fixture script encountering the error: fatal: bad config line 10 in file ./config This happened due to the same incorrect behavior of `>>`, when used by a shell that links to one `msys-2.0.dll` running a program that links to a different `msys-2.0.dll` of another version or build, as caused the failure encountered with the non-shim in GitoxideLabs#1862. (It may be the handful of other failures are also caused by this `>>` problem, but as of now that has not been examined.) This commit temporarily instruments that fixture script so that, when tests are run, the observations and analysis in the last gist above can be confirmed. (These changes are also shown there.)
EliahKagan
force-pushed
the
run-ci/bash-program
branch
from
e0b422a to
720ae4a
Compare
|
Due to the effect of subsequent minor rebases both in #1862 and here (just to bring them forward, not to change them), which were done in that order, I think it no longer matters whether this is rebased (again) after merging #1862. Although the author timestamps are still interleaves, the committer timestamps on all commits in #1862 are now earlier than on all commits here. If that PR is merged first, then I think in practice they will be shown linearized in the expected way, with that PR's commits first, unless a tool is deliberately configured to do otherwise. Edit: The failure is due to #1896, which is not specific to this PR. I'll rerun. |
Starting in GitoxideLabs#1712, `gix-testtools` looks for `bash.exe` on Windows in one of its common locations as provided by Git for Windows, by taking the path given by `git --exec-path`, going up by three components, and going down to `bin/bash.exe` under that. But the `bin` and `bash.exe` components were appended in a way that used `\` directory separators. Ordinarily, that would be ideal, since `\` is the primary directory separator on Windows. However, in this case, appending with `\` produces a path that is harder to read (especially in diagostic messages), and that may cause problems if it is processed by a shell or in a way that is intended to operate similarly to shell processing of `\`. A path that does not explicitly prefer `/` but instead uses `PathBuf::push` will have `\` in front of the new components, but will still usually have `/` in front of the old components. This is because, aside from the unusual case that the `GIT_EXEC_PATH` environment vairable is set explicitly and its value uses all `\` separators, the output of `git --exec-path`, which we use to find where `git` installed on Windows, uses `/` separators. The effect of this change seems to be fairly minor, with existing test fixtures having worked before it was done. This is partly because, on Windows, the value of `argv[0]` that the shell actually sees -- and that populates `$0` when no script name is available, as happens in `bash -c '...'` with no subsequent arguments -- is translated by an MSYS DLL such as `msys-2.0.dll` (or, for Cygwin, `cygwin1.dll`) into a Unix-style path meaningful to the shell. This also refactors for clarity, and adds new tests related to the change.
This is to help support running them with a shell from the Git for
Windows SDK, which, relative to the directory where it's installed
in, provides a `usr/bin` directory with a `bash.exe` executable,
like the same-named directory in a non-SDK full installation of Git
for Windows via the installer or PortableGit or or via package
managers such as `scoop` that repackage PortableGit, but unlike
those other installations does not provide a `bin` directory.
Inside the MSYS2 "Git Bash" provided as part of the Git for
Windows SDK, there are both `/bin` and `/usr/bin` directories, but
this not related to the `bin` subdirectory of the root of the
installation. On both regular Git for Windows "Git Bash" and Git
for Windows SDK "Git Bash" environments, `/bin` in the environment
is mounted to refer to the same directory as `/usr/bin`. In both,
this is separate from `(git root)/bin` as accessed outside that
environment.
For example, in an SDK "Git Bash":
$ mount
C:/git-sdk-64 on / type ntfs (binary,noacl,auto)
C:/git-sdk-64/usr/bin on /bin type ntfs (binary,noacl,auto)
C:/Users/ek/AppData/Local/Temp on /tmp type ntfs (binary,noacl,posix=0,usertemp)
C: on /c type ntfs (binary,noacl,posix=0,user,noumount,auto)
$ cygpath -w /bin /usr/bin
C:\git-sdk-64\usr\bin
C:\git-sdk-64\usr\bin
And in a non-SDK "Git Bash":
$ mount
C:/Users/ek/AppData/Local/Temp on /tmp type ntfs (binary,noacl,posix=0,usertemp)
C:/Users/ek/scoop/apps/git/2.48.1 on / type ntfs (binary,noacl,auto)
C:/Users/ek/scoop/apps/git/2.48.1/usr/bin on /bin type ntfs (binary,noacl,auto)
C: on /c type ntfs (binary,noacl,posix=0,user,noumount,auto)
$ cygpath -w /bin /usr/bin
C:\Users\ek\scoop\apps\git\2.48.1\usr\bin
C:\Users\ek\scoop\apps\git\2.48.1\usr\bin
The former has another `bin` directory alongside the `usr` directory
on disk, containing shims for `git.exe`, `sh.exe`, and `bash.exe`,
while the latter does not, but in neither case does `/bin` inside
Git Bash refer to it. This other `bin` directory was formerly used
to find `bash.exe` to run test fixture scripts.
A possible reason to continue using `(git root)/bin` would be if
the shims modify the environment in a way that makes the fixtures
operate better.
The change in the previous commit of switching to the non-shim `bash.exe` in `(git root)/usr/bin` causes problems, because the environment may not be correct for shell commands and scripts. In particular, the `PATH` might not enable standard POSIX tools to be found, or the tools that are found may interoperate incorrectly with the shell. The latter caused failures in GitoxideLabs#1862 in an analogous choice of `sh.exe`, which were addressed by preferring the shim when available. See: - GitoxideLabs#1862 (comment) Here, 90 tests started to fail when the test suite was run locally from PowerShell (i.e. not a Git Bash environment) on a Windows 10 system that, in addition to a full Git for Windows installation, contains a separate non-GfW MSYS2 installation whose `bin` directories are in `PATH` even in non-MSYS2 environments. The failures were described, and most of them investigated, as follows: - GitoxideLabs#1864 (comment) - https://gist.github.com/EliahKagan/3c5eebd091e66d8c912fddbce0a064cd - https://gist.github.com/EliahKagan/17066ad1f7b0aa98e4fdf4642abe1d93 Most failures, including all those that were unintuitive, were directly or indirectly due to the `make_remote_repos.sh` fixture script encountering the error: fatal: bad config line 10 in file ./config This happened due to the same incorrect behavior of `>>`, when used by a shell that links to one `msys-2.0.dll` running a program that links to a different `msys-2.0.dll` of another version or build, as caused the failure encountered with the non-shim in GitoxideLabs#1862. (It may be the handful of other failures are also caused by this `>>` problem, but as of now that has not been examined.) This commit temporarily instruments that fixture script so that, when tests are run, the observations and analysis in the last gist above can be confirmed. (These changes are also shown there.)
This changes `bash_program()` so that it will find the `bash.exe` provided by Git for Windows that is most reliable for our use in runinng test fixture scripts, of those that are available. First it uses the shim, but falls back to the non-shim if the shim is not available. If neither is found, then the fallback of using the simple command `bash.exe` (which triggers a path search when run) continues to be used.
This reverts commit d290ad9.
To make it easier for users of `gix-testtools` to diagnose problems or verify that the fallback for running fixutre scripts without usable shebangs (which is effectively how any fixture shell script is run on Windows), the formerly private `bash_program()` is now public. However, it is not recommend to rely on this specific value or on observed behavior of how it is computed. The details may change at any time. The purpose of `bash_program()` and how it is used internally by `gix-testtools` is also now documented explicitly. Broad details of how it searches or guesses what path to use are likewise documented, with a caveat that changes to them are not considered breaking.
This adds a `bash-program` subcommand, abbreviated `bp`, to the `gix-testools` program (`jtt`) to check what the `bash_program()` library function gives. This is intended for diagnostic use and should probably not be used in scripting. Currently it shows the quoted debug repreesentation of the path.
EliahKagan
force-pushed
the
run-ci/bash-program
branch
from
720ae4a to
720a23f
Compare
Byron
approved these changes
Mar 20, 2025
|
Thanks--I'm glad you like it! The more substantial conceptually related PR, though technically independent of this one (I tested them both apart and together to be sure) is #1862, for |
EliahKagan
added a commit
to EliahKagan/gitoxide
that referenced
this pull request
Mar 21, 2025
One of the `justfile` recipes ran `just --fmt --unstable`, and did so as such. The problem with this is that the `just` executable in the outer `just` call is not guaranteed to be the same `just` that the inner call in the recipe finds. For example: - In general, a user might use a `just` that is not in `$PATH` even when another `just` is in `$PATH`. This would happen when testing changes to `just`, and potentially in other use cases. - The "inner" `just` is looked up by a POSIX-compatible shell that, on Windows, may have a changed environment. For example, the `sh.exe` shim provided by Git for Windows modifies environment variables including placing some directories in the front of `$PATH`. (See discussion in GitoxideLabs#1864 for details.) Thus `just` provides a built-in function `just_executable()` that can be used, and which we already use in the default recipe. This uses that function instead. However, it is not as simple as `{{ just_executable() }} --fmt --unstable`, because the path may require quoting to be run in a shell. In practice, it almost always needs to be quoted on Windows, where otherwise a `\` is being given to the shell (which the shell is required to interpret as a quoting character; this is distinct from a scenario where a path might be passed as an argument to a shell, in which case strange things may or may not occur). It might rarely need to be quoted on other systems too, it it has spaces or other even weirder contents. So this uses `{{ quote(just_executable()) }}`. It does so through the `j` variable that has already been assigned that value.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tasks:
If #1862 comes in first, rebase for clearer history (optional, should not be needed)Outscoped:
shell()or related facility inbash_program()#1886* The stakes here are low enough that I think that doesn't have to be investigated in detail. But the stakes in #1862 are higher, the shim vs. non-shim situation is similar, and we only surfaced one error case there, so I am going to examine the failures from here to become more confident in the improved solution there.
On Windows, since #1712,
gix-testtoolslooks for abashshell associated with Git for Windows, to run fixture scripts. This logic is broadly similar togix_path::env::shell()(#1758), which it influenced (#1752 (comment)). But there are some differences, even beyondshell()ingix-pathbeing forshandbash_program()ingix-testtoolsbeing forbash. Some differences are stylistic, while others are behavioral.It seems to me that they should be more similar than they are, and that there are also some improvements that should be applied to both in the same way. The changes proposed for
shell()in #1862 include some that make it more similar tobash_program(), such as checking if the shell exists, as well as others such as preferring/, which neithershell()norbash_program()yet do but which makes sense in both.This PR is the
gix-testtoolscounterpart to thegix-pathchanges in #1862. The topical similarity could justify including both in the same PR, but having separate feature branches is more flexible, and I think the effects are also independent. In addition, neither is ready, it is possible that one will be ready before the other, and I do not know which. Currently the changes in this PR are:gix_path::env::shell()./over\in building the path tobash.exe.bash.exein(git root)/usr/bininstead of the shim in(git root)/bin.All but the last of those changes are done together, while the last is in its own commit. See commit messages for more details and rationale. Some code is analogous to code proposed for
gix-pathin #1862 but less commented. More comments could be added, especially if this PR ends up being merged without #1862 being merged or looking like it would be merged soon after.All but the last of these changes also appear to be working fine on all tested systems. In contrast, using the non-shim
bash.exebreaks at least one fixture and many tests when run locally on my Windows 10 development machine from PowerShell. The failing tests are not the ones introduced here, but preexisting tests that passed before, including when run in that environment. The failures appear to be due to errors in test fixture scripts. This situation is similar to the local failures currently blocking #1862 and I suspect the cause is the same. This is what I was referring to in #1758 (comment), and I'll try to give details of the failures (as an edit or comment here) soon.I suspect that, for the
sh.exeandbash.exeprovided by Git for Windows, the shim behavior of addingbindirectories associated with Git for Windows to the front ofPATHis necessary to prevent scripts run in those shells from invoking the wrong implementations of commands, where multiple implementations are available. But I have not determined for sure that this is the case, so this PR is not ready yet.If that is the case, then a possible solution could be to prefer the shims (both here and in #1862), though if the additional subprocess invocations inherent in doing so cause a performance problem, then the existing customization of the environment in both
gix-commandandgix-testtoolscould potentially be extended. If that performance degradation is not excessive, then the ideal solution may be to prefer the shims but fall back to the non-shim versions, which would preserve compatibility with the Git for Windows SDK in scenarios where it currently works (the SDK does not have the shims, noted in #1761 (comment), as observed in #1758 (comment) and rechecked in #1758 (comment)).