LINUX.ORG.RU

GNU grep 2.13

 ,


0

1

4 июля Джим Мейеринг сообщил о выходе очередной версии GNU grep. За десять недель разработки 4 программиста сделали 24 коммита, отмечает он.

Исправлено две ошибки появившиеся в версии 2.6:

  • grep -i в многобайтовых локалях теперь правильно выводит строки, содержащие буквы, чьё представление в верхнем и нижнем регистре занимает различное число байтов. Это, например, «и-с-точкой» в турецком языке. Прежние версии GNU grep могли либо пропустить часть строки, либо, наоборот, вывести мусор;
  • опции --include и --exclude теперь снова можно совмещать друг с другом. Так, «grep --include='*.[ch]' --exclude='system.h' PATTERN *» читает все файлы *.c и *.h, кроме system.h.

Новые особенности:

  • grep без опции -z теперь считает разреженные файлы бинарными, если можно легко определить, что файл действительно разреженный.

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

★★★★★

Проверено: catap ()

Ответ на: комментарий от A-234

нифига подобного же: когда в смс попадается хотя бы один не ascii символ, производится замена кодировки на ucs-2, которая хранит по два байта на любой символ, поэтому к-во символов в такой смс тоже фиксировано, а не плавает в зависимости от пробелов

Хм. а сдвиг вы не считаете за усложнение?

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

нифига подобного же: когда в смс попадается хотя бы один не ascii символ, производится замена кодировки на ucs-2, которая хранит по два байта на любой символ, поэтому к-во символов в такой смс тоже фиксировано, а не плавает в зависимости от пробелов

Ужас какой, я был о них лучшего мнения.

Хм. а сдвиг вы не считаете за усложнение?

Пример замены «grep» на «sed» намекает на то что такой сдвиг потребуется вне зависимости от того какую кодировку вы используете.

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

Замену, редактирование, поиск не затрудняет.

Замена одного символа на другой с другой длинной приводит к изменению общего размера и сдвигу хвоста.

поиск подразумевает сравнение. Одно дело, пробежать for по фиксированным границам в n потоков, а другое, вытаскивать букву за буквой, сравнивать длинну и затем значение.

замена одного символа на другой может привести к сдвигу хвоста.

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

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

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

UTF-16

Он хуже UTF32 во всех случаях, кроме совместимости с вендой, жабой, тиклем и подобными вещами.

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

Сравнивать утф-8 строки как раз можно безо всяких головняков как обычные.

это если у тебя есть две отдельные строки, которые надо сравнить.

А при замене надо найти и сравнивать вхождения в строку.

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

А выделение памяти под строку в n-символов

а зачем выделять строку именно на n символов?

замену символов в строке

не затрудняет.

Вот что затрудняется, так это регистронезависимое сравнение. Только в этом случае приходится учитывать, что данный набор байт это реальная буква, а не просто набор байт.

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

поиск подразумевает сравнение. Одно дело, пробежать for по фиксированным границам в n потоков, а другое, вытаскивать букву за буквой

кто тебя заставляет сравнивать именно буквы, а не байты? Это не нужно, кроме случая, когда ы==Ы.

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

Я нифига не понял. По-вашему, неправильные глаголы редко используются?

Наоборот. Они используются чаще. Пример - глагол «to be».

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

Замена одного символа на другой с другой длинной приводит к изменению общего размера и сдвигу хвоста.

Кому такое может понадобиться? Заменяют одну подстроку на другую и сдвиг при этом почти всегда требуется.

поиск подразумевает сравнение. Одно дело, пробежать for по фиксированным границам в n потоков, а другое, вытаскивать букву за буквой, сравнивать длинну и затем значение.

Да какая разница, ваши потоки все будут стартовать с начала строки, которое от кодировки не зависит.

Поэтому еще раз, замена «grep» на «sed» уже приводит к сдвигам и кодировка тут ни при чем. Поиск подстроки для utf-8 ничем не отличается от поиска в ASCII.

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

Ваш мир однозначно удивительнее моего.

A-234 ★★★★★ ()
Ответ на: комментарий от Binary

ойвэй, я только сейчас понял, что изначально заявил UTF-16 вместо 32. Не буду больше по выходным участвовать в технических дискуссиях :)

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

тем, что все символы занимают равное число байт?

И давно это так? Еще вчера количество байт в utf-16 кодировке было различным для различных символов. Может у Вас какой-то другой unicode, где не нужны surrogate pairs и прочие прелести?

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

ойвэй, я только сейчас понял, что изначально заявил UTF-16 вместо 32. Не буду больше по выходным участвовать в технических дискуссиях :)

Поправка принята :)

С другой стороны, у UTF-32 другая проблема - жрет очень много места, какой бы текст ним не кодировался.

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

С другой стороны, у UTF-32 другая проблема - жрет очень много места, какой бы текст ним не кодировался.

Потому UTF-8, если применена к месту, прекрасная кодировка.

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

На Китайские народы нужно смотреть не свысока, а со снисхождением.

В цитатник лора!

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

Потому UTF-8, если применена к месту, прекрасная кодировка.

Проблема в том,ч то этих мест не так много. utf-8 является простейшим архиватором текстовой строки и имеет все достоинства и недостатки архиватора.

Достоинства - относительно высокая степень сжатия информации, минимальный контроль целостности. Недостатки - невозможность точно ставить лимиты на объем и необходимость распаковки и упаковки строк в приложениях.

Есть только один весомый плюс - совместимость с ascii. Только поэтому мы и сней и имеем сейчас дело.

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

Так любой вариант будет с недостатками, кроме того, что передавать по 4 байта на каждый символ. Ну и кому оно надо?

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

Так любой вариант будет с недостатками, кроме того, что передавать по 4 байта на каждый символ. Ну и кому оно надо?

если говорить о сжатии, то никто не мешал гзиповать строк или использовать гугловский быстрый архиватор.

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

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