GitoxideLabs/gitoxide gix-path-v0.10.15

gix-path v0.10.15

on GitHub

Bug Fixes

• Check prefix and prefer shim in gix_path::env::shell()
  This makes a few changes to make shell() more robust:

  1. Check the last two components of the path git --exec-path
     gave, to make sure they are libexec/git-core.

  (The check is done in such a way that the separator may be /
  or \, though a \ separator here would be unexpected. We
  permit it because it may plausibly be present due to an
  overriden GIT_EXEC_PATH that breaks with Git's own behavior of
  using / but that is otherwise fully usable.)

  If the directory is not named git-core, or it is a top-level
  directory (no parent), or its parent is not named libexec,
  then it is not reasonable to guess that this is in a directory
  where it would be safe to use sh.exe in the expected relative
  location. (Even if safe, such a layout does not suggest that a
  sh.exe found in it would be better choice than the fallback of
  just doing a PATH search.)

1. Check the grandparent component (that ../.. would go to) of
   the path git --exec-path gave, to make sure it is recognized
   name of a platform-specific usr-like directory that has been
   used in MSYS2.

   This is to avoid traversing up out of less common directory
   trees that have some different and shallower structure than
   found in a typical Git for Windows or MSYS2 installation.

2. Instead of using only the (git root)/usr/bin/sh.exe non-shim,
   prefer the (git root)/bin/sh.exe shim. If that is not found,
   fall back to the (git root)/usr/bin/sh.exe non-shim, mainly to
   support the Git for Windows SDK, which doesn't have the shim.

   The reason to prefer the shim is that it sets environment
   variables, including prepending bin directories that provide
   tools one would expect to have when using it. Without this,
   common POSIX commands may be unavailable, or different and
   incompatible implementations of them may be found.

   In particular, if they are found in a different MSYS2
   installation whose msys-2.0.dll is of a different version or
   otherwise a different build, then calling them directly may
   produce strange behavior. See:

   • https://cygwin.com/faq.html#faq.using.multiple-copies
   • #1862 (comment)

   This makes things more robust overall than either preferring the
   non-shim or just doing a path search for sh as was done before
   that. But it exacerbates #1868 (as described there), so if the
   Git for Windows sh.exe shim continues to work as it currently
   does, then further improvements may be called for here.

• #1862 (comment)

1. Adding components with / separators. While in principle a \
   should work, the path of the shell itself is used in shell
   scripts (script files and sh -c operands) that may not account
   for the presence of backslashes, and it is also harder to read
   paths with \ in contexts where it appears escaped, which may
   include various messages from Rust code and shell scripts.

   The path before what we add will already use / and never \,
   unless GIT_EXEC_PATH has been set to a strange value, because
   it is based on git --exec-path, which by default gives a path
   with / separators. Thus, ensuring that the part we add uses /
   should be sufficient to get a path without \ in all cases when
   it is clearly reasonable to do so. This therefore also usually
   increases stylistic consistency of the path, which is another
   factor that makes it more user-friendly in messages.

   This is needed to get tests to pass since changing gix-command
   to use gix_path::env::shell() on Windows, where a path is
   formatted in away that sometimes quotes \ characters. Their
   expectations could be adjusted, but it seems likely that various
   other software, much of which may otherwise be working, has
   similar expectations. Using / instead of \ works whether \
   is expected to be displayed quoted or not.

2. Check that the path to the shell plausibly has a shell there,
   only using it if it a file or a non-broken file symlink. When
   this is not the case, the fallback short name is used instead.

3. The fallback short name is changed from sh to sh.exe, since
   the .exe suffix is appended in other short names on Windows,
   such as git.exe, as well as being part of the filename
   component of the path we build for the shell when using the
   implementation provided as part of Git for Windows.

Other

• Fix to_windows_separators docstring, revise others
  The gix_path::convert::to_windows_separators documentation
  comment had inadvertently described the opposite of what this
  function does, saying it changed backslashed to slashes and that
  the effect was like a Unix path. This fixes the docstring so it
  saye to_windows_separators changes slashes to backslashes, and
  moves the text that likens it to paths on Unix to the
  to_unix_separators docstring, where it applies.

  This also makes a number of other more minor revisions for
  clarity and stylistic consistency to documentation comments on
  other functions in the gix_path::convert module.

Commit Statistics

• 25 commits contributed to the release.
• 3 commits were understood as conventional.
• 0 issues like '(#ID)' were seen in commit messages

Thanks Clippy

Clippy helped 1 time to make code idiomatic.

Commit Details