The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск утилиты GNU grep 3.5

28.09.2020 20:39

Представлен выпуск утилиты для организации поиска данных в текстовых файлах - GNU Grep 3.5. В новой версии возвращено старое поведение опции "--files-without-match" (-L), которое в выпуске grep 3.2 было изменено для единообразия с утилитой git-grep. Если в grep 3.2 поиск стал считаться успешным при упоминании обрабатываемого файла в списке, то сейчас возвращено поведение, при котором успех поиска зависит не от наличия файла в списке, а от совпадения искомой строки.

Переработано сообщение, выводимое при выявлении совпадений в бинарных файлах. Сообщение теперь имеет вид "grep: FOO: binary file matches" и выводится в stderr для избежания пересечений с обычным выводом (например, команда 'grep PATTERN FILE | wc' раньше неверно подсчитывала число совпадений из-за вывода предупреждения в стандартный поток). В stderr аналогичным образом перенаправлены и сообщения "grep: FOO: warning: recursive directory loop" и "grep: FOO: input file is also the output".

  1. Главная ссылка к новости (https://www.mail-archive.com/i...)
  2. OpenNews: Выпуск утилиты GNU grep 3.4
  3. OpenNews: Доступен GNU Autoconf 2.69b для тестирования изменений, потенциально нарушающих совместимость
  4. OpenNews: Выпуск текстового редактора GNU nano 5.0
  5. OpenNews: Выпуск Mcron 1.2, реализации cron от проекта GNU
  6. OpenNews: Обновление GnuPG 2.2.23 с устранением критической уязвимости
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/53796-grep
Ключевые слова: grep
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (36) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, A.Stahl (ok), 20:44, 28/09/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Кто же так делает-то? Нужно: "Представлен новый выпуск Linux дистрибутива reGrep (кодовое имя: Грёпаный Файл), на базе которого развивается утилита для организации поиска данных в текстовых файлах."

    Берите пример с разработчиков ДЕ и весёленьких обоев. У всех есть свои дистрибутивы, а у грепа нет :(

     
     
  • 2.8, Dzen Python (ok), 21:07, 28/09/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Фу. Снова неправильно. Держи исправленную новость:
    "Представлен выпуск electron-утилиты для организации поиска данных в текстовых файлах - YAMLGrep 64.1. В новой версии возвращено старая модель сборки с npm-модулем FilesWithoutMatch (вызываемого при конфигурировании строкой в общем json "files-without-match = true"), который в выпуске grep 3.2 было изменено для единообразия с утилитой git-grep, а затем возвращен в выпуске 3.5. Если в
    ранних версиях и без явного включения опции поиск считался успешным при упоминании  обрабатываемого файла в списке, то сейчас возвращено поведение, при котором успех поиска зависит не от наличия файла в списке, а от совпадения искомой строки..."
     
     
  • 3.11, Аноним (11), 23:07, 28/09/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Фу. Снова неправильно. Держи исправленную новость:
    "Мы пересали grep на раст, так предыдущая версия сегфолтилась и текла, но теперь мы пьем смузи, а наш поиск встал крепким и шелковистым..."
     
     
  • 4.12, Аноним (11), 23:08, 28/09/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > встал крепким

    Блин, прям по Фрейду опечатка. Хотел сказал: "стал крепким и шелковистым". Как у ТВ-Парк.

     
     
  • 5.35, Аноним84701 (ok), 13:49, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Блин, прям по Фрейду опечатка. Хотел сказал: "стал крепким и шелковистым". Как у ТВ-Парк.

    Учитывая что, вроде бы, всегда было "... станут мягкими и шелковистыми", там "по Фрейду" не одна опечатка, кхе ;-)

     
  • 4.17, Fracta1L (ok), 07:51, 29/09/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ripgrep уже есть и он быстрее сабжа, лол
     
  • 2.20, Аноним (20), 12:13, 29/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вангую дистрибутив для ls
     

  • 1.2, б.б. (?), 20:46, 28/09/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    зачем ещё нужен grep, если microsoft открыли код собачки из windows xp? кто теперь в здравом уме после этого будет grep-ом пользоваться?
     
     
  • 2.4, Дерьмократ (?), 20:47, 28/09/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Сразу видно, что ты кол не смотрел. Собачка под капотом использует греп
     
     
  • 3.6, IRASoldier_registered (ok), 20:59, 28/09/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    find / findstr таки не grep
     
     
  • 4.33, Аноним (33), 18:38, 30/09/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    echo findstr %1 %2 %3 %4 %5 > %systemroot%\grep.cmd
    грепайте на здоровье
     
     
  • 5.34, IRASoldier_registered (ok), 22:18, 30/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, Кэп. Без твоей мудрости никто бы не знал, как сделать батник для Винды, назвать его грепом и потом заявить, что в Винде есть греп.


     

  • 1.3, Аноним (3), 20:47, 28/09/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    А мне вот больше по душе такая нумерация версий. Утилите 10 миллионов лет, а она 3.5, а не 82.0.1.398.
     
     
  • 2.5, A.Stahl (ok), 20:58, 28/09/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Ну так и релизится она раз в миллион лет.
     
  • 2.10, Аноним (10), 21:54, 28/09/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > нумерация версий
    > по душе

    Выбирать нумерацию версий "по душе" и прочим "душевным" смузи-критериям -- первый признак хипстера. Версии следует выбирать исходя из целей:

    - там, где важно обозначать обратную (не)совместимость и давать какие-то гарантии на уровне API — выбираем semver;
    - там, где клиентам не интересен никакой API (или его вообще как такового нет), и релизы вообще привязаны к дате, и приложение включает в себя буквально сотни библиотек, и все это дело развивается слишком стремительно — выбираем тупой ежемесячный бамп или указываем время непосредственно в версии (Chromium 85, IntelliJ IDEA 2020.2.2).

    Для библиотек и утилит берем semver x.y.z, для конечных приложений для широких масс — YYYY.QQ.

     
     
  • 3.13, Аноним (11), 23:10, 28/09/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Chromium 85

    Так тут тоже привязыывают к версии API/ABI движка V8. В данном случае это V8 v8.5, и каждая верия V8 ломает совместимость.

     
     
  • 4.19, Q2W (?), 12:04, 29/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А хромиум на V8 v8.10 какую версию будет иметь?
     
  • 3.15, Аноним (15), 23:51, 28/09/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Может и удобно пользователям, но неудобно для разработки. Для разработки удобно увеличивать y для каждой "готовой" версии со значительными изменениями. Final public release назвать 1.0.0 и менять x только если большая часть кода переписана и всё слишком уж несовместимо. Это и пользователям удобно.
     
     
  • 4.23, Ordu (ok), 19:52, 29/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Кто тебе сказал, что это неудобно для разработки? Для разработки, как раз, совершенно фиолетово. Для разработчика софтины, все эти версии -- не более чем tag'и для некоторых из коммитов. Что именно в этих tag'ах написано совершенно не важно, до тех пор, пока эти имена легко сравнивать по критерию "раньше/позже". Дело в том, что ежели ты занят разработкой, если ты в git заглядываешь каждый день или хотя бы раз в неделю, если ты просматриваешь новые коммиты, следишь за багами, обсуждениями и прочими вещами, то как бы там не назывались релизы, ты будешь их помнить и будешь в них ориентироваться. semver -- это для человека не вовлечённого в разработку, которому тем не менее хочется ориентироваться в версиях. То есть не для разработчика.

    Semver может быть удобнее для мейнтейнера дистрибутива, который разгребает dll hell, да и то только в тех случаях, которые подпадают под "там, где важно обозначать обратную (не)совместимость и давать какие-то гарантии на уровне API".

     
     
  • 5.24, Аноним (15), 19:57, 29/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это только для своего кода, никто не будет разгребать все зависимости и уж тем более следить за всеми коммитами, если те тебя вообще не касаются -- разрабатывают и пусть разрабатывают, тебя это начнёт волновать только когда выйдет новая версия с изменениями, которые тебе придётся учитывать.
     
     
  • 6.25, Ordu (ok), 20:32, 29/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Это только для своего кода, никто не будет разгребать все зависимости и
    > уж тем более следить за всеми коммитами, если те тебя вообще
    > не касаются

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

    Изменения внешнего API тебе при этом не то чтоб совсем неинтересны, но они интересны не больше, чем изменения внутренних. А может и меньше.

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

    Не. Во-первых, эти изменения тебя начнут волновать ещё до того, как выйдет новая версия. Ещё до того, как появится новый тег для версии тебе придётся учитывать изменения API. Во-вторых, semver отражает только изменения внешнего API, а тебе будут интересны изменения внутренних API. Если ты разработчик какой-нибудь библиотки, то вполне вероятна ситуация, когда внешние API этой библиотеки тебя вообще не трогают: ты может быть пилишь какой-нибудь там код взаимодействия в /proc, и твоя задача вынуть оттуда нужную информацию и сделать её доступной для другого кода библиотеки, то есть выставить наружу API, которым библиотека будет пользоваться для извлечения информации из /proc. Этот API запросто может не выставляться наружу из библиотеки, и таким образом _никакие_ изменения внешних API тебя не затронут напрямую. А вот изменения внутренние запросто могут затронуть.

     
     
  • 7.26, Аноним (15), 21:09, 29/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Видимо, мы подразумеваем разной сложности продукты -- в реальной жизни у тебя вполне вероятно не будет даже доступа к исходникам, и тебя никак не может волновать внеочередная перестановка кроватей (тем более, планирующаяся -- это не твоя задача!). Я всё ещё не вижу как код разрабатываемый соседним отделом касается тебя, ты ведь даже не будешь копаться в кишках, да и платят тебе вовсе не за это.

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

     
     
  • 8.27, Ordu (ok), 22:12, 29/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если я не копаюсь в кишках кода, то я не являюсь его разработчиком В лучшем слу... большой текст свёрнут, показать
     
     
  • 9.28, Аноним (15), 23:22, 29/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Пользователь кода, но разработчик одного и того же продукта Индикация изменений... текст свёрнут, показать
     
     
  • 10.29, Ordu (ok), 23:35, 29/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так Я выше изложил тебе выдержанную и здравую позицию Если ты не хочешь понима... текст свёрнут, показать
     
     
  • 11.30, Аноним (15), 23:45, 29/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, там сплошное хамство и индульгирование с твоей стороны Ты этого, конечно, ... текст свёрнут, показать
     
     
  • 12.31, Ordu (ok), 23:47, 29/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Приведи пример хамства я работаю над тем, чтобы снизить количества хамства с мо... текст свёрнут, показать
     
  • 8.36, anonymizer (?), 17:40, 03/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Чутье не подводит Должно быть планируемая ... текст свёрнут, показать
     
     
  • 9.37, Аноним (15), 19:04, 03/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Но ведь это совсем другое слово Смысл первого в том, что оно само, а во втором ... текст свёрнут, показать
     
     
  • 10.38, anonymizer (?), 20:31, 03/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Кровати сами переставляются ... текст свёрнут, показать
     
     
  • 11.39, Аноним (15), 20:36, 04/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, это то, что я сказал, да По аналогии с назревающая , видимо ... текст свёрнут, показать
     
  • 3.32, Zlo (??), 11:12, 30/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Почему вспоминают Chromium c его жалкой 85 версией, и никто не вспоминает нвидию с 456.55
     

  • 1.7, OpenEcho (?), 20:59, 28/09/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >в выпуске grep 3.2 было изменено для единообразия с утилитой git-grep

    Т.е. git теперь стал первичен ? не git под grep а наоборот... :)

     
     
  • 2.18, Аноним (18), 10:01, 29/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я тебе больше скажу, я patch-файлы только в git-формате использую. Потому что они при накладывании поверх репозитория превращаются в коммиты. А дебианы всякие пусть свой quilt используют.
     

  • 1.14, Аноним (14), 23:38, 28/09/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    А чем оно лучше grep из bsd?
     
     
  • 2.16, Аноним (11), 23:51, 28/09/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Тем, что не из BSD.
     

  • 1.22, Аноним (22), 14:14, 29/09/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >В новой версии возвращено старое поведение опции "--files-without-match" (-L), которое в выпуске grep 3.2 было изменено для единообразия с утилитой git-grep. Если в grep 3.2 поиск стал считаться успешным при упоминании обрабатываемого файла в списке, то сейчас возвращено поведение, при котором успех поиска зависит не от наличия файла в списке, а от совпадения искомой строки.

    Игорь всплыл

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру