LINUX.ORG.RU

GNU Grep 2.15

 ,


0

2

26 октября вышла новая версия программы GNU Grep — 2.15. Выпуск связан главным образом с исправлением ошибок. Прошло 62 недели, за это время 9 человек сделали 57 коммитов.

Были исправлены следующие ошибки:

  • \s и \S неправильно работали с пробельными символами длиной в несколько байт. Например, выражение \s неправильно работало с неразрывным пробелом. Например, вот: printf '\xc2\xa0' | LC_ALL=ru_RU.UTF-8 grep '\s'. Ошибка появилась в версии 2.6;
  • grep -i могла вызывать ошибку сегментирования в системах, использующих wchar_t, основанный на кодировке UTF-16 (например, Cygwin). Ошибка возникала, когда нужно было перевести в нижний регистр входную строку, содержащую определенную 4-байтовую последовательность (ошибка присутствовала с версии 2.6, но проявляться в виде ошибки сегментирования начала только в версии 2.13;
  • grep -E могла завершиться с ошибкой сегментирования при обработе регулярных выражений вида '([^.]*[M]){1,2}', где M — многобайтовый символ. Ошибка появилась в версии 2.6, пропала в версиях 2.7 и 2.8. Все версии, начиная с 2.9, работают с ошибкой;
  • grep -F могла попадать в бесконечный цикл, когда искомая строка содержит некорректную в текущей локали последовательность байтов:
  • grep -P могла работать неправильно с многобайтовыми символами.

Новые улучшения:

  • grep -P теперь использует jit-компиляцию, что значительно ускоряет работу. Это реализовано совершенно прозрачно для пользователя, не нужно устанавливать никаких флагов и т.п. Эта возможность включается на этапе компиляции, если обнаружена подходящая версия библиотеки pcre.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: unfo (всего исправлений: 1)

всегда удивляюсь этим новостям о пофикшеных багах в coreutils итп, никогда в таком софте ошибок не наблюдал

unt1tled ★★★★
()
Ответ на: комментарий от Deleted

Назови-ка мне язык и человека, его использующего, которые всегда без багов создают. Очень интересно посмотреть на супермена и его, так сказать, инструмент.

вопрос поставлен неправильно — инструментом должна являться (в данном случае) библиотека

т.е. если бы они юзали скажем uregex_ (или RegexMatcher) из libicu, то такого рода багрепорты были бы не в багзилле грепа, а багзилле libicu — а скорее, их бы не было вообще, т.к. ibm вылизала libicu за свои деньги

предположим, однако, что uregex не выдает необходимой функциональности целиком — тогда разумным было бы

1. ограничить юникодную функциональность греп тем, что выдает uregex

2. участвовать в развитии uregex

но я сильно сомневаюсь, что человек, заболевший GовноProgrammingLicence головного мозга, начнет вдруг участвовать в развитии библиотеки с bsd-like лицензией

так что имеем что имеем: упоровшихся разрабов и детские баги

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от redgremlin

Грепу скоро 30ик стукнет, причём, очевидно, в первых версиях никаким уникодом ещё не пахло, это дописывали и переписывали совсем другие люди в совсем другое время, так что немудрено, что остались редконаходимые артефакты 'char=byte' кода.

ммм... если бы матчингом занималась исключительно специализированная библиотека вроде libicu, каким образом такие артефакты могли бы выжить?

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от D_Lans

Видимо качественное существование опенсорса возможно только при коммунизме. Опенсорс и капитализм плохо совместимы.

вполне совместимы, когда компания типа ibm выкладывает бесплатно библиотеку типа libicu, или ea выкладывает eastl, или...

что характерно, все это под bsd-like license

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

На самом деле всё еще смешнее, потому что с регвырами умеет работать glibc и делает это отдельным от grep'а способом. Поэтому вот тут в grep баг вроде как пофиксили, но в glibc баг остался, поэтому, например, sed будет работать с ошибкой:

printf '\xc2\xa0' | LC_ALL=ru_RU.UTF-8 sed -n '/\s/p'
anarquista ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

но я сильно сомневаюсь, что человек, заболевший GовноProgrammingLicence головного мозга, начнет вдруг участвовать в развитии библиотеки с bsd-like лицензией

Правильно! И дальше так веди себя - рассуждая обязательно навязывай свои сраные оценки. Так мы сразу сразу видим какой типаж пишет, и можем не тратить свое время на чтение быдлячьей отрыжки.

ps: Подобное поведение вполне ожидаемо - у bsd-фанов очень недалекое, и часто просто быдлячье мышление.

anonymous
()
Ответ на: комментарий от D_Lans

Видимо качественное существование опенсорса возможно только при коммунизме. Опенсорс и капитализм плохо совместимы.

А коммунизм и люди - несовместимы вовсе. Итого ты заявил что качественный опенсорс и люди несовместимы - очевидно ложное утверждение

black7
()
Ответ на: комментарий от D_Lans

Или это проблемы языка?

Криворукие самоуверенные обезъяны - проблема любого ЯП

black7
()
Ответ на: комментарий от NaN

Назови-ка мне язык и человека, его использующего, которые всегда без багов создают. Очень интересно посмотреть на супермена и его, так сказать, инструмент.

Кнут.

Супермен и инструмент в одном лице? Или ты только инструмент имел ввиду?

black7
()
Ответ на: комментарий от www_linux_org_ru

что человек, заболевший GовноProgrammingLicence головного мозга, начнет вдруг участвовать в развитии библиотеки с bsd-like лицензией
так что имеем что имеем: упоровшихся разрабов и детские баги

Гггг, держи пять - давно тут бздунов фанатиков так не опускали

black7
()
Ответ на: комментарий от anarquista

Поэтому вот тут в grep баг вроде как пофиксили, но в glibc баг остался, поэтому, например, sed будет работать с ошибкой

мощно, да

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от anonymous

анонимус не нашел ничего лучшего, как перевести разговор на обсуждение личностей... ну что же:

и можем не тратить свое время на чтение

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

Подобное поведение вполне ожидаемо - у bsd-фанов очень недалекое, и часто просто быдлячье мышление.

ну и кто тут из нас двоих «навязывает сраные оценки»?

ты высказался категорично, а я, обрати внимание, аккуратно сказал «я сильно сомневаюсь»

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

анонимус не нашел ничего лучшего, как перевести разговор на обсуждение личностей... ну что же:

Я копнул туда откуда вонь - от твоей личности. Быдлячий шаблон «перевести разговор на обсуждение личностей» выкинь ибо протухло. Ты не святой.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

ты высказался категорично, а я, обрати внимание, аккуратно сказал «я сильно сомневаюсь»

И что? Я больше скажу: ты обычный лох, который когда не может вывезти разговор отмалчивается. Не веришь?

Смотри: Сегодня языку Perl исполнилось 25 лет!

Анонимус не забывает..

anonymous
()
Ответ на: комментарий от KennyMinigun

Достаточно на sed, велосипеды не нужны.

anonymous
()
Ответ на: комментарий от D_Lans

Программа поиска подстроки в строке по-вашему сложная?

Да. Но grep это не программа поиска подстроки в строке.

fmap
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.