forum.opennet.ru - "Выпуск утилиты GNU grep 3.4" (84)

"Выпуск утилиты GNU grep 3.4"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Выпуск утилиты GNU grep 3.4"	+/–
Сообщение от opennews (?), 03-Янв-20, 10:05
Представлен выпуск утилиты для организации поиска данных в текстовых файлах - GNU Grep 3.4. В новой версии добавлена опция "--no-ignore-case", отключающая действие настроек отмены учёта регистра символов (-i, --ignore-case). Исключено попадание под маску "." некорректных последовательностей UTF-8. При выполнении "grep -Fw" решены проблемы с ложным сопоставлением данных в многобайтовых локалях, отличных от UTF-8. Устранены провалы в производительности при обработке большого числа шаблонов без обратных ссылок, а также шаблонов вида '01.2', приводящих к выполнению внутренней пересортировки токенов... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52128
Ответить \| Правка \| Cообщить модератору

Оглавление

Не нужно ripgrep в 3 5 быстрее , BSD_Cucks_BTFO (?), 10:05 , 03-Янв-20, (1) –8

А нам некуда спешить тише едешь -- дальше будешь А то грепают тута аки самолёт, A.Stahl (ok), 10:13 , 03-Янв-20, (2) +10

иногда надо по-быстрому в многометровом логе найти нужное событие , qqq (??), 14:39 , 03-Янв-20, (19) –1

многогиговом, 12345 (??), 14:56 , 03-Янв-20, (22)

Такие логи есть смысл сваливать в более специальные системы с индексированием, е, Michael Shigorin (ok), 19:50 , 03-Янв-20, (50) +2

Имхо, пока ничего лучше sawmill не придумали для этой задачи, но даже sawmill, IdeaFix (ok), 20:52 , 03-Янв-20, (55) –1

Главное настроить систему логирования на системе логирования, что бы когда она б, GentooBoy (ok), 00:32 , 04-Янв-20, (72) +1
дороговато для грепа, Anonymouss (?), 00:55 , 04-Янв-20, (75)

Тогда греп надо на электрон переписать , Аноним (20), 14:49 , 03-Янв-20, (20) +5

не успеюют - быстрее сделают grepd, супернуб (?), 09:22 , 06-Янв-20, (87)

Да, rg и fd - должны быть на каждой системе Fd кстати сделан поверх либы walkdi, Wilem (?), 12:08 , 03-Янв-20, (7) +1
riggrep написан на rust, не учитывает особенности unicode u ss - 223 и не п, bircoph (ok), 14:08 , 03-Янв-20, (12) +5

Объясни по-подробнее про особенности utf8, что не так , Wilem (?), 14:25 , 03-Янв-20, (16) –1

Я не знаю, что он имел в виду, но венда тоже не умеет в utf8 По-моему я даже в , Аноним (21), 14:51 , 03-Янв-20, (21)

https snipboard io 5E9mRX jpg, Wilem (?), 15:02 , 03-Янв-20, (23) –1

Там свой особенный утф8, мало общего имеющий со стандартом Дело не в том, что о, Аноним (21), 15:28 , 03-Янв-20, (25) –1

А что за символы с которыми крешится или которые несовместимы Прям сейчас бы оп, Wilem (?), 15:45 , 03-Янв-20, (28) –1

Я не помню, какие именно, но даже в википедии емнип было написано в японской 1, Аноним (21), 16:00 , 03-Янв-20, (30)

UTF-8 не нужен при наличии полноценного юникода Квест угадай сколько байтов по, Аноним (67), 22:33 , 03-Янв-20, (67) –3

Полноценный - это какой UTF-32 Ну да, там есть небольшой запас, чтобы на это з, Аноним (21), 22:57 , 03-Янв-20, (69)

В винде вроде двухбайтовый UCS2 фигурировал PS полноценный , ага , Michael Shigorin (ok), 23:09 , 03-Янв-20, (70)
В UTF-8 в теории символ может до 6 байт весить, это сильно лучше или как , Аноним (83), 23:08 , 04-Янв-20, (83)

Очень в теории, текущий лимит 4 байта из соображений совместимости И всяко лучш, Аноним (21), 23:23 , 04-Янв-20, (84)

Угу, то ли дело греп, на который еще не так давно лет 6 назад любители вставит, Аноним84701 (ok), 15:28 , 03-Янв-20, (26) –2

В спеке на утф-8 сказано, что Eszett приравнивается к ss Я такого найти не см, Wilem (?), 15:42 , 03-Янв-20, (27)

Мне лень смотреть Ведь это не я писал о том, что ripgrep не учитывает особенно, Аноним84701 (ok), 17:29 , 03-Янв-20, (36) +4

Ну вот, опять восхищаюсь Вашими тщательностью и кругозором - Был бы рад знакомс, Michael Shigorin (ok), 19:44 , 03-Янв-20, (48)

Просто приходится много общаться с немецкоязычными, поэтому и разбираться с выве, Аноним84701 (ok), 20:08 , 03-Янв-20, (52) +1

Период, а не переод , Anonymoustus (ok), 11:46 , 05-Янв-20, (85)

У него беда с докой Он понимает опции -e, -f, -l, -n, -s, -q, -v , Аноним (13), 14:18 , 03-Янв-20, (13)

rg --helpДовольно подробная , Wilem (?), 14:23 , 03-Янв-20, (15) –1
https pastebin com N7xZyMnD, Wilem (?), 14:28 , 03-Янв-20, (17) –1

Я люблю Rust и юзаю rg, но вот такие провокационные комментарии мне совсем не нр, Аноним (18), 14:31 , 03-Янв-20, (18)

Тезис был grep - не нужен Если ты считаешь, что это не так, объясни - зачем ну, Wilem (?), 15:04 , 03-Янв-20, (24) –2

Я держусь позиции, что Rust должен будет заменить C, особенно когда до конца реш, Аноним (18), 15:51 , 03-Янв-20, (29) –2

Греп обязательно должен быть в стандартных поставках потому, что многие скрипты , Wilem (?), 16:02 , 03-Янв-20, (32) –1

В целом согласен, но все же поскольку от GNU grep пока никуда не убежишь, это хо, Аноним (18), 16:08 , 03-Янв-20, (33)

Я бы сказал -- тождественно равен нулю Особенно для тех, которые заморачиваютс, Michael Shigorin (ok), 19:41 , 03-Янв-20, (47) –1
Рано или поздно что-то заменит C Но почему вы уверены, что это будет Rust, а не, Аноним (61), 21:53 , 03-Янв-20, (61) +1

Возможно и не Rust Не хотелось бы, чтобы Verona, едва ли ситуация с именем в та, Аноним (18), 22:25 , 03-Янв-20, (65) –2

А конструкции типа более лучшая альтернатива грепать умеет Если нет,, Аноним (21), 17:59 , 03-Янв-20, (38)

Очевидно умеет, странный вопрос И сделает это намного быстрее , Аноним (18), 18:47 , 03-Янв-20, (40) –1

Поставил, пришлось скачать 15мб раст у меня был Установка заняла 5 минут, экз, Аноним (21), 19:13 , 03-Янв-20, (43) +2

Угу, здорово Я ведь тоже вам могу сейчас случайных чиселок набросать, но занима, Аноним (18), 19:31 , 03-Янв-20, (44) –2

Вы бы циферками и ответили, а не детским садом , Michael Shigorin (ok), 19:36 , 03-Янв-20, (45) +1

Я не большой специалист в данном вопросе, чтобы анализировать эти чиселки тем б, Аноним (18), 19:45 , 03-Янв-20, (49) –1

это детский сад, увы Нет, я тоже чаще меряю на глазок , чем отмеряю микром, Michael Shigorin (ok), 19:54 , 03-Янв-20, (51)

С высоты птичьего полета, безо всякой теории погрешностей У меня не SSD, как у , Аноним (18), 20:34 , 03-Янв-20, (54) –1

А чё, можете сами проверить Вот вам данные http ftp freedb org pub freedb fre, Аноним (21), 21:33 , 03-Янв-20, (60)

Вот вам более реальное тестирование Это всё, что нужно знать о хипстоподелках и, Аноним (21), 21:07 , 03-Янв-20, (58)

Ну знаю, у меня не было мнения Но я считаю, что должно быть сопоставимо с си, а, Аноним (21), 21:03 , 03-Янв-20, (57) –1

Ни разу не удавалось подобного результата добиваться, у меня всегда rg работал л, Аноним (18), 22:15 , 03-Янв-20, (63) –1
Честно говоря, не представляю, как вы такого добились и уже подумываю забрать св, Аноним (18), 00:20 , 04-Янв-20, (71)

В брошу свои чиселки с tmpfs, лучший результат 4 запусков code time rg -c , анонн. (?), 01:19 , 04-Янв-20, (77)

Вот потому я и не хотел играть в эти идиотские чиселки Всегда можно подобрать у, Аноним (18), 01:36 , 04-Янв-20, (79)

1 файл это не спортивно Лично мне нравится руст, но не нравится результат где п, Аноним (21), 01:34 , 04-Янв-20, (78)

Ну вот вам code find usr src -type f 124 wc -l 83928du -sh usr src2,5G u, анонн. (?), 00:37 , 04-Янв-20, (73) +2

В догонку rg --version , анонн. (?), 00:40 , 04-Янв-20, (74)
ok, grep ядра без кэшей , 0 5 мб памяти в пике, 2 5 shared code 2863real 0m1, Аноним (21), 01:13 , 04-Янв-20, (76)

Чего-чего, но падений я еще не видел Наверное, потому что не влезет в tmpfs, да , анонн. (?), 01:52 , 04-Янв-20, (80)

Мне Раст интересен Но растаманы оталкивают тем что серят в адрес Юникса, ГНУ и , Аноним (-), 18:20 , 03-Янв-20, (39) +4

В семье не без разнообразия Не знаю, кто занимается такими глупостями, но не, Аноним (18), 18:57 , 03-Янв-20, (41) +1

Что за глупый вопрос Смысл родительского коммента сводится к не нужно , какая , Ordu (ok), 22:00 , 03-Янв-20, (62)

Теперь осталось добавить опцию --cancel-no-ignore-case false , Аноним (3), 10:39 , 03-Янв-20, (3) +11

--switch-off-disable-cancel-no-ignore-case false true , Аноним (9), 13:49 , 03-Янв-20, (9) +1

остаётся только значение по умолчанию сделать рандомным, Аноним (9), 13:50 , 03-Янв-20, (10) +1

А может кто-то поделиться с домохозяйкой http www gnu org software grep manual, Аноним (4), 11:01 , 03-Янв-20, (4) –3

оно https www opennet ru man shtml topic grep russian 0 category submit F0 C, JL2001 (ok), 12:18 , 03-Янв-20, (8)
https www google com search q grep D0 B4 D0 BB D1 8F D1 87 D0 B0 D0 B9 D0 BD, iCat (ok), 14:23 , 03-Янв-20, (14) –1

не знаю как гулугулу , а тындекс выдал по запросу man grep в первую очередь н, San (??), 11:34 , 03-Янв-20, (5) +1

не знаю, что за тындэкс, но гугл первой ссылкой выдаёт на русском а ещё знаю, г, Аноним (9), 13:51 , 03-Янв-20, (11) –1

хотелось бы исключения файлов по маскам или по крайней мере упрощение, manster (ok), 16:02 , 03-Янв-20, (31) –1

Почитай про гну-тулбокс, и не проси глупостей Чтобы выбирать файлы или исключат, Ordu (ok), 17:16 , 03-Янв-20, (34)

мне в git grep нужно, manster (ok), 17:19 , 03-Янв-20, (35) –2

git-grep 1 до pathspec дочитайте - , Michael Shigorin (ok), 19:39 , 03-Янв-20, (46)

Заметил, что режим угадываний малоэффективен Разумеется в курсе, что git grep 1, manster (ok), 20:11 , 03-Янв-20, (53) –1

cat bashrcfunction git-grep git grep -- SOURCE_FILES_PATTERNS D, Ordu (ok), 21:24 , 03-Янв-20, (59) +1

Благодарю, мне представляется это неплохим решением, но не очень понятно как это, manster (ok), 22:19 , 03-Янв-20, (64)

Если я правильно понимаю, то как-то так cat emacs setq helm-git-grep-pathsp, Ordu (ok), 22:48 , 03-Янв-20, (68) +1

не, не делай ТАК Прочитай, все же, пока не запретили как неполиткорректную писан, . (?), 17:37 , 03-Янв-20, (37) –6

Хозяйке на заметку этот же организм в соседней теме про CCC бредил полониевым н, Michael Shigorin (ok), 18:58 , 03-Янв-20, (42) –2
Не, я не буду читать Кернигана, только для того, чтобы выяснить что-нибудь в сти, Ordu (ok), 20:56 , 03-Янв-20, (56) –1

Луговский похожую дорожку проходил несколько раньше -- возможно, Вам бы оказалос, Michael Shigorin (ok), 22:25 , 03-Янв-20, (66) –2

Что есть ГНУ Хорошую вещь ГНУ не назовут , Аноним (86), 16:28 , 05-Янв-20, (86)

Сообщения [Сортировка по времени | RSS]

1. "Выпуск утилиты GNU grep 3.4" –8 +/–

Сообщение от BSD_Cucks_BTFO (?), 03-Янв-20, 10:05

Не нужно. ripgrep в 3.5 быстрее.

Ответить | Правка | Наверх | Cообщить модератору

2. "Выпуск утилиты GNU grep 3.4" +10 +/–

Сообщение от A.Stahl (ok), 03-Янв-20, 10:13

А нам некуда спешить: тише едешь -- дальше будешь. А то грепают тута аки самолёты, нет чтобы остановиться и оглянуться куда летят-то. Кто-то ведь в пропасть летит. Но нет, летят, бегут куда-то. Зачем? Эх-х-х...

Ответить | Правка | Наверх | Cообщить модератору

19. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от qqq (??), 03-Янв-20, 14:39

иногда надо по-быстрому в многометровом логе найти нужное событие...

Ответить | Правка | Наверх | Cообщить модератору

22. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от 12345 (??), 03-Янв-20, 14:56

многогиговом

Ответить | Правка | Наверх | Cообщить модератору

50. "Выпуск утилиты GNU grep 3.4" +2 +/–

Сообщение от Michael Shigorin (ok), 03-Янв-20, 19:50

> многогиговом
Такие логи есть смысл сваливать в более специальные системы с индексированием, если поиск по ним является сколь-нибудь частой задачей.
Например, вот человек несколько лет назад описал свою "замену Splunk на открытом софте": http://edgeofsanity.net/article/2012/06/17/central-logging-w...

Ответить | Правка | Наверх | Cообщить модератору

55. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от IdeaFix (ok), 03-Янв-20, 20:52

Имхо, пока ничего лучше sawmill не придумали для этой задачи, но... даже sawmill как-то не может эффективно в 16-32 треда и в сотню гигов памяти. Да, логи скорее малотеровые, чем многогиговые....

Ответить | Правка | Наверх | Cообщить модератору

72. "Выпуск утилиты GNU grep 3.4" +1 +/–

Сообщение от GentooBoy (ok), 04-Янв-20, 00:32

Главное настроить систему логирования на системе логирования, что бы когда она будет падать определить причину.

Ответить | Правка | Наверх | Cообщить модератору

75. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Anonymouss (?), 04-Янв-20, 00:55

дороговато для грепа

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

20. "Выпуск утилиты GNU grep 3.4" +5 +/–

Сообщение от Аноним (20), 03-Янв-20, 14:49

Тогда греп надо на электрон переписать.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

87. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от супернуб (?), 06-Янв-20, 09:22

не успеюют - быстрее сделают grepd

Ответить | Правка | Наверх | Cообщить модератору

7. "Выпуск утилиты GNU grep 3.4" +1 +/–

Сообщение от Wilem (?), 03-Янв-20, 12:08

Да, rg и fd - должны быть на каждой системе. Fd кстати сделан поверх либы walkdir, которую тоже BurntSushi написал. Великий человек.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

12. "Выпуск утилиты GNU grep 3.4" +5 +/–

Сообщение от bircoph (ok), 03-Янв-20, 14:08

riggrep написан на rust, не учитывает особенности unicode (u(ss)->ß) и не портируем на некоторые современные и безопасные архитектуры.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

16. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Wilem (?), 03-Янв-20, 14:25

Объясни по-подробнее про особенности utf8, что не так?

Ответить | Правка | Наверх | Cообщить модератору

21. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (21), 03-Янв-20, 14:51

Я не знаю, что он имел в виду, но венда тоже не умеет в utf8. По-моему я даже в бсод ронял 10 и кучу програм в ней всего 1 символом (совершенно валидным в линуксе), не знаю, починили ли с тех пор. Так что особенности есть.

Ответить | Правка | Наверх | Cообщить модератору

23. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Wilem (?), 03-Янв-20, 15:02

https://snipboard.io/5E9mRX.jpg

Ответить | Правка | Наверх | Cообщить модератору

25. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Аноним (21), 03-Янв-20, 15:28

> https://snipboard.io/5E9mRX.jpg
Там свой особенный утф8, мало общего имеющий со стандартом. Дело не в том, что он не отображается, а в том, что юникод в венде будет совершенно свой (и если использовать его, проблемы будут у других систем), а часть символов и вовсе вызовет бсод и инстакраши софта (передаю привет notepad++). В линуксах не крашится.

Ответить | Правка | Наверх | Cообщить модератору

28. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Wilem (?), 03-Янв-20, 15:45

А что за символы с которыми крешится или которые несовместимы? Прям сейчас бы опробовал на винде и линуксе.

Ответить | Правка | Наверх | Cообщить модератору

30. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (21), 03-Янв-20, 16:00

> А что за символы с которыми крешится или которые несовместимы? Прям сейчас
> бы опробовал на винде и линуксе.
Я не помню, какие именно, но даже в википедии емнип было написано (в японской [1] так точно). Ну вот к примеру описываемые мной различия у вендоров [2].

[1] https://ja.wikipedia.org/wiki/Unicode
[2] https://web.archive.org/web/20110422181018/http://www.ingrid...

Ответить | Правка | Наверх | Cообщить модератору

67. "Выпуск утилиты GNU grep 3.4" –3 +/–

Сообщение от Аноним (67), 03-Янв-20, 22:33

UTF-8 не нужен при наличии полноценного юникода. Квест "угадай сколько байтов потянет каждый символ длинной-предлинной строчки если в ней гарантированно не только латиница" сильно на любителя.

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

69. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (21), 03-Янв-20, 22:57

> UTF-8 не нужен при наличии полноценного юникода. Квест "угадай сколько байтов потянет
> каждый символ длинной-предлинной строчки если в ней гарантированно не только латиница"
> сильно на любителя.
Полноценный - это какой? UTF-32? Ну да, там есть небольшой запас, чтобы на это забить и считать 4 байта примерно равно 1 символ (и то с оговорками вроде модифицирующих кодпоинтов). Только ведь он жутко неэффективный в части занимаемой памяти, правда?

Ответить | Правка | Наверх | Cообщить модератору

70. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Michael Shigorin (ok), 03-Янв-20, 23:09

> Полноценный - это какой? UTF-32?
В винде вроде двухбайтовый UCS2 фигурировал...
PS: "полноценный", ага.

Ответить | Правка | Наверх | Cообщить модератору

83. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (83), 04-Янв-20, 23:08

В UTF-8 в теории символ может до 6 байт весить, это сильно лучше или как?

Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

84. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (21), 04-Янв-20, 23:23

> В UTF-8 в теории символ может до 6 байт весить, это сильно
> лучше или как?
Очень в теории, текущий лимит 4 байта из соображений совместимости. И всяко лучше utf-16. [1] %)
По-моему, на практике 4 довольно редко встречалось и только в китайских текстах. Но это совершенно не важно, случайный доступ с юникодом просто не применяют.
[1] https://en.wikipedia.org/wiki/Plane_(Unicode)

Ответить | Правка | Наверх | Cообщить модератору

26. "Выпуск утилиты GNU grep 3.4" –2 +/–

Сообщение от Аноним84701 (ok), 03-Янв-20, 15:28

> riggrep написан на rust, не учитывает особенности unicode (u(ss)->ß)
Угу, то ли дело греп, на который еще не так давно (лет 6 назад) любители вставить "ß" затейливо матюкались  из-за принципиальных проблем поиска с умляутами.
% echo "THISS"|grep -ic "ß"
0
% echo "straße"|grep -ic "ss"
0
% grep --version
grep (GNU grep) 3.3

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

27. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Wilem (?), 03-Янв-20, 15:42

В спеке на утф-8 сказано, что Eszett приравнивается к "ss"? Я такого найти не смог, более того на стековерфлоу сами немцы говорят, что с точки зрения языка Eszett *не равен* "ss", плюс у них вокруг этого переодически правила меняются. Также интересно - какое дело до обработки этого символа юзеру опеннета? Товарищ парсит в консоли немецкие логи?

Ответить | Правка | Наверх | Cообщить модератору

36. "Выпуск утилиты GNU grep 3.4" +4 +/–

Сообщение от Аноним84701 (ok), 03-Янв-20, 17:29

> В спеке на утф-8 сказано, что Eszett приравнивается к "ss"?
Мне лень смотреть. Ведь это не я писал о том, что ripgrep "не учитывает особенности unicode (u(ss)->ß)".
Проще было проверить на практике – grep тоже как-то не очень учитывает (утф-8 используется по умолчанию)
> найти не смог, более того на стековерфлоу сами немцы говорят, что  с точки зрения языка Eszett *не равен* "ss", плюс у них вокруг этого переодически правила меняются.
Конечно не равен – вы не можете заменить любую двойную "ss" на ß.
А вот наоборот - (грубо говоря) всегда. Даже в деловой переписке это не будет чем-то уж слишком "из ряда вон".
Но да, стековерфлоу – это конечно авторитет! Куда тем же "Дойче Правописание [Правила]" (§25)  до мнения авторитетов 🙄
https://www.rechtschreibrat.com/DOX/rfdr_Regeln_2016_redigie...
https://www.duden.de/sprachwissen/rechtschreibregeln/doppel-...
> E2: Steht der Buchstabe ß nicht zur Verfügung, so schreibt man ss. In der Schweiz kann man immer ss schreiben. Beispiel: Straße – Strasse
> Если нет буквы  ß  - пишем ss. В Швейцарии  вообще можно всегда писать ss вместо ß.
.
> E3: Bei Schreibung mit Großbuchstaben schreibt man SS. Daneben ist auch die Verwendung des Großbuchstabens ẞ möglich. Beispiel: Straße – STRASSE – STRAẞE.
> Для заглавных/прописных букв используется SS. (Если в шрифте присутствует - старая формулировка до ввода "официальной" большой ß) прописная ß, то возможно написание с <большая ß>
Кстати, авторитеты не затрагивали проблему поиска в старых документах, где вместо isst, dass, wusste писали ißt, daß, wußte?
Небольшая подсказка насчет новых-старых правил:
Любителям умляутов (причем, вполне серьезным и уважаемым изданиям газет и журналов)  не впервой просто проигнорировать "блидинг-эдж" нововведения, вплоть до их отмены или серьезной переработки ;)
Да и благодаря таким "реформам" с отменами - до сих пор вполне нормально воспринимается старое правописание.
Ну и матюкались не на то, что ß не заменялось на "ss" при поиске, а на то, что ни ß, ни поиск öäü - вообще не работал толком:
http://www.knoppixforum.de/knoppix-forum-deutsch/sonstiges/t...
https://forum.ubuntuusers.de/topic/grep-findet-keine-umlaute...
https://bbs.archlinux.org/viewtopic.php?id=96082
(длинный список по запросу поисковика "grep umlauts")
А если задаться целью - то на грабли c умляутами до сих пор и на утф8 наткнуться можно:
https://stackoverflow.com/questions/24962147/grep-and-utf-8-...
https://stackoverflow.com/questions/49535221/how-to-grep-uml...
> Также интересно - какое дело до обработки этого символа юзеру опеннета? Товарищ парсит в консоли немецкие логи?
Мне лично - никакого.
Но критиковать ripgrep, тактично умалчивая о той же проблеме в grep --  немножечко отдает двойными стандартами.

Ответить | Правка | Наверх | Cообщить модератору

48. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Michael Shigorin (ok), 03-Янв-20, 19:44

> Небольшая подсказка насчет новых-старых правил:
Ну вот, опять восхищаюсь Вашими тщательностью и кругозором :-)
Был бы рад знакомству.
PS: а может, в 2020 опеннетовку проведём хотя бы в Москве или Питере?

Ответить | Правка | Наверх | Cообщить модератору

52. "Выпуск утилиты GNU grep 3.4" +1 +/–

Сообщение от Аноним84701 (ok), 03-Янв-20, 20:08

>> Небольшая подсказка насчет новых-старых правил:
> Ну вот, опять восхищаюсь Вашими тщательностью и кругозором :-)
Просто приходится много общаться с немецкоязычными, поэтому и разбираться с вывертами правописания  приходилось особо тщательно – так что это не кругозор, а скорее "сопутствующие спец. знания"  ;-)
> Был бы рад знакомству.
> PS: а может, в 2020 опеннетовку проведём хотя бы в Москве или Питере?
Лет 6-7 назад вполне. Сейчас, к сожалению, то семья, то здоровье "теребят".

Ответить | Правка | Наверх | Cообщить модератору

85. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Anonymoustus (ok), 05-Янв-20, 11:46

> переодически
Период, а не переод.

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

13. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (13), 03-Янв-20, 14:18

У него беда с докой. Он понимает опции -e, -f, -l, -n, -s, -q, -v?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

15. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Wilem (?), 03-Янв-20, 14:23

    rg --help
Довольно подробная.

Ответить | Правка | Наверх | Cообщить модератору

17. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Wilem (?), 03-Янв-20, 14:28

https://pastebin.com/N7xZyMnD

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

18. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (18), 03-Янв-20, 14:31

Я люблю Rust и юзаю rg, но вот такие провокационные комментарии мне совсем не нравятся. rg - это альтернативная молодая тула: пусть со своими шикарными преимуществами, но и со своими альтернативными недостатками. Нет ничего плохого в том, что стандартный инструмент развивается и становится лучше, потому что этот инструмент на данный момент везде.
На opennet и так люто ненавидят Rust и костерят его всякими "хрустами", а такие провокации только масла в огонь подливают. Или это и была цель?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

24. "Выпуск утилиты GNU grep 3.4" –2 +/–

Сообщение от Wilem (?), 03-Янв-20, 15:04

Тезис был: grep - не нужен. Если ты считаешь, что это не так, объясни - зачем нужен grep при наличии лучшей альтернативы?

Ответить | Правка | Наверх | Cообщить модератору

29. "Выпуск утилиты GNU grep 3.4" –2 +/–

Сообщение от Аноним (18), 03-Янв-20, 15:51

Я держусь позиции, что Rust должен будет заменить C, особенно когда до конца решатся все проблемы llvm с алиасингом и Rust станет в целом быстрее, чем C. Но по банальной реакции аудитории opennet на Rust видно, что сообщество пока к этому не готово (в англоязычном сообществе примерно такая же ситуация, только без такого количества агрессии).
Но на данный момент конкретно с rg я вижу такие очевидные проблемы:
1. rg не POSIX-совместим. Это не то чтобы плохо, стандарту POSIX уже сколько лет и пора бы двигаться дальше, но пока это проблема. В целом, это решаемо банальным созданием POSIX-совместимой обертки.
2. llvm пока поддерживает не так много архитектур
3. Rust пока что вызвает много недоверия у сообщества, потому шанс того, что мейнтейнеры текущих популярных дистрибутивов зареплейсят grep на rg в качестве стандартной утилиты довольно мал. Соотвественно на данный момент важно, чтобы GNU grep существовал хотя бы на аппарате жизнеобеспечения.

Ответить | Правка | Наверх | Cообщить модератору

32. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Wilem (?), 03-Янв-20, 16:02

Греп обязательно должен быть в стандартных поставках потому, что многие скрипты его используют. Но самому пользоваться грепом не вижу смысла. Также, как и find-ом (fd сильно быстрее). Я их оба два закатал в базовый докеровский образ на котором остальные все образы на работе базируются. Очень удобно.
Что касается пакетов в дистрибутивах, это вообще по-барабану - есть ripgrep в пакетах или нет. cargo install ripgrep если для личных нужд. А для рабочих есть ansible или образы для поддержания единства конфигурации машин.

Ответить | Правка | Наверх | Cообщить модератору

33. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (18), 03-Янв-20, 16:08

В целом согласен, но все же поскольку от GNU grep пока никуда не убежишь, это хорошо, что в нем хотя бы баги латают.

Ответить | Правка | Наверх | Cообщить модератору

47. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Michael Shigorin (ok), 03-Янв-20, 19:41

> 3. Rust пока что вызвает много недоверия у сообщества, потому шанс
> того, что мейнтейнеры текущих популярных дистрибутивов зареплейсят
> grep на rg в качестве стандартной утилиты довольно мал.
Я бы сказал -- тождественно равен нулю.  Особенно для тех, которые заморачиваются не-x86 (и ещё и не-arm) -- там "помножить на хреновую поддержку архитектур".

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

61. "Выпуск утилиты GNU grep 3.4" +1 +/–

Сообщение от Аноним (61), 03-Янв-20, 21:53

>Я держусь позиции, что Rust должен будет заменить C,
Рано или поздно что-то заменит C. Но почему вы уверены, что это будет Rust, а не, например, Verona или подмножество betterC языка D?
>особенно когда до конца решатся все проблемы llvm с алиасингом и Rust станет в целом быстрее, чем C
А как решится проблема с запретом использования названия Rust в альтернативных реализциях? Кажется, уже кто-то наступал на подобные грабли, не Sun ли это был?

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

65. "Выпуск утилиты GNU grep 3.4" –2 +/–

Сообщение от Аноним (18), 03-Янв-20, 22:25

Возможно и не Rust. Не хотелось бы, чтобы Verona, едва ли ситуация с именем в таком случае будет лучше, а то может и не в одном имени проблемы будут, это же microsoft.
По крайней мере, даже если с Rust что-то пойдет не так, скорее всего тот язык, который таки прочно заменит C, будет как минимум использовать многие идеи и наработки из Rust.
Просто пока у Rust больше всех шансов. К D никто интереса не проявляет, да и он на самом деле не решает такого количества проблем, как Rust, да и комбинация ооп и функционального программирования в Rust очень здорово работает, как по мне. Насколько знаю, автор D даже начал делать borrow checker для своего языка, чтобы это исправить. Может что-то из этого и выйдет. Про Better C мало слышал, чуть позже почитаю.

Ответить | Правка | Наверх | Cообщить модератору

38. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (21), 03-Янв-20, 17:59

А конструкции типа (\[.*?\]+) более лучшая альтернатива грепать умеет? Если нет, то сами знаете, куда её запихнуть вместе с авторами, потому что это совсем не альтернатива.

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

40. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Аноним (18), 03-Янв-20, 18:47

Очевидно умеет, странный вопрос. И сделает это намного быстрее.

Ответить | Правка | Наверх | Cообщить модератору

43. "Выпуск утилиты GNU grep 3.4" +2 +/–

Сообщение от Аноним (21), 03-Янв-20, 19:13

>намного быстрее
Поставил, пришлось скачать 15мб (раст у меня был). Установка заняла 5 минут, экзешник 4.5 мегабайта (греп 0.2 мегабайта - отработает пока оно считается в память!).
По факту, результаты следующие.
grep(на холодную без кэшей):
real    0m0.009s
user    0m0.001s
sys     0m0.002s
rg(на холодную без кэшей):
real    0m0.038s
user    0m0.002s
sys     0m0.005s
grep(повторный запуск подряд):
real    0m0.002s
user    0m0.001s
sys     0m0.001s
rg(повторный запуск подряд):
real    0m0.004s
user    0m0.003s
sys     0m0.001s

Данных было 15 байт, система на ссд. Вывод: ваша информация - очередной фейк.

Ответить | Правка | Наверх | Cообщить модератору

44. "Выпуск утилиты GNU grep 3.4" –2 +/–

Сообщение от Аноним (18), 03-Янв-20, 19:31

Угу, здорово. Я ведь тоже вам могу сейчас случайных чиселок набросать, но заниматься этим я, конечно, не буду, потому что это детский сад.
Если бы вы действительно хотели выяснить правду, а не подтвердить для себя собственное мнение, вы бы серьезно изучили вопрос, провели бы много разных тестов и скорее всего сюда бы ничего не написали.

Ответить | Правка | Наверх | Cообщить модератору

45. "Выпуск утилиты GNU grep 3.4" +1 +/–

Сообщение от Michael Shigorin (ok), 03-Янв-20, 19:36

Вы бы циферками и ответили, а не детским садом.

Ответить | Правка | Наверх | Cообщить модератору

49. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Аноним (18), 03-Янв-20, 19:45

Я не большой специалист в данном вопросе, чтобы анализировать эти чиселки (тем более не имея на руках тестовых данных, что делает ситуацию еще более глупой). Все, что я могу сказать - на моей машине rg работает во много раз быстрее.
Обращаясь и к вам, и к остальным читающим. Не слушайте ни меня, ни господина с чиселками - поставьте rg на свою машину и протестируйте на своих реальных задачах. Было бы очень глупо, если бы вы сейчас прочтитали господина с чиселками, вам понравилось его мнение (ведь конечно, Rust ничего не может и пишут на нем глупые хипстеры), а в итоге оказаться неправым, верно?

Ответить | Правка | Наверх | Cообщить модератору

51. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Michael Shigorin (ok), 03-Янв-20, 19:54

> Все, что я могу сказать -
...это детский сад, увы.  Нет, я тоже чаще "меряю на глазок", чем отмеряю микрометром [и отрубаю топором], но это всё же осознавать надо.
> Обращаясь и к вам, и к остальным читающим. Не слушайте ни меня,
> ни господина с чиселками - поставьте rg на свою машину
Перечитайте, пожалуйста, #12 и подскажите, где взять rust для e2k.  Моя основная рабочая машина именно на этой архитектуре.
PS: если "чиселки" не разобрали -- хотя бы отгрепав глазами(sic!) по real -- то главная из них там была 15 (та, что в последней строчке), как мне кажется.  По сути это измерение скорости запуска, а для оценки самой молотилки стоило бы погонять на -F разной длины и регэксах разной заковыристости по массивам данных от единиц байт (как там) до хотя бы мегабайт.  Если интересно -- ну так займитесь же, заодно можно теорию погрешностей подтянуть или вовсе открыть для себя :-)

Ответить | Правка | Наверх | Cообщить модератору

54. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Аноним (18), 03-Янв-20, 20:34

С высоты птичьего полета, безо всякой теории погрешностей. У меня не SSD, как у господина с чиселками - у меня зашифрованный раздел на жестком диске, и на нем я наблюдаю значительную разницу. И чиселками я бросаться не буду, потому что числелки на каких-то непонятных данных, на чьей-то чужой машине со своей конфигурацией, в чем-то убеждают, мне кажется, только не слишком далеких людей.
> где взять rust для e2k.
Архитектура довольно молодая, почему она уже обязана поддерживаться llvm? Прочитал, что у вас есть двоичная трансляция из x86 - можете с ней попробовать. Я не то чтобы евангелист llvm - лучше бы у Rust был свой бекенд. Но пока как есть.

Ответить | Правка | Наверх | Cообщить модератору

60. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (21), 03-Янв-20, 21:33

>непонятных данных
А чё, можете сами проверить. Вот вам данные http://ftp.freedb.org/pub/freedb/freedb-complete-20191203.ta... и вот вам текст, который нужно извлечь во всех файлах: '(\[.*?\]+)'
Теперь если скажете, какие ключи надо скормить rg, тобы тот отработал сопоставимо с grep -RPo * (и желательно выдал те же данные в том же формате), я признаю, что раст имеет право на существование.

Ответить | Правка | Наверх | Cообщить модератору

58. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (21), 03-Янв-20, 21:07

Вот вам более реальное тестирование. Это всё, что нужно знать о хипстоподелках и восторженных отзывах в интернете.
https://www.opennet.dev/openforum/vsluhforumID3/119373.html#57

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

57. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Аноним (21), 03-Янв-20, 21:03

> Угу, здорово. Я ведь тоже вам могу сейчас случайных чиселок набросать, но
> заниматься этим я, конечно, не буду, потому что это детский сад.
> Если бы вы действительно хотели выяснить правду, а не подтвердить для себя
> собственное мнение, вы бы серьезно изучили вопрос, провели бы много разных
> тестов и скорее всего сюда бы ничего не написали.
Ну знаю, у меня не было мнения. Но я считаю, что должно быть сопоставимо с си, а не в 4 раза медленней (тем более, если речь идёт об использовании в скриптах, а не о разборе гигабайтов текста).
Пытаюсь придумать тестирование с другим тестовым набором данных (где я возьму гигабайт текста?), но пока не получается и результаты выглядят ещё хуже для противников гну.
Хорошо, реальный юзкейс. Грепнул 1.1гб текста/1100000 файлов (сущий пустяк, в принципе, во всяком случае для меня и моих данных) и чёт совсем  грустно стало. В общем, прекращайте фейкомётить.
rg:
real    61m38.956s
user    0m34.536s
sys     1m1.371s
grep:
real    2m44.097s
user    0m11.746s
sys     0m24.306s

Во время работы рг потреблял 200+ мб оперативки (уже несколько дико для применения в скриптах), греп всего 30мб. А если его тысячу раз в секунду вызывать? Ведь чем больше футпринт, тем больше сайд эффектов при использовании выплывает.
Зачем он спавнит кучу тредов, кстати? Ведь всё равно значительно быстрее не будет, а на случайном доступе просадки только такие. Выглядит, как типичная хипстоподелка каких-то школьников. Не то, чтобы это было плохо само по себе, но вот то, как вы о ней отзываетесь... И это будет конкурировать с гну греп? Вы серьёзно? Посмотрите на цифры ещё раз: менее 3х минут и более 60...

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

63. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Аноним (18), 03-Янв-20, 22:15

Ни разу не удавалось подобного результата добиваться, у меня всегда rg работал лучше. Что ж, значит ripgrep еще не так хорош и ему есть над чем работать, все же GNU grep куда более зрелая тула. Попробую воспроизвести что-то подобное у себя. Пока не очень получилось.

Ответить | Правка | Наверх | Cообщить модератору

71. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (18), 04-Янв-20, 00:20

Честно говоря, не представляю, как вы такого добились и уже подумываю забрать свои слова назад. Скорее всего проблема в количестве файлов - на огромном числе файлов я еще не проверял.
Я зарекался чиселки кидать, но ладно. Нашел рандомные логи http://www.almhuette-raith.at/apache-log/access.log (906M)
> time rg '(\[.*?\]+)' access.log | wc -l
4595960
real    0m1.306s
user    0m1.206s
sys    0m0.577s
> time grep -P '(\[.*?\]+)' access.log | wc -l
4595960
real    0m2.329s
user    0m2.101s
sys    0m0.949s
Больше всего отличился ag:
> time ag '(\[.*?\]+)' access.log | wc -l
4595960
real    0m22.608s
user    0m22.472s
sys    0m0.986s
После я рандомным образом изменил паттерн.
> time rg '(\[.*?\]+).*test' test.log | wc -l
6302
real    0m0.266s
user    0m0.203s
sys    0m0.072s
Ни для grep, ни для ag я результата дождаться не смог. Не знаю, с чем это связано (скорее всего с этим: https://mariusschulz.com/blog/why-using-the-greedy-in-regula... - потому вдвойне забавно, что rg это спокойно прожевал), но сейчас нет возможности доводить эксперимент до конца.

Может хватит обзывать "школьными хипстерскими поделками" все, что вам лично не нравится по идеологическим причинам? Потому что лично вы себя ведете как самый обыкновенный школьник-задира.

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

77. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от анонн. (?), 04-Янв-20, 01:19

> Я зарекался чиселки кидать, но ладно. Нашел рандомные логи http://www.almhuette-raith.at/apache-log/access.log
> (906M)
(В)брошу свои чиселки:
>> time rg '(\[.*?\]+)' access.log | wc -l
> 4595960
> real 0m1.306s
> user 0m1.206s
> sys 0m0.577s
>> time grep -P '(\[.*?\]+)' access.log | wc -l
> 4595960
> real 0m2.329s
> user 0m2.101s
> sys 0m0.949s
с tmpfs, лучший результат 4 запусков

% time rg -c '(\[.*?\]+)' access.log
4596036
rg -c '(\[.*?\]+)' access.log  1,46s user 0,17s system 99% cpu 1,632 tota
% time rg -c -j1 '(\[.*?\]+)' access.log
4596036
rg -c -j1 '(\[.*?\]+)' access.log  1,46s user 0,15s system 99% cpu 1,607 total
time /usr/local/bin/grep -cP '(\[.*?\]+)' access.log
4596036
/usr/local/bin/grep -cP '(\[.*?\]+)' access.log  3,53s user 0,28s system 99% cpu 3,813 total
> Ни для grep, ни для ag я результата дождаться не смог. Не
> знаю, с чем это связано (скорее всего с этим: https://mariusschulz.com/blog/why-using-the-greedy-in-regula...
> - потому вдвойне забавно, что rg это спокойно прожевал), но сейчас
> нет возможности доводить эксперимент до конца.
Тут уже находили анти-паттерн для rg:

seq 100000000 > fstfile
time rg -ic 1 fstfile
47400465
rg -ic 1 fstfile  5,10s user 0,13s system 99% cpu 5,237 total
time /usr/local/bin/grep -ic 1 fstfile
47400465
/usr/local/bin/grep -ic 1 fstfile  4,28s user 0,35s system 99% cpu 4,640 total

time /usr/local/bin/grep -ic "^1" fstfile
11111113
/usr/local/bin/grep -ic "^1" fstfile  3,02s user 0,33s system 99% cpu 3,351 total
time rg -ic "^1" fstfile
11111113
rg -ic "^1" fstfile  7,77s user 0,24s system 99% cpu 8,019 total

Но это уж совсем синтетика - стоит добавить пару знаков и разница уходит:

time rg -ic "^12" fstfile
11111
rg -ic "^12" fstfile  1,83s user 0,19s system 99% cpu 2,020 total
time /usr/local/bin/grep -ic "^12" fstfile
11111
/usr/local/bin/grep -ic "^12" fstfile  2,69s user 0,32s system 99% cpu 3,017 total

Удивительно правда, что у здешнего анонима _все_ оказалось антипаттерном, да еще и c разницей на порядки.

Ответить | Правка | Наверх | Cообщить модератору

79. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (18), 04-Янв-20, 01:36

> Удивительно правда, что у здешнего анонима _все_ оказалось антипаттерном, да еще и c разницей на порядки.
Вот потому я и не хотел играть в эти идиотские чиселки. Всегда можно подобрать удобное окружение и подходящие данные, для которых чиселки какие надо получатся. Для такого инструмента как grep, в конечном счете все определяет только личная статистика использования на повседневных задачах. Моя такова, что на моих задачах и на моих машинах rg выигрывает.
Но раз уж я влез в эту глупость, все-таки проверил grep и ag:
> time grep -P '(\[.*?\]+).*test' test.log | wc -l
6302
real    9m2.752s
user    9m2.289s
sys    0m0.080s
> time ag '(\[.*?\]+).*test' test.log | wc -l
6302
real    8m34.161s
user    8m33.436s
sys    0m0.100s

Ответить | Правка | Наверх | Cообщить модератору

78. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (21), 04-Янв-20, 01:34

1 файл это не спортивно. Лично мне нравится руст, но не нравится результат где примитивная утилита сливает в 20 раз на типичном юзкейсе.

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

73. "Выпуск утилиты GNU grep 3.4" +2 +/–

Сообщение от анонн. (?), 04-Янв-20, 00:37

> Хорошо, реальный юзкейс. Грепнул 1.1гб текста/1100000 файлов (сущий пустяк, в принципе,
> во всяком случае для меня и моих данных) и чёт совсем
>  грустно стало. В общем, прекращайте фейкомётить.
Ну вот вам:

find /usr/src -type f |wc -l
   83928
du -sh /usr/src
2,5G    /usr/src

результат третьего запуска греп (чтоб точно искать с кэша):

grep --version
grep (GNU grep) 3.3
Copyright (C) 2018 Free Software Foundation, Inc.
time /usr/local/bin/grep -RPo  '(\[.*?\]+)' /usr/src |wc -l
1093008
/usr/local/bin/grep -RPo '(\[.*?\]+)' /usr/src  8,14s user 1,85s system 99% cpu 9,995 total
wc -l  0,12s user 0,00s system 1% cpu 9,994 total
time rg -uuuo '(\[.*?\]+)' /usr/src |wc -l
1093006
rg -uuuo '(\[.*?\]+)' /usr/src  3,22s user 3,22s system 354% cpu 1,818 total
wc -l  0,10s user 0,22s system 17% cpu 1,815 total

в один тред

% time rg -uuuo -j1 '(\[.*?\]+)' /usr/src |wc -l
1093006
rg -uuuo -j1 '(\[.*?\]+)' /usr/src  2,02s user 1,70s system 99% cpu 3,728 total
wc -l  0,09s user 0,02s system 2% cpu 3,726 total

Потребление памяти: 18МБ RES.
Похоже кто-то, не будем указывать пальцем на анонима, собрал дебаг-билд и бодро с ним сравнил релиз билд grep. Ну или точные опции запуска - в студию!

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

74. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от анонн. (?), 04-Янв-20, 00:40

В догонку:
rg --version
ripgrep 11.0.2

Ответить | Правка | Наверх | Cообщить модератору

76. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (21), 04-Янв-20, 01:13

ok, grep ядра (без кэшей), 0.5 мб памяти в пике, 2.5 shared

2863
real    0m17.642s
user    0m4.675s
sys     0m1.727s

rg (без кэшей, упал?), 1мб памяти в пике плюс 5.5 shared

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:378:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
2862
real    0m18.099s
user    0m0.976s
sys     0m1.803s

в 4 потока rg

2862
real    0m5.618s
user    0m0.784s
sys     0m1.573s
Справедливости ради повторный запуск grep

real    0m5.130s
user    0m4.546s
sys     0m0.539s
повторный запуск rg

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:378:21
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: __libc_start_main
  18: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
2862
real    0m1.035s
user    0m0.540s
sys     0m0.459s

rg в 4 потока

2862
real    0m0.721s
user    0m0.559s
sys     0m0.518s
по-моему всё это множится на 0 фактом того, что данных мало и они синтетические в рамках данного "теста".
Вон я же дал датасет приближенный к реальным данным, почему не используете его? http://ftp.freedb.org/pub/freedb/freedb-complete-20191203.ta...
Ну и стоит всё же использовать hdd, на ssd вы много данных не разместите.
>дебаг-билд
нет

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

80. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от анонн. (?), 04-Янв-20, 01:52

> rg (без кэшей, упал?), 1мб памяти в пике плюс 5.5 shared
Чего-чего, но падений я еще не видел.
> Вон я же дал датасет приближенный к реальным данным, почему не используете
> его? http://ftp.freedb.org/pub/freedb/freedb-complete-20191203.ta...
Наверное, потому что не влезет в tmpfs, да и качаться будет минут 10?
> Ну и стоит всё же использовать hdd, на ssd вы много данных не разместите.
Это мне в ящике стола ковыряться, хард искать, подключать … да и какой смысл измерять скорость чтения с диска, в который все и упрется (если оно не поместится в кэше).
>>дебаг-билд
> нет
Но билд, судя по паникам - кривоват.

Ответить | Правка | Наверх | Cообщить модератору

39. "Выпуск утилиты GNU grep 3.4" +4 +/–

Сообщение от Аноним (-), 03-Янв-20, 18:20

Мне Раст интересен. Но растаманы оталкивают тем что серят в адрес Юникса, ГНУ и Си.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

41. "Выпуск утилиты GNU grep 3.4" +1 +/–

Сообщение от Аноним (18), 03-Янв-20, 18:57

В семье не без... разнообразия. Не знаю, кто занимается такими глупостями, но не обращайте внимания. Изучайте себе язык в удовольствие и не слушайте поехавших - их везде хватает.
Если бы не C, Rust никогда бы не появился. Rust имеет много корней, в том числе сугубо функциональных, но достоинства и недостатки C в значительной степени повлияли на дизайн Rust. Глупо высмеивать C просто потому, что он не в состоянии дать те же возможности и гарантии, что и Rust, в силу необходимости поддерживать обратную совместимоть. То же с GNU и UNIX - все новое строится на их достижениях и ошибках. Как тут можно что-то высмеивать.

Ответить | Правка | Наверх | Cообщить модератору

62. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Ordu (ok), 03-Янв-20, 22:00

> Или это и была цель?
Что за глупый вопрос? Смысл родительского коммента сводится к "не нужно", какая ещё цель кроме провокации cpaча могла за этим стоять?

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

3. "Выпуск утилиты GNU grep 3.4" +11 +/–

Сообщение от Аноним (3), 03-Янв-20, 10:39

> В новой версии добавлена опция "--no-ignore-case", отключающая действие настроек отмены учёта регистра символов (-i, --ignore-case).
Теперь осталось добавить опцию --cancel-no-ignore-case[=false]

Ответить | Правка | Наверх | Cообщить модератору

9. "Выпуск утилиты GNU grep 3.4" +1 +/–

Сообщение от Аноним (9), 03-Янв-20, 13:49

--switch-off-disable-cancel-no-ignore-case[=false[=true]]

Ответить | Правка | Наверх | Cообщить модератору

10. "Выпуск утилиты GNU grep 3.4" +1 +/–

Сообщение от Аноним (9), 03-Янв-20, 13:50

остаётся только значение по умолчанию сделать рандомным

Ответить | Правка | Наверх | Cообщить модератору

4. "Выпуск утилиты GNU grep 3.4" –3 +/–

Сообщение от Аноним (4), 03-Янв-20, 11:01

А может кто-то поделиться с домохозяйкой http://www.gnu.org/software/grep/manual/grep.html только  на русском?
гулугулу какие-то куски даёт?

Ответить | Правка | Наверх | Cообщить модератору

8. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от JL2001 (ok), 03-Янв-20, 12:18

> А может кто-то поделиться с домохозяйкой http://www.gnu.org/software/grep/manual/grep.html
> только  на русском?
> гулугулу какие-то куски даёт?
оно?
https://www.opennet.dev/man.shtml?topic=grep&russian=0&catego...

Ответить | Правка | Наверх | Cообщить модератору

14. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от iCat (ok), 03-Янв-20, 14:23

https://www.google.com/search?q=grep+%D0%B4%D...

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

5. "Выпуск утилиты GNU grep 3.4" +1 +/–

Сообщение от San (??), 03-Янв-20, 11:34

не знаю как "гулугулу", а тындекс выдал по запросу "man grep" в первую очередь на русском и первая ссылка на самом опеннете: https://www.opennet.dev/man.shtml?topic=grep&category=1

Ответить | Правка | Наверх | Cообщить модератору

11. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Аноним (9), 03-Янв-20, 13:51

не знаю, что за тындэкс, но гугл первой ссылкой выдаёт на русском. а ещё знаю, где запятые ставить

Ответить | Правка | Наверх | Cообщить модератору

31. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от manster (ok), 03-Янв-20, 16:02

хотелось бы исключения файлов по маскам или по крайней мере упрощение

Ответить | Правка | Наверх | Cообщить модератору

34. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Ordu (ok), 03-Янв-20, 17:16

> хотелось бы исключения файлов по маскам
Почитай про гну-тулбокс, и не проси глупостей. Чтобы выбирать файлы или исключать файлы есть find.
Делай так: find <find-options> -exec grep -H <grep-options> {} \;
> упрощение
Упрощение чего?

Ответить | Правка | Наверх | Cообщить модератору

35. "Выпуск утилиты GNU grep 3.4" –2 +/–

Сообщение от manster (ok), 03-Янв-20, 17:19

мне в git grep нужно

Ответить | Правка | Наверх | Cообщить модератору

46. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Michael Shigorin (ok), 03-Янв-20, 19:39

> мне в git grep нужно
git-grep(1) до pathspec дочитайте :-)

Ответить | Правка | Наверх | Cообщить модератору

53. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от manster (ok), 03-Янв-20, 20:11

Заметил, что режим угадываний малоэффективен. Разумеется в курсе, что git grep 123 -- *.c
Мне надо, чтобы набор масок читался откуда-то из пременных окружений, это раньше работало и вопросов не было.

Ответить | Правка | Наверх | Cообщить модератору

59. "Выпуск утилиты GNU grep 3.4" +1 +/–

Сообщение от Ordu (ok), 03-Янв-20, 21:24

> Заметил, что режим угадываний малоэффективен. Разумеется в курсе, что git grep 123
> -- *.c
> Мне надо, чтобы набор масок читался откуда-то из пременных окружений, это раньше
> работало и вопросов не было.
cat >>~/.bashrc
function git-grep() {
    git grep $* -- $SOURCE_FILES_PATTERNS
}
^D
exec bash -l

Ответить | Правка | Наверх | Cообщить модератору

64. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от manster (ok), 03-Янв-20, 22:19

Благодарю,
мне представляется это неплохим решением,
но не очень понятно как это адаптировать для применения в https://github.com/yasuyk/helm-git-grep

Ответить | Правка | Наверх | Cообщить модератору

68. "Выпуск утилиты GNU grep 3.4" +1 +/–

Сообщение от Ordu (ok), 03-Янв-20, 22:48

> Благодарю,
> мне представляется это неплохим решением,
> но не очень понятно как это адаптировать для применения в https://github.com/yasuyk/helm-git-grep
Если я правильно понимаю, то как-то так:
cat >>~/.emacs
(setq helm-git-grep-pathspecs (getenv "SOURCE_FILES_PATTERNS"))
^D
Может не совсем так, может придётся распарсить $SOURCE_FILES_PATTERNS на отдельные слова, и засунуть в helm-git-grep-pathspecs список слов. Может быть я неправильно понимаю назначение helm-git-grep-pathspecs, и тогда надо будет найти подходящую переменную, или даже создать эту переменную и кинуть в тот github-реп пулл-реквест. Это уже детали, с которыми ты сам можешь разобраться.

Ответить | Правка | Наверх | Cообщить модератору

37. "Выпуск утилиты GNU grep 3.4" –6 +/–

Сообщение от . (?), 03-Янв-20, 17:37

не, не делай ТАК.
Прочитай, все же, пока не запретили как неполиткорректную писанину, книжку Кернигана, про юникс, а не про какой-то там gnushitbox. Этим "новым стандартам" вряд ли суждено прожить тридцать лет, как тем.
Скорее всего, отправятся на помойку, как немодные, еще лет через пяток.
Заодно - сам, без дополнительных пояснений, сообразишь, после прочтения и, разумеется, понимания, почему это никуда не годная привычка (а владеющему немодным слепым набором - еще и неудобнее набирать, чем правильный вариант)

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

42. "Выпуск утилиты GNU grep 3.4" –2 +/–

Сообщение от Michael Shigorin (ok), 03-Янв-20, 18:58

> Прочитай, все же, пока не запретили как неполиткорректную писанину
Хозяйке на заметку: этот же организм в соседней теме про CCC бредил полониевым новичком -- похоже, избирательно доверчив, аки дитя малое... ну а здесь find(1) записал в отходы.  Возможно, всё-таки "просто" с бодуна такое полезло.
Другое дело, что предусмотрительному человеку бывает полезно ещё и о пробелах подумать хотя бы -- см. самое начало http://altlinux.org/spp
PS: хотя K&P про универсальную среду программирования -- хороший совет, ага.

Ответить | Правка | Наверх | Cообщить модератору

56. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Ordu (ok), 03-Янв-20, 20:56

> Заодно - сам, без дополнительных пояснений, сообразишь, после прочтения и, разумеется, понимания
Не, я не буду читать Кернигана, только для того, чтобы выяснить что-нибудь в стиле "правильный вариант передавать список файлов из find в grep -- пайп, а всё остальное -- неправославно". Мне не интересно это. Ну реально, догмы мне надоели. Я переключился на борьбу с догмами, но и это мне надоело последнее время. Поэтому оставь этот сборник догм за авторством Кернигана себе. Просто перечитай его сам, отдохни душой, просветлись умом. Но не надо мне его подсовывать.
> владеющему немодным слепым набором - еще и неудобнее набирать, чем правильный вариант
Слепой набор, наоборот очень моден, тут ты что-то путаешь. Сколько раз твердили админам и кодерам, что он им бесполезен, что если они заняты делом а не туфтой, то 300 зн/мин они не смогут набирать ни при каких условиях, что для того, чтобы набрать пару тысяч строк кода за рабочий день* им и 60 зн/мин хватит за глаза и за уши, а они всё равно дpoчат на слепой набор.
*) Это кстати кто-то из тех самых патриархов юникс заялял -- Керниган, Ритчи или Томпсон, -- что в самые продуктивные свои дни, ему удавалось набрать пару тысяч строк кода.
И я не вижу никаких проблем набрать приведённое выше слепым набором. Даже более того, отсутствие пайпа избавляет от необходимости тянуться мизинцем левой руки куда-то далеко. Меня в find вечно напрягает то, что стартовый путь для поиска надо ставить до шаблона имени искомых файлов -- это понятно логически, но моя голова уже лет двадцать не может привыкнуть, потому что она думает мысль в обратном порядке: сначала "что" ищем, и только затем "где" ищем. Но это ведь будет раздражать вне зависимости от зрячести набора, так?

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

66. "(offtopic) мировоззренческое" –2 +/–

Сообщение от Michael Shigorin (ok), 03-Янв-20, 22:25

> Я переключился на борьбу с догмами, но и это мне надоело последнее время.
Луговский похожую дорожку проходил несколько раньше -- возможно, Вам бы оказалось интересно его найти да потолковать.  В его случае критически важным оказалось то, что он по-научному честен, насколько могу судить.

Ответить | Правка | Наверх | Cообщить модератору

86. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (86), 05-Янв-20, 16:28

Что есть ГНУ? Хорошую вещь ГНУ не назовут.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Выпуск утилиты GNU grep 3.4"	–8 +/–
Сообщение от BSD_Cucks_BTFO (?), 03-Янв-20, 10:05
Не нужно. ripgrep в 3.5 быстрее.
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "Выпуск утилиты GNU grep 3.4"	+10 +/–
	Сообщение от A.Stahl (ok), 03-Янв-20, 10:13
	А нам некуда спешить: тише едешь -- дальше будешь. А то грепают тута аки самолёты, нет чтобы остановиться и оглянуться куда летят-то. Кто-то ведь в пропасть летит. Но нет, летят, бегут куда-то. Зачем? Эх-х-х...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Выпуск утилиты GNU grep 3.4"	–1 +/–
	Сообщение от qqq (??), 03-Янв-20, 14:39
	иногда надо по-быстрому в многометровом логе найти нужное событие...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от 12345 (??), 03-Янв-20, 14:56
	многогиговом
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Выпуск утилиты GNU grep 3.4"	+2 +/–
	Сообщение от Michael Shigorin (ok), 03-Янв-20, 19:50
	> многогиговом Такие логи есть смысл сваливать в более специальные системы с индексированием, если поиск по ним является сколь-нибудь частой задачей. Например, вот человек несколько лет назад описал свою "замену Splunk на открытом софте": http://edgeofsanity.net/article/2012/06/17/central-logging-w...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	55. "Выпуск утилиты GNU grep 3.4"	–1 +/–
	Сообщение от IdeaFix (ok), 03-Янв-20, 20:52
	Имхо, пока ничего лучше sawmill не придумали для этой задачи, но... даже sawmill как-то не может эффективно в 16-32 треда и в сотню гигов памяти. Да, логи скорее малотеровые, чем многогиговые....
	Ответить \| Правка \| Наверх \| Cообщить модератору


	72. "Выпуск утилиты GNU grep 3.4"	+1 +/–
	Сообщение от GentooBoy (ok), 04-Янв-20, 00:32
	Главное настроить систему логирования на системе логирования, что бы когда она будет падать определить причину.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	75. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Anonymouss (?), 04-Янв-20, 00:55
	дороговато для грепа
	Ответить \| Правка \| К родителю #55 \| Наверх \| Cообщить модератору


	20. "Выпуск утилиты GNU grep 3.4"	+5 +/–
	Сообщение от Аноним (20), 03-Янв-20, 14:49
	Тогда греп надо на электрон переписать.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	87. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от супернуб (?), 06-Янв-20, 09:22
	не успеюют - быстрее сделают grepd
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Выпуск утилиты GNU grep 3.4"	+1 +/–
	Сообщение от Wilem (?), 03-Янв-20, 12:08
	Да, rg и fd - должны быть на каждой системе. Fd кстати сделан поверх либы walkdir, которую тоже BurntSushi написал. Великий человек.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	12. "Выпуск утилиты GNU grep 3.4"	+5 +/–
	Сообщение от bircoph (ok), 03-Янв-20, 14:08
	riggrep написан на rust, не учитывает особенности unicode (u(ss)->ß) и не портируем на некоторые современные и безопасные архитектуры.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	16. "Выпуск утилиты GNU grep 3.4"	–1 +/–
	Сообщение от Wilem (?), 03-Янв-20, 14:25
	Объясни по-подробнее про особенности utf8, что не так?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Аноним (21), 03-Янв-20, 14:51
	Я не знаю, что он имел в виду, но венда тоже не умеет в utf8. По-моему я даже в бсод ронял 10 и кучу програм в ней всего 1 символом (совершенно валидным в линуксе), не знаю, починили ли с тех пор. Так что особенности есть.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Выпуск утилиты GNU grep 3.4"	–1 +/–
	Сообщение от Wilem (?), 03-Янв-20, 15:02
	https://snipboard.io/5E9mRX.jpg
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Выпуск утилиты GNU grep 3.4"	–1 +/–
	Сообщение от Аноним (21), 03-Янв-20, 15:28
	> https://snipboard.io/5E9mRX.jpg Там свой особенный утф8, мало общего имеющий со стандартом. Дело не в том, что он не отображается, а в том, что юникод в венде будет совершенно свой (и если использовать его, проблемы будут у других систем), а часть символов и вовсе вызовет бсод и инстакраши софта (передаю привет notepad++). В линуксах не крашится.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "Выпуск утилиты GNU grep 3.4"	–1 +/–
	Сообщение от Wilem (?), 03-Янв-20, 15:45
	А что за символы с которыми крешится или которые несовместимы? Прям сейчас бы опробовал на винде и линуксе.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Аноним (21), 03-Янв-20, 16:00
	> А что за символы с которыми крешится или которые несовместимы? Прям сейчас > бы опробовал на винде и линуксе. Я не помню, какие именно, но даже в википедии емнип было написано (в японской [1] так точно). Ну вот к примеру описываемые мной различия у вендоров [2]. [1] https://ja.wikipedia.org/wiki/Unicode [2] https://web.archive.org/web/20110422181018/http://www.ingrid...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	67. "Выпуск утилиты GNU grep 3.4"	–3 +/–
	Сообщение от Аноним (67), 03-Янв-20, 22:33
	UTF-8 не нужен при наличии полноценного юникода. Квест "угадай сколько байтов потянет каждый символ длинной-предлинной строчки если в ней гарантированно не только латиница" сильно на любителя.
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	69. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Аноним (21), 03-Янв-20, 22:57
	> UTF-8 не нужен при наличии полноценного юникода. Квест "угадай сколько байтов потянет > каждый символ длинной-предлинной строчки если в ней гарантированно не только латиница" > сильно на любителя. Полноценный - это какой? UTF-32? Ну да, там есть небольшой запас, чтобы на это забить и считать 4 байта примерно равно 1 символ (и то с оговорками вроде модифицирующих кодпоинтов). Только ведь он жутко неэффективный в части занимаемой памяти, правда?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	70. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Michael Shigorin (ok), 03-Янв-20, 23:09
	> Полноценный - это какой? UTF-32? В винде вроде двухбайтовый UCS2 фигурировал... PS: "полноценный", ага.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	83. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Аноним (83), 04-Янв-20, 23:08
	В UTF-8 в теории символ может до 6 байт весить, это сильно лучше или как?
	Ответить \| Правка \| К родителю #69 \| Наверх \| Cообщить модератору


	84. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Аноним (21), 04-Янв-20, 23:23
	> В UTF-8 в теории символ может до 6 байт весить, это сильно > лучше или как? Очень в теории, текущий лимит 4 байта из соображений совместимости. И всяко лучше utf-16. [1] %) По-моему, на практике 4 довольно редко встречалось и только в китайских текстах. Но это совершенно не важно, случайный доступ с юникодом просто не применяют. [1] https://en.wikipedia.org/wiki/Plane_(Unicode)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Выпуск утилиты GNU grep 3.4"	–2 +/–
	Сообщение от Аноним84701 (ok), 03-Янв-20, 15:28
	> riggrep написан на rust, не учитывает особенности unicode (u(ss)->ß) Угу, то ли дело греп, на который еще не так давно (лет 6 назад) любители вставить "ß" затейливо матюкались из-за принципиальных проблем поиска с умляутами. % echo "THISS"\|grep -ic "ß" 0 % echo "straße"\|grep -ic "ss" 0 % grep --version grep (GNU grep) 3.3
	Ответить \| Правка \| К родителю #12 \| Наверх \| Cообщить модератору


	27. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Wilem (?), 03-Янв-20, 15:42
	В спеке на утф-8 сказано, что Eszett приравнивается к "ss"? Я такого найти не смог, более того на стековерфлоу сами немцы говорят, что с точки зрения языка Eszett не равен "ss", плюс у них вокруг этого переодически правила меняются. Также интересно - какое дело до обработки этого символа юзеру опеннета? Товарищ парсит в консоли немецкие логи?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	36. "Выпуск утилиты GNU grep 3.4"	+4 +/–
	Сообщение от Аноним84701 (ok), 03-Янв-20, 17:29
	> В спеке на утф-8 сказано, что Eszett приравнивается к "ss"? Мне лень смотреть. Ведь это не я писал о том, что ripgrep "не учитывает особенности unicode (u(ss)->ß)". Проще было проверить на практике – grep тоже как-то не очень учитывает (утф-8 используется по умолчанию) > найти не смог, более того на стековерфлоу сами немцы говорят, что с точки зрения языка Eszett не равен "ss", плюс у них вокруг этого переодически правила меняются. Конечно не равен – вы не можете заменить любую двойную "ss" на ß. А вот наоборот - (грубо говоря) всегда. Даже в деловой переписке это не будет чем-то уж слишком "из ряда вон". Но да, стековерфлоу – это конечно авторитет! Куда тем же "Дойче Правописание [Правила]" (§25) до мнения авторитетов 🙄 https://www.rechtschreibrat.com/DOX/rfdr_Regeln_2016_redigie... https://www.duden.de/sprachwissen/rechtschreibregeln/doppel-... > E2: Steht der Buchstabe ß nicht zur Verfügung, so schreibt man ss. In der Schweiz kann man immer ss schreiben. Beispiel: Straße – Strasse > Если нет буквы ß - пишем ss. В Швейцарии вообще можно всегда писать ss вместо ß. . > E3: Bei Schreibung mit Großbuchstaben schreibt man SS. Daneben ist auch die Verwendung des Großbuchstabens ẞ möglich. Beispiel: Straße – STRASSE – STRAẞE. > Для заглавных/прописных букв используется SS. (Если в шрифте присутствует - старая формулировка до ввода "официальной" большой ß) прописная ß, то возможно написание с <большая ß> Кстати, авторитеты не затрагивали проблему поиска в старых документах, где вместо isst, dass, wusste писали ißt, daß, wußte? Небольшая подсказка насчет новых-старых правил: Любителям умляутов (причем, вполне серьезным и уважаемым изданиям газет и журналов) не впервой просто проигнорировать "блидинг-эдж" нововведения, вплоть до их отмены или серьезной переработки ;) Да и благодаря таким "реформам" с отменами - до сих пор вполне нормально воспринимается старое правописание. Ну и матюкались не на то, что ß не заменялось на "ss" при поиске, а на то, что ни ß, ни поиск öäü - вообще не работал толком: http://www.knoppixforum.de/knoppix-forum-deutsch/sonstiges/t... https://forum.ubuntuusers.de/topic/grep-findet-keine-umlaute... https://bbs.archlinux.org/viewtopic.php?id=96082 (длинный список по запросу поисковика "grep umlauts") А если задаться целью - то на грабли c умляутами до сих пор и на утф8 наткнуться можно: https://stackoverflow.com/questions/24962147/grep-and-utf-8-... https://stackoverflow.com/questions/49535221/how-to-grep-uml... > Также интересно - какое дело до обработки этого символа юзеру опеннета? Товарищ парсит в консоли немецкие логи? Мне лично - никакого. Но критиковать ripgrep, тактично умалчивая о той же проблеме в grep -- немножечко отдает двойными стандартами.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Michael Shigorin (ok), 03-Янв-20, 19:44
	> Небольшая подсказка насчет новых-старых правил: Ну вот, опять восхищаюсь Вашими тщательностью и кругозором :-) Был бы рад знакомству. PS: а может, в 2020 опеннетовку проведём хотя бы в Москве или Питере?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	52. "Выпуск утилиты GNU grep 3.4"	+1 +/–
	Сообщение от Аноним84701 (ok), 03-Янв-20, 20:08
	>> Небольшая подсказка насчет новых-старых правил: > Ну вот, опять восхищаюсь Вашими тщательностью и кругозором :-) Просто приходится много общаться с немецкоязычными, поэтому и разбираться с вывертами правописания приходилось особо тщательно – так что это не кругозор, а скорее "сопутствующие спец. знания" ;-) > Был бы рад знакомству. > PS: а может, в 2020 опеннетовку проведём хотя бы в Москве или Питере? Лет 6-7 назад вполне. Сейчас, к сожалению, то семья, то здоровье "теребят".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	85. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Anonymoustus (ok), 05-Янв-20, 11:46
	> переодически Период, а не переод.
	Ответить \| Правка \| К родителю #27 \| Наверх \| Cообщить модератору


	13. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Аноним (13), 03-Янв-20, 14:18
	У него беда с докой. Он понимает опции -e, -f, -l, -n, -s, -q, -v?
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору