[BUG] Extremely slow bash script

[Erik Cervin Edin]

Dear Git-for-Windows community,

I'm running into a very annoying performance issue with one of my bash
scripts. I have a simple search and replace script that runs very slow
when invoked using git search-replace.sh (not git-search-replace.sh)
_and_ with an argument that contains a network path.

This specific script isn't really relevant, the issue can be reproduced using

```git-slow.sh
#!/bin/bash
echo "$1"
```

This usually runs without problem, except in the odd situation that
it's invoked via git, with a shell quoted variable that contains a
network path
For example
git slow.sh a
git slow.sh '\\8.8.8.8\foo\bar\'
a='\\8.8.8.8\foo\bar'
git-slow.sh "$a"
all run fine, but if run something like
a='\\8.8.8.8\foo\bar'
git slow.sh "$a"
it can take _minutes_ (!?).

Now, I suspect this is because something (I'm guessing MINGW) is doing
some sort of look-up on those network addresses (I'd prefer it did
not) and it takes a very long time to do so.

Notably, as I mentioned earlier invoking the script
git-slow.sh "$a"
ie. directly, is fine.

GIT_TRACE=1 output isn't giving much insight
12:45:46.481666 exec-cmd.c:237 trace: resolved executable
dir: C:/Users/erik/Git/mingw64/bin
12:45:46.483664 git.c:750 trace: exec: git-slow.sh
'\\8.8.8.8\foo\bar'
12:45:46.483664 run-command.c:655 trace: run_command:
git-slow.sh '\\8.8.8.8\foo\bar'
\\8.8.8.8\foo\bar

I'm guessing it's a MINGW issue, specifically some kind of variable
expansion hoopla, because if I type
echo $a<TAB>
I experience a very similar issue.

All in all, a very odd issue. Any ideas?

Seen on
git version 2.38.1.windows.1

--
Erik Cervin-Edin

[Erik Cervin Edin]

On Fri, Oct 21, 2022 at 12:54 PM Erik Cervin Edin <er...@cervined.in> wrote:
>
> Now, I suspect this is because something (I'm guessing MINGW) is doing
> some sort of look-up on those network addresses (I'd prefer it did
> not) and it takes a very long time to do so.

Yep, can confirm that if I run

a='\\8.8.8.8\foo\bar'
git slow.sh "$a"

then sure enough, System starts making network requests to 8.8.8.8. This
behavior seems highly undesirable

[Johannes Sixt]

Am 21.10.22 um 13:26 schrieb Erik Cervin Edin:

Sounds like your system is in a domain, but the domain controller is
unavailable. I use this solution for the problem:

https://stackoverflow.com/questions/72436188/git-branch-command-is-slow-from-git-bash-on-windows/72464271#72464271

It basically hard-codes some names and groups in /etc/passwd and
/etc/group. I do not know whether this is a feasible solution when you
update Git using the Git-for-Windows installer (I do not use it at all).

-- Hannes

[Erik Cervin Edin]

On Fri, Oct 21, 2022, 6:40 PM Johannes Sixt <j...@kdbg.org> wrote:

Am 21.10.22 um 13:26 schrieb Erik Cervin Edin:
> On Fri, Oct 21, 2022 at 12:54 PM Erik Cervin Edin <er...@cervined.in> wrote:
>>
>> Now, I suspect this is because something (I'm guessing MINGW) is doing
>> some sort of look-up on those network addresses (I'd prefer it did
>> not) and it takes a very long time to do so.
>
> Yep, can confirm that if I run
>   a='\\8.8.8.8\foo\bar'
>   git slow.sh "$a"
> then sure enough, System starts making network requests to 8.8.8.8. This
> behavior seems highly undesirable
>

Sounds like your system is in a domain, but the domain controller is
unavailable. I use this solution for the problem:

Thank you for the input! I'm not terribly familiar with domains and domain controllers on Windows. Running

  gpresult -z | grep Domain

it appears the Domain is the computer itself, which sounds about right. I presume that would also mean the domain controller is available

https://stackoverflow.com/questions/72436188/git-branch-command-is-slow-from-git-bash-on-windows/72464271

I'm not sure this issue is the same but it's possibly related. However, my problem only occurs in the situation described above

  git script args

as opposed to

  git-script args

and only if the args contain a network path. This is at least the only issue I've perceived. However the symptoms seem correlated enough to make it worthwhile to explore.

I did try

  mkpasswd >> /etc/passwd
  mkgroup >> /etc/group

but it didn't make a difference.

Hannes you (I presume) in the post on Stackoverflow also mention removing duplicates. Not sure what that means in this situation and if this solution involves something more than what I tried.

[Erik Cervin Edin]

I'm still struggling to understand why invoking the script the way
that I do would in any way entail lookups on the network. I'm just
passing a string, containing a network address, verbatim to a script
and assigning it verbatim to a variable.

However, some of what I reported earlier turned out to be incorrect or
inaccurate

On Fri, Oct 21, 2022 at 12:54 PM Erik Cervin Edin <er...@cervined.in> wrote:
>

> This specific script isn't really relevant, the issue can be reproduced using
>
> ```git-slow.sh
> #!/bin/bash
> echo "$1"
> ```

Most importantly, this was incorrect. The issue only presents itself
when the shebang is #!/bin/sh and _not_ #!/bin/bash
Ie, it should say

> ```git-slow.sh
> #!/bin/sh
> echo "$1"
> ```

Another thing that turned out to be incorrect was

> This usually runs without problem, except in the odd situation that
> it's invoked via git, with a shell quoted variable that contains a
> network path
> For example
> git slow.sh a
> git slow.sh '\\8.8.8.8\foo\bar\'
> a='\\8.8.8.8\foo\bar'
> git-slow.sh "$a"
> all run fine

Specifically

> git slow.sh '\\8.8.8.8\foo\bar\'

turned out to also be affected but it appears the lookup that occurs
is cached. Ie. running
git slow.sh '\\8.8.8.8\'
will be slow the first time around but subsequent invocations will run
a lot faster, for a while, presumably until the lookup is no longer
cached.

Another noteworthy addendum to the issue is that invoking
git slow.sh '\\123\'
in cmd does _not_ result in the same issue.

All of this points to some sort of issue in the interplay of bash, git
and sh (whichI believe is bash running in POSIX mode?)

Since changing the shebang resolved my issue, I will opt for this solution.