e987df5fe6 (list-objects-filter: implement composite filters, 2019-06-27) introduced a test to "t6112-rev-list-filters-objects.sh" that checks the output of a Git command with the following commands:

  grep ~$omitted_1 actual &&
  grep ~$omitted_2 actual &&
  grep ~$omitted_3 actual &&

Since the leading tilde in the pattern is not quoted/escaped, it is subject to tilde expansion. So if the system has a user whose username happens to be equal to the content of one of those "$omitted_*" variables, then "grep" would look for the user's home directory. Luckily, those variables contain object hashes, so this is not very likely.

Furthermore, Bash versions v5.0 and earlier seem to be buggy and don't handle this particular tilde expansion very well, and either segfault right away or, in case of v3.2, get stuck in an endless loop and segfault upon receiving ctrl-c.

Quote those words starting with a tilde to avoid these issues.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
 t/t6112-rev-list-filters-objects.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

On Sat, Apr 18, 2026 at 9:33 AM SZEDER Gábor <szeder.dev@gmail.com> wrote:

Interesting find on the bash segfault behavior.

Looks good to me. I wasn't able to find any other unquoted ~$ uses in the testsuite except mid-word (e.g. HEAD~$i), though I suspect your version of bash seg-faulting is a better check than my grep-fu anyway.

On Sat, Apr 18, 2026 at 06:26:00PM -0700, Elijah Newren wrote:

On second thought, tilde expansion should happen before parameter/variable expansion, so the above is wrong: we are looking for a user named "$omitted_1" and not a user named like whatever object hash the "$omitted_1" variable holds.

Still unlikely, but we should still avoid it.

Actually, I'm going to take back that statement about the Bash segfault.

I tested older Bash versions with binaries that I compiled myself from the sources at git://git.savannah.gnu.org/bash.git, and those exhibited the segfault in v5.0 and below. Bisect shows that v5.1 is not just the first release but the first commit that doesn't segfault on t6112.

However.

Bash v5.1 was released on 2020-12-06, about a year and a half after those unintended tilde expansions were added. I find it hard to believe that noone stumbled upon this issue during that time... Suspicious, I booted my old laptop running an outdated Debian derivative with distro shipped Bash 5.0.17, and, lo and behold, t6112 passed just fine.

So I'm inclined to think that something is wrong here... No idea what, though. I can reproduce the segfault with something as simple as "./bash-v5.0 -c 'v=~a'", and the segfault doesn't even come from Bash but from within getpwnam() called during tilde expansion. Oh, well.

Will send a patch with updated log message some time later.

e987df5fe6 (list-objects-filter: implement composite filters, 2019-06-27) introduced a test to "t6112-rev-list-filters-objects.sh" that checks the output of a Git command with the following commands:

  grep ~$omitted_1 actual &&
  grep ~$omitted_2 actual &&
  grep ~$omitted_3 actual &&

Since the leading tilde in the pattern is not quoted/escaped, it is subject to tilde expansion. So if the system has a user whose username happens to be "$omitted_1", then "grep" would look for that user's home directory.

Quote those words starting with a tilde to avoid this.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
Same diff, updated commit message.

 t/t6112-rev-list-filters-objects.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)