Hi, On Sat, 13 Jan 2024, Matthias Aßhauer wrote: > On Sat, 13 Jan 2024, Torsten Bögershausen wrote: > > > On Sat, Jan 13, 2024 at 02:56:27AM +0000, Michael Litwak wrote: > > > I just installed Git for Windows 2.43.0 and noticed the installer offers > > > three options for altering the PATH: > > > > > > 1) Run git from git bash only > > > > > > 2) Run git from git bash, cmd.exe and PowerShell (RECOMMENDED) > > > > > > 3) Run git from git bash, cmd.exe and PowerShell with optional utilities > > > (warning: will override find, sort and other system utilities). > > > > > > It turns out iconv.exe is accessible from cmd.exe (Command Prompt) only > > > when you take the third option. But iconv.exe is NOT optional. It is > > > required for git to deal with UTF-16LE with BOM text conversions (and > > > probably for numerous other encoding conversions). > > For end users directly calling iconv.exe is definitely optional. > > > Plese wait a second - and thanks for bringing this up. > > To my knowledge the binary iconv.exe (or just iconv under non-Windows) > > is never called from Git itself. > > Git is using iconv_open() and friends, which are all inside > > a library, either the C-library "libc", or "libiconv" > > (not 100% sure about the naming here) > > Exactly. I can't find a single instance of Git for Windows calling iconv.exe > instead of using the corresponding library functions. [1] > > And even if it did, iconv.exe is definitely on the path for git.exe [2] unless > you're calling /(mingw|clangarm)(64|32)/bin/git.exe directly, in which case > the solution is to call /cmd/git.exe instead. Just a quick addition to this: _even if_ you happen to call `/*[63][42]/bin/git.exe` directly, the `PATH` is adjusted (unless `MSYSTEM` is set, which would indicate a pilot error without the corresponding `PATH` components such as `/usr/bin`): https://github.com/git-for-windows/git/blob/v2.43.0.windows.1/compat/mingw.c#L3529 Ciao, Johannes > [1] > https://github.com/search?q=repo%3Agit-for-windows%2Fgit%20iconv%20NOT%20path%3A%2F%5Et%5C%2F%2F%20NOT%20path%3A%2F%5EDocumentation%5C%2F%2F&type=code > [2] > https://github.com/git-for-windows/MINGW-packages/blob/0c91cf2079184ae6a604e8f7a406a47d39305e72/mingw-w64-git/git-wrapper.c#L166-L258 > > > iconv.exe is not needed in everyday life, or is it ? > > If yes, when ? > > iconv.exe is used when you run the test-suite, to verify > > what Git is doing. > > > > Could you elaborate a little bit more, > > when iconv.exe is missing, and what is happening, please ? > > > > > > > > But when PATH option #2 is chosen, and iconv.exe is unreachable from a > > > Windows Command Prompt, the git commands which call upon iconv.exe do NOT > > > indicate the error. The call to iconv.exe fails silently. It is only > > > later after you commit, push and clone the repo again that you see the > > > encoding failures. > > > > > > And the warning about overriding find and sort must be taken with a grain > > > of salt, since the Windows versions of those programs are accessed via a > > > Windows folder which appears earlier in the PATH. > > We should probably consider rewording that warning. > > > > So this Git for Windows installer screen is misleading. And perhaps > > > iconv.exe should be relocated so it is accessible even when PATH option #2 > > > is chosen. I intend to submit an issue on the Git for Windows issue > > > tracker regarding this. I'll also submit an issue about the lack of an > > > error when running 'git add' for a UTF-16LE with BOM file under PATH > > > option #2. > > > > > > Thanks, > > > - Michael > > > > > [] > > > >
