LINUX.ORG.RU

GNU Grep 2.20: исправление ошибок

 ,


0

1

Вскоре вслед за выходом версии 2.19 выходит новая, в которой исправлено несколько ошибок:

  • grep --max-count=N FILE ранее не прекращало чтение файла после N-го совпадения, вывод был корректным, однако чтение файла продложалось (и могло продолжаться бесконечно), эта ошибка появилась в версии 2.19;
  • Такие команды, как echo aa | grep -E 'a(b$|c$)' могли ошибочно напечатать ввод, как строку, соответствующую паттерну.

Кроме того, эта версия содержит изменение в поведении:

  • grep --exclude-dir='FOO/' теперь действительно исключает директорию FOO, ранее слэш в конце lделал опцию бесполезной.

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

★★★★★

Проверено: Shaman007 ()
Последнее исправление: cetjs2 (всего исправлений: 3)
Ответ на: комментарий от NeverLoved

Да, минорщина, с одной стороны. А с другой — для меня это довольно важная новость, которая показывает состояние проекта, как он развивается.

anarquista ★★★★★
() автор топика

Вендекапец.

anonymous
()

Что ж, по крайней мере найденные ошибки они исправляют.

nt_crasher ★★★
()

Как бы его заставить работать побыстрее? Многопоточность какую-нибудь прикрутить, например..

xtraeft ★★☆☆
()

прямо реклама!

«Минорщина, Вендекапец, решето, Шаман» - LOR, 60 лет неизменных традиций!

:)

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

Многопоточность имеет смысл, если доступ к диску намного шустрее обработки каждого файла (SSD RAID) и если память можно отхапать гига так на два.
А многопоточно шуршать по обычному НЖМД - только зря дрючить головки.

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

Многопоточность имеет смысл, если доступ к диску намного шустрее обработки каждого файла (SSD RAID) и если память можно отхапать гига так на два.

Предположим, доступ к диску (или файловый кеш) и память позволяют это сделать. Решения я все равно не нашел. Вот прямо сейчас грепаю файл на 200 миллионов строк fgrep-ом - минут 5-10 занимает :(

xtraeft ★★☆☆
()
Последнее исправление: xtraeft (всего исправлений: 1)
Ответ на: комментарий от xtraeft

rust-grep же есть! Там многопоточность заявлена!

serhey
()
Ответ на: комментарий от xtraeft

а пробовал silversearcher?

на некоторых файлах/директориях работает быстрее грепа, на некоторых наоборот. ну и, заметил, на разных выражениях разница тоже иногда заметна

actionless ★★★★★
()
Последнее исправление: actionless (всего исправлений: 2)
Ответ на: комментарий от actionless

Не пробовал. Твое описание что-то не воодушевляет :)

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

Как бы его заставить работать побыстрее? Многопоточность какую-нибудь прикрутить, например..

Купи SSD...

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

Многопоточность имеет смысл, если доступ к диску намного шустрее обработки каждого файла (SSD RAID) и если память можно отхапать гига так на два. А многопоточно шуршать по обычному НЖМД - только зря дрючить головки.

Если вы работаете с каким‐то проектом (т.е. разрабатываете ПО), то при наличии сколько‐нибудь большого не занятого объёма памяти все исходные файлы будут находится в кэше в памяти. Особенно если у вас нет таких энтерпрайзных штук как выделенный build сервер. Причина простая: исходные файлы требуются компилятору при сборке, редактору/IDE для чтения и записи в процессе редактирования, плагину автодополнения/IDE для того, чтобы знать, что дополнять, grep’у или аналогу для поиска, VCS для проверки на наличие изменений и т.д. Короче их будут дёргать так часто, что они намертво пропишутся в кэше. Хотя, конечно, многие будут дёргать по большей части только stat.

В чём проблема с «отхапыванием памяти» я не понимаю. Сейчас 2 ГиБ — это уже нехорошо для чего‐то, кроме телефонов и планшетов, а на машинах разработчиков 16 и более ГиБ — норма.

ZyX
()

grep --exclude-dir='FOO/' теперь действительно исключает директорию FOO, ранее слэш в конце lделал опцию бесполезной.

делать, видимо, больше нехрен..

Deleted
()
Последнее исправление: Zangezi (всего исправлений: 1)
Ответ на: комментарий от segfault

Рабочие файлы и так на ssd лежат. Как это отменит однопоточность грепа? Он нагружает только 1 физическое ядро, затык совсем не в чтении с диска.

xtraeft ★★☆☆
()
Последнее исправление: xtraeft (всего исправлений: 1)
Ответ на: комментарий от xtraeft

Интересно, что это за комп такой, где стоит SSD, но проц настолько слаб, что не успевает в один поток пропускать через себя то, что читается с диска?

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

Я уверен, что у меня процессор молотит на 100% одного ядра, а остальные простаивают. Что с ssd, что из озу.
grep, если ты не знал, еще и регулярки умеет, так что многопоточность тут совсем не помешает.

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