getent is getting called when git-bash is run, which causes an error if Cygwin is installed

[MartyMacGyver]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Error is seen in Git-2.12 on forward. Worked in Git-2.11.1-64-bit

$ git --version --build-options

git version 2.13.1.windows.2
built from commit: a36e14b3aaa0ddb633c40a9c8483e6fe12d99616
sizeof-long: 4
machine: x86_64

• Windows 7 Ultimate, x64

$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601]

• I believe they were all defaults, particularly git-for-windows is not in my path

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Path Option: BashOnly
Plink Path: C:\Program Files\TortoiseGit\bin\TortoisePlink.exe
SSH Option: Plink
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: ConHost
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

I have Cygwin 64-bit installed - it's in the path too (near the end).

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

git-bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

Click on git-bash

• What did you expect to occur after running these commands?
  Just a git-bash command prompt

• What actually happened instead?

     1 [main] getent (14752) C:\cygwin\bin\getent.exe: *** fatal error - cygheap base mismatch detected - 0x1802FF408/0x180304408.
  

  This problem is probably due to using incompatible versions of the cygwin DLL.
  Search for cygwin1.dll using the Windows Start->Find/Search facility
  and delete all but the most recent version. The most recent version should
  reside in x:\cygwin\bin, where 'x' is the drive on which you have
  installed the cygwin distribution. Rebooting is also suggested if you
  are unable to find another cygwin DLL.

(then I get the command prompt)

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

n/a

[MartyMacGyver]

I've been getting the error above in recent git-for-windows x64 releases. My Cygwin install is also x64. I did the usual "DLL base address" dance, but that didn't help. I reinstalled (with the concomitant reboots), and made sure it should only work when the git-bash link is used (git for windows isn't anywhere in my path). Still, this error persists.

I updated Cygwin - has the very latest DLL. Not sure why git is using a cygwin DLL from over a year ago but ok, still should've been a problem in Git-2.11.1-64-bit.

But if I remove Cygwin from my path, it works. Which is nice but unacceptable - and besides, git-bash should put itself first in the path to prefer its own command set, thus never seeing Cygwin. Which is what it appears to be doing, except this getent thing.

So I opened a cmd shell, removed Cygwin from the path, and started git-bash from that (as it inherits the shell environment that way). No more getent error! And I can see cygwin is nowhere in its path now...

$ getent
bash: getent: command not found

But wait - if getent is nowhere to be found if Cygwin is absent, and git-bash is happy even if it cannot find it... why is git-bash trying to run getent at all? If you try to run things within git-bash that are coming from Cygwin only then sure, that may cause problems, but git-bash itself shouldn't be dependent on unix-like things that git-for-windows never installed in the first place.

I am starting to think that this getent thing is a relatively recent change since Git-2.11.1-64-bit - either it used to be installed and now it's not, or git-bash is depending on it inappropriately in a way it didn't before.

[MartyMacGyver]

Update: the exact commit in the SDK where this problem starts appears to be git-for-windows/git-sdk-64@abcb646, wherin this getent change appears to have been introduced in /etc/bash.bashrc:

if [[ -n "$(command -v getent)" ]] && id -G | grep -q "$(getent -w group 'S-1-16-12288' | cut -d: -f2)"

getent itself is nowhere to be found, and the context is unclear so I'm not sure under what conditions this change is supposed to have an effect. @dscho made the merge and may have more insight on why the change was made.

Note: if I manually remove that if [[ -n "$(command -v getent)" ]]... fi block of code from etc/bash.bashrc the problem disappears.

[MartyMacGyver]

One more bit of into: the system cygwin1.dll and git's msys-2.0.dll are a little different in size but have the same version number (2008.0.0.0), virtual size (0x005c0000), and preferred base address (0x0000000180040000). While they are clearly not compatible with each other, they aren't very different either. Nonetheless, if you're in git-bash, you cannot run Cygwin commands - including getent.

There's no way I've found to trim a path before running a shell, and taking Cygwin out of the path for the sake of this spurious call isn't a good option either. I can hack out the code in bash.bashrc (it's not clear why it's there and what benefit it would normally offer), but that's still just a hack.

If getent has a purpose here, then it should be included from MSYS2. This seems to me to be the only proper fix, which both avoids trouble like I've seen and actually makes getent work as it's clearly meant to be doing something besides either erroring out or never being found.

[MartyMacGyver]

Now that I know what to look for, it seems this getent change originally came from msys2/MSYS2-packages@ae10fd8

And for all that it's a bit superfluous... it simply detects if bash is being run as Administrator, and updates the prompt to signify that. Which is great if MSYS2's getent exists and is present, and is not so good if it finds it somewhere else in the path.

[landstander668]

It sounds like the simplest solution is to add getent to the GfW installation. @dscho, I'll take a look at this tonight and see if I can get PR in order within the next few days... should be pretty similar to the ssh-pageant integration from issue #683.

[landstander668]

I've opened a preliminary PR which adds getent to the Git for Windows build. The not insignificant downside, however, is that it increased the size of the 64-bit installer by approximately 20% (adding roughly 10 MB). So I'm not currently sure if this is a viable approach, compared to removing the getent calls from /etc/bash.bashrc. Hoping for input from @dscho on this question.

[MartyMacGyver]

Though it's a drop in the bucket in terms of package sizes on Windows, I'm surprised that it adds 10 MB - what all's it adding besides getent? Or is it bloating because of static linking in MSYS2 versus Cygwin (which shows getent as... 19KB)?

You could remove the getent calls, but you'll end up carrying that modified bash.bashrc forward indefinitely.

[elieux]

The getent package and its dependency libargp are ~100 KiB in total.

[landstander668]

Yeah, on further examination I don't think there's any way the addition of the getent package can explain the observed size increase (which was considerably worse in the case of the portable installer) by itself. I'm thinking I might have generated a build with additional debugging options, without realizing it.

I'll be unavailable for the remainder of today and tomorrow, but I'll take another look on Sunday and try to figure out what's going on.

[landstander668]

dscho has expressed a preference to remove the getent calls from /etc/bash.bashrc rather than adding the package, so I've updated the PR accordingly.

[dscho]

Closed via PR git-for-windows/build-extra#146

[MartyMacGyver]

Thanks for getting this resolved - looking forward to seeing the fix in a future build!