find (1): как реализован подстановочный знак «звезда» для сбоя некоторых имен файлов?

В файловой системе, где имена файлов находятся в UTF-8, у меня есть файл с ошибочным именем; оно отображается как:, D�sinstallerфактическое имя в соответствии с zsh:, D$'\351'sinstallerLatin1 для Désinstaller, само по себе французское варварство для «удаления». Zsh не совпал бы с этим, [[ $file =~ '^.*$' ]]но совпал бы с глобусом *- это поведение, которое я ожидаю.

Теперь я все еще ожидаю найти его во время работы find . -name '*'- на самом деле, я бы никогда не ожидал, что имя файла не пройдет этот тест. Тем не менее, с LANG=en_US.utf8, файл не отображается, и я должен установить LANG=C(или en_US, или '') для его работы.

Вопрос: Что такое реализация и как я мог предсказать этот результат?

_{Информация: Arch Linux 3.14.37-1-lts, find (GNU findutils) 4.4.2}

Это действительно хороший улов. Из быстрого взгляда на исходный код для поиска GNU я бы сказал, что это сводится к тому, как fnmatchведет себя недопустимые последовательности байтов ( pred_name_commonin pred.c):

b = fnmatch (str, base, flags) == 0;
(...)
return b;

Этот код проверяет возвращаемое значение fnmatchна равенство с 0, но не проверяет наличие ошибок; это приводит к тому, что о любых ошибках сообщают как "не совпадает".

Много лет назад было предложено изменить поведение этой функции libc, чтобы она всегда возвращала истину в *шаблоне, даже для неработающих имен файлов, но из того, что я могу сказать, идея должна быть отклонена (см. Поток, начинающийся с https. : //sourceware.org/ml/libc-hacker/2002-11/msg00071.html ):

Когда fnmatch обнаруживает недопустимый многобайтовый символ, он должен вернуться к однобайтовому сопоставлению, чтобы у «*» была возможность сопоставить такую ​​строку.

И почему это лучше или правильнее? Есть ли существующая практика?

Как упомянул Стефан Шазелас в комментарии, а также в том же потоке 2002 года, это не согласуется с расширением глобуса, выполняемым оболочками, которые не блокируют недопустимые символы. Возможно, еще более загадочным является тот факт, что при реверсе теста будут сопоставляться только те файлы, которые имеют сломанные имена (создайте файлы в bash с помощью touch $'D\351marrer' $'Touch\303\251' $'\346\227\245\346\234\254\350\252\236'):

$ find -name '*'
.
./Touché
./日本語

$ find -not -name '*'
./D?marrer

Итак, чтобы ответить на ваш вопрос, вы могли бы предсказать это, зная поведение вашего fnmatchв этом случае и зная, как findобрабатывает возвращаемое значение этой функции; Вы, вероятно, не могли бы узнать только прочитав документацию.

-nameОпция find использует нотацию сопоставления с образцом оболочки для сопоставления имени файла. *шаблон, соответствующий нескольким символам , должен соответствовать строке из нуля или более символов.

findиспользует fnmatch для проверки соответствия шаблону, поэтому вы можете использовать ltrace для проверки результата:

$ touch $'\U1212'aa
$ touch D$'\351'sinstaller
$ LC_ALL=en_US.utf8 ltrace -e fnmatch find -name '*'          
find->fnmatch("foo", "foo", 0)                   = 0
find->fnmatch("Foo", "foo", 0)                   = 1
find->fnmatch("Foo", "foo", 16)                  = 0
find->fnmatch("*", ".", 0)                       = 0
.
find->fnmatch("*", "D\351sinstaller", 0)         = -1
find->fnmatch("*", "\341\210\222aa", 0)          = 0
./ሒaa
+++ exited (status 0) +++

С D\351sinstaller, fnmatchвозвращение -1, указала , что она не соответствовала. Действительный символ как ሒaaбудет сопоставлен.

В вашем случае, с UTF-8локалью, \351это недопустимый символ, приводящий к сбою сопоставления с шаблоном.