Re: xfstests can't be installed by running make install

[Florian Weimer]

* Eryu Guan:

> This problem here doesn't seem the same as the bug above, Fedora 28 has
> glibc-2.27, which contains the fix for above bug, and the bug is about
> trailing "/". But the problem here is we're asking for all lower case
> filenames but wildcard returns upper case names too. e.g.
>
> address@hidden tmp]# pwd
> /root/tmp
> address@hidden tmp]# ls -l
> total 4
> -rw-r--r--. 1 root root   0 Jul 17 10:51 aaa
> -rw-r--r--. 1 root root   0 Jul 17 10:51 AAA
> -rw-r--r--. 1 root root 273 Jul 17 10:50 Makefile
> drwxr-xr-x. 1 root root   0 Jul 15 14:59 testdir
> address@hidden tmp]# cat Makefile
> STRING1 = $(wildcard $(CURDIR)/[a-z]*/)
> STRING2 = $(wildcard ./[a-z]*/)
> STRING3 = $(wildcard $(CURDIR)/[a-z]*/.)
> STRING4 = $(wildcard $(CURDIR)/[a-z]*)
> default:
>         @echo STRING1="$(STRING1)"
>         @echo STRING2="$(STRING2)"
>         @echo STRING3="$(STRING3)"
>         @echo STRING4="$(STRING4)"
> address@hidden tmp]# make
> STRING1=/root/tmp/aaa /root/tmp/AAA /root/tmp/testdir/ /root/tmp/Makefile
> STRING2=./aaa ./AAA ./testdir/ ./Makefile
> STRING3=/root/tmp/testdir/.
> STRING4=/root/tmp/aaa /root/tmp/AAA /root/tmp/testdir /root/tmp/Makefile
> address@hidden tmp]#
>
> STRING4 is asking for all lower file names, but both "AAA" and
> "Makefile" are returned.

This is related to this glibc bug:

  https://sourceware.org/bugzilla/show_bug.cgi?id=23393

The bug mentions the regular expression [0-9], but it also affects
patterns like [a-z].  I have not yet looked at fnmatch and glob in
detail, but based on the report here (and a quick test with “echo
[a-z]*”), they are affected by the same issue.

This is ultimately caused by a locale data update which was backported
into Fedora 28 (glibc 2.27) and its derivatives.  Upstream glibc only
has this change for version 2.28 (not yet released).  It's currently
not considered a release blocker, if it's even considered a bug at
all.

I dimly recall earlier discussions regarding this matter quite some
time ago, perhaps in the POSIX context.  GNU grep appears to have a
workaround for [0-9], but not [a-z].  Cc:ing Jim Meyering in case he
has any insights.