find и буквы с диакритическими знаками

touch "фигня"
find . -iname "шняга"

Странно, действительно ничего не находит…

Не подойдёт, так как бывают неочевидные случаи.

Например, я не смог найти нужный файл из-за того что кто-то букву «й» написал как «и» с диакритическим знаком «˘».

Anon, делом займись, шутник.

А анон, тем временем, указывает на бревно в твоём глазу, которое ты старательно не видишь.

Unicode::Collate в перле, очевидно. Сейчас в линуксе ровно в двух местах есть поддержка юникода: перл (по дефолту выключено) и icu, всё остальное, включая bash, ФС, coreutils и ~100% софта юникод не умеет.

http://perldoc.perl.org/Unicode/Collate.html#Methods-for-Searching доказательство того, что перл умеет юникод, а местные клоуны — нет.

перл умеет юникод, а местные клоуны — нет

Тебе череп не жмет? Я выше написал как iconv-ом избавиться от диакритических знаков

бывают неочевидные случаи

Исправляй.

Сейчас в линуксе ровно в двух местах есть поддержка юникода: перл (по дефолту выключено) и icu

Да я бы сказал, что и в perl он через одно место внедряется ( perl использую постоянно ) Вроде бы в других языках с этим получше.

Ничего, что в cp1251 исходный текст даже за вырезанием диакритики не влезает? Ничего, что это локалезависимо? А, да, мы же не умеем юникод и называем кириллицу в utf-8 «поддержкой юникода».

Ну и твоё решение не работает с декомпозицией того же й. Потому, что в нём даже отдалённо не пахнет нормализацией юникода. Потому, что ты тупо надеешься, что регэкспы для транслита тебя спасут.

http://stackoverflow.com/questions/6162484/why-does-modern-perl-avoid-utf-8-b... не так сложно. Во многих других языках дефолтные строки не до такой степени юникодные. Без ICU питон/руби, например, не совсем юникодны. python, емнип, ещё и с ucs-2 строками по дефолту. utf-16 с некоторыми ручными манипуляциями в java, tcl, но там тот же collate не изкоробочный (как и в перле). Тут сама проблема не самая простая, да и уровней поддержки полно, на многих задачах полная поддержка юникода не требуется.

Зачем это словоблудие? Если ты знаешь как правильно делать - напиши или дай ссылку на правильный юникодный find. Если просто хочется рассказать как все плохо - ну, это тоже очень интересно. Очень. Продолжай, пожалуйста

Эмм. Написание юникодного финда на перле не представляет никакой сложности. Он будет заметно медленнее обычного, конечно. Но задача решена.

А анон, тем временем, указывает на бревно в твоём глазу, которое ты старательно не видишь.

А Windows, тем временем, пока вы тут выделываетесь, прекрасно находит слова с диакритическими знаками.

Изумительно. Как мне сделать поиск по найденным файлам? Или ещё лучше - как это засунуть в скрипт?

Поэтому я и использую find в cygwin. Но, как оказалось, в нём сабжевая проблемка.

P.S. Хотя можно использовать вот этот костыль http://www.structurise.com/kleptomania/
для распознавания текста с экрана (вот скриншот этой чудо-программы) :)

А Windows, тем временем,

окей, зачем ты тут тогда ;)

gci -r|% { $_.Name.Normalize() -like "паттерн"}

Можно указать форму нормализации, если хочется ([SystemString]«FormKC» например). Внутри файлов искать тоже не проблема.

И да, /r/ подсветку powershell в [code], кстати.

уда́рение

Ты такой файл и не найдёшь, потому что ударе́ние, не?

└► find music/ -mindepth 1 -name Motörhead -type d ; echo ; find --version 
music/Motörhead

find (GNU findutils) 4.5.11
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Eric B. Decker, James Youngman, and Kevin Dalley.
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION SELINUX FTS(FTS_CWDFD) CBO(level=2) 

УМВР

Ты ищи Motorhead, а не Motörhead.

Хотя я брежу, нужно делать indexof от compareinfo с опцией ignoresymbols (и ignorecase по желанию). Но это не делает задачу менее решаемой.

Ты ищи Motorhead, а не Motörhead.

Не найду ничего. А должен? До сего момента думал, что ö != o точно так же, как, к примеру, «o латинское строчное» != «O латинское заглавное».

А как сделать, если хочется найти? unicode collation алгоритм, в конце концов, не просто так придумали.

И да, полное решение у конкурентов:

gci -r|% {$result = [System.Globalization.CompareInfo]::GetCompareInfo("en-us").IndexOf($_.name.normalize(),"фай
л",[system.globalization.compareoptions]"IgnoreNonSpace");if ($result -ne "-1") { write-host $_.name } }

Лаконично, не правда ли? Можно оформить функцией.

УМВР

Потому-что кто-то путает отдельные символы с символами модифицированными. В юникоде по стандарту они равноценны. А вот в тупых библиотеках, не понимающих юникод, это не учитывается.

Не найду ничего. А должен?

А, так всё даже настолько плохо? Да, должен. Это всё равно что Ё/Е при поиске считать одной буквой. Или «ß» == «ss» у немцев. Посмотри, как любой приличный поиск работает.

OK, убедили.