The OpenNET Project / Index page

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



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

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

Подробнее: https://www.opennet.me/opennews/art.shtml?num=53796

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

Оглавление

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


1. "Выпуск утилиты GNU grep 3.5"  +5 +/
Сообщение от A.Stahl (ok), 28-Сен-20, 20:44 
Кто же так делает-то? Нужно: "Представлен новый выпуск Linux дистрибутива reGrep (кодовое имя: Грёпаный Файл), на базе которого развивается утилита для организации поиска данных в текстовых файлах."

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

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

8. "Выпуск утилиты GNU grep 3.5"  +5 +/
Сообщение от Dzen Python (ok), 28-Сен-20, 21:07 
Фу. Снова неправильно. Держи исправленную новость:
"Представлен выпуск electron-утилиты для организации поиска данных в текстовых файлах - YAMLGrep 64.1. В новой версии возвращено старая модель сборки с npm-модулем FilesWithoutMatch (вызываемого при конфигурировании строкой в общем json "files-without-match = true"), который в выпуске grep 3.2 было изменено для единообразия с утилитой git-grep, а затем возвращен в выпуске 3.5. Если в
ранних версиях и без явного включения опции поиск считался успешным при упоминании  обрабатываемого файла в списке, то сейчас возвращено поведение, при котором успех поиска зависит не от наличия файла в списке, а от совпадения искомой строки..."
Ответить | Правка | Наверх | Cообщить модератору

11. "Выпуск утилиты GNU grep 3.5"  –2 +/
Сообщение от Аноним (11), 28-Сен-20, 23:07 
Фу. Снова неправильно. Держи исправленную новость:
"Мы пересали grep на раст, так предыдущая версия сегфолтилась и текла, но теперь мы пьем смузи, а наш поиск встал крепким и шелковистым..."
Ответить | Правка | Наверх | Cообщить модератору

12. "Выпуск утилиты GNU grep 3.5"  +5 +/
Сообщение от Аноним (11), 28-Сен-20, 23:08 
> встал крепким

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

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

35. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Аноним84701 (ok), 01-Окт-20, 13:49 
> Блин, прям по Фрейду опечатка. Хотел сказал: "стал крепким и шелковистым". Как у ТВ-Парк.

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

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

17. "Выпуск утилиты GNU grep 3.5"  –1 +/
Сообщение от Fracta1L (ok), 29-Сен-20, 07:51 
ripgrep уже есть и он быстрее сабжа, лол
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

20. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Аноним (20), 29-Сен-20, 12:13 
Вангую дистрибутив для ls
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Выпуск утилиты GNU grep 3.5"  –3 +/
Сообщение от б.б. (?), 28-Сен-20, 20:46 
зачем ещё нужен grep, если microsoft открыли код собачки из windows xp? кто теперь в здравом уме после этого будет grep-ом пользоваться?
Ответить | Правка | Наверх | Cообщить модератору

4. "Выпуск утилиты GNU grep 3.5"  –4 +/
Сообщение от Дерьмократ (?), 28-Сен-20, 20:47 
Сразу видно, что ты кол не смотрел. Собачка под капотом использует греп
Ответить | Правка | Наверх | Cообщить модератору

6. "Выпуск утилиты GNU grep 3.5"  –2 +/
Сообщение от IRASoldier_registered (ok), 28-Сен-20, 20:59 
find / findstr таки не grep
Ответить | Правка | Наверх | Cообщить модератору

33. "Выпуск утилиты GNU grep 3.5"  –1 +/
Сообщение от Аноним (33), 30-Сен-20, 18:38 
echo findstr %1 %2 %3 %4 %5 > %systemroot%\grep.cmd
грепайте на здоровье
Ответить | Правка | Наверх | Cообщить модератору

34. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от IRASoldier_registered (ok), 30-Сен-20, 22:18 
Спасибо, Кэп. Без твоей мудрости никто бы не знал, как сделать батник для Винды, назвать его грепом и потом заявить, что в Винде есть греп.


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

3. "Выпуск утилиты GNU grep 3.5"  +7 +/
Сообщение от Аноним (3), 28-Сен-20, 20:47 
А мне вот больше по душе такая нумерация версий. Утилите 10 миллионов лет, а она 3.5, а не 82.0.1.398.
Ответить | Правка | Наверх | Cообщить модератору

5. "Выпуск утилиты GNU grep 3.5"  +5 +/
Сообщение от A.Stahl (ok), 28-Сен-20, 20:58 
Ну так и релизится она раз в миллион лет.
Ответить | Правка | Наверх | Cообщить модератору

10. "Выпуск утилиты GNU grep 3.5"  +4 +/
Сообщение от Аноним (10), 28-Сен-20, 21:54 
> нумерация версий
> по душе

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

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

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

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

13. "Выпуск утилиты GNU grep 3.5"  +1 +/
Сообщение от Аноним (11), 28-Сен-20, 23:10 
> Chromium 85

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

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

19. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Q2W (?), 29-Сен-20, 12:04 
А хромиум на V8 v8.10 какую версию будет иметь?
Ответить | Правка | Наверх | Cообщить модератору

15. "Выпуск утилиты GNU grep 3.5"  +2 +/
Сообщение от Аноним (15), 28-Сен-20, 23:51 
Может и удобно пользователям, но неудобно для разработки. Для разработки удобно увеличивать y для каждой "готовой" версии со значительными изменениями. Final public release назвать 1.0.0 и менять x только если большая часть кода переписана и всё слишком уж несовместимо. Это и пользователям удобно.
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

23. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Ordu (ok), 29-Сен-20, 19:52 
Кто тебе сказал, что это неудобно для разработки? Для разработки, как раз, совершенно фиолетово. Для разработчика софтины, все эти версии -- не более чем tag'и для некоторых из коммитов. Что именно в этих tag'ах написано совершенно не важно, до тех пор, пока эти имена легко сравнивать по критерию "раньше/позже". Дело в том, что ежели ты занят разработкой, если ты в git заглядываешь каждый день или хотя бы раз в неделю, если ты просматриваешь новые коммиты, следишь за багами, обсуждениями и прочими вещами, то как бы там не назывались релизы, ты будешь их помнить и будешь в них ориентироваться. semver -- это для человека не вовлечённого в разработку, которому тем не менее хочется ориентироваться в версиях. То есть не для разработчика.

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

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

24. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Аноним (15), 29-Сен-20, 19:57 
Это только для своего кода, никто не будет разгребать все зависимости и уж тем более следить за всеми коммитами, если те тебя вообще не касаются -- разрабатывают и пусть разрабатывают, тебя это начнёт волновать только когда выйдет новая версия с изменениями, которые тебе придётся учитывать.
Ответить | Правка | Наверх | Cообщить модератору

25. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Ordu (ok), 29-Сен-20, 20:32 
> Это только для своего кода, никто не будет разгребать все зависимости и
> уж тем более следить за всеми коммитами, если те тебя вообще
> не касаются

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

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

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

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

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

26. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Аноним (15), 29-Сен-20, 21:09 
Видимо, мы подразумеваем разной сложности продукты -- в реальной жизни у тебя вполне вероятно не будет даже доступа к исходникам, и тебя никак не может волновать внеочередная перестановка кроватей (тем более, планирующаяся -- это не твоя задача!). Я всё ещё не вижу как код разрабатываемый соседним отделом касается тебя, ты ведь даже не будешь копаться в кишках, да и платят тебе вовсе не за это.

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

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

27. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Ordu (ok), 29-Сен-20, 22:12 
> Я всё ещё не вижу как код разрабатываемый соседним отделом касается тебя, ты ведь даже не будешь копаться в кишках, да и платят тебе вовсе не за это.

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

> тебя никак не может волновать внеочередная перестановка кроватей (тем более, планирующаяся -- это не твоя задача!).

Давай я приведу какой-нибудь пример, чтобы тебе понятнее было. Допустим, у нас в продукте есть внутренняя библиотека для работы с файлами. Назовём её IOLib. Допустим, мы решили перепилить эту библиотеку, и перепилив её обновить версии с 1.1.5 на 1.2.0. Допустим мы перепилили эту библиотеку. И что, можно уже 1.2.0 релизить? Или может надо подождать, когда остальной код нашего продукта, который пользуется IOLib, будет перепилен под изменения этой IOLib?

Чуешь? Версии 1.2.0 ещё нет, а разработчики уже вовсю работают над ней. То есть отсутствие тега 1.2.0 никак не мешает им работать. И более того, тег 1.2.0 появится только тогда, когда вся работа по изменению внутренних API будет завершена.

Чуешь? Версия 1.2.0 -- это версия для _внешнего_ пользователя кода. Тот пользователь может быть разработчиком, но разработчиком не нашего кода, а какой-то другой пурги о которой мы можем даже не иметь никакого представления. То есть _пользователю_ кода может быть нужен semver, а разработчику кода не нужен semver.

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

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

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

28. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Аноним (15), 29-Сен-20, 23:22 
Пользователь кода, но разработчик одного и того же продукта. Индикация изменений необходима, и это не хэш или комментарий в духе "тут мы начали всё ломать -- не использовать пока не доломаем", и даже не ветка со всеми релевантными изменениями. Никто не побежит подстраиваться по wip изменения -- ещё не известно, останутся они или нет, но все должны бежать подстраиваться под одного разраба всё так неаккуратно переломавшего? В таком случае, всё ещё нужна понятная нумерация, чтобы для каждой версии была хотя бы какая-то оценка стадии перестановки кроватей (хотя лучше вообще этого избежать и мержить только законченные изменения вместо всей этой грязи). Использовать хэши вместо версий (или хотя бы дат) это наркомания, только эгоистичный разраб, работающий в одно лицо, может себе такое позволить.
Ответить | Правка | Наверх | Cообщить модератору

29. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Ordu (ok), 29-Сен-20, 23:35 
Так. Я выше изложил тебе выдержанную и здравую позицию. Если ты не хочешь понимать -- не понимай. Если хочешь натягивать сову на глобус -- натягивай. Если же ты хочешь понять, о чём я тебе тут вещаю, то иди перечитай написанное выше и подумай. Хотя бы пять минут подумай, и только после этого возвращайся с вопросами.
Ответить | Правка | Наверх | Cообщить модератору

30. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Аноним (15), 29-Сен-20, 23:45 
Нет, там сплошное хамство и индульгирование с твоей стороны. Ты этого, конечно, не видишь. Что, впрочем, и не удивительно.
Ответить | Правка | Наверх | Cообщить модератору

31. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Ordu (ok), 29-Сен-20, 23:47 
> Нет, там сплошное хамство и индульгирование с твоей стороны. Ты этого, конечно,
> не видишь. Что, впрочем, и не удивительно.

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

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

36. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от anonymizer (?), 03-Окт-20, 17:40 
> выглядит странно

Чутье не подводит. Должно быть "планируемая".

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

37. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Аноним (15), 03-Окт-20, 19:04 
Но ведь это совсем другое слово? Смысл первого в том, что оно само, а во втором случае уже присутствует третья сторона.
Ответить | Правка | Наверх | Cообщить модератору

38. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от anonymizer (?), 03-Окт-20, 20:31 
Кровати сами переставляются?
Ответить | Правка | Наверх | Cообщить модератору

39. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Аноним (15), 04-Окт-20, 20:36 
Ну, это то, что я сказал, да. По аналогии с "назревающая", видимо.
Ответить | Правка | Наверх | Cообщить модератору

32. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Zlo (??), 30-Сен-20, 11:12 
Почему вспоминают Chromium c его жалкой 85 версией, и никто не вспоминает нвидию с 456.55
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

7. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от OpenEcho (?), 28-Сен-20, 20:59 
>в выпуске grep 3.2 было изменено для единообразия с утилитой git-grep

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

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

18. "Выпуск утилиты GNU grep 3.5"  +/
Сообщение от Аноним (18), 29-Сен-20, 10:01 
Я тебе больше скажу, я patch-файлы только в git-формате использую. Потому что они при накладывании поверх репозитория превращаются в коммиты. А дебианы всякие пусть свой quilt используют.
Ответить | Правка | Наверх | Cообщить модератору

14. "Выпуск утилиты GNU grep 3.5"  –3 +/
Сообщение от Аноним (14), 28-Сен-20, 23:38 
А чем оно лучше grep из bsd?
Ответить | Правка | Наверх | Cообщить модератору

16. "Выпуск утилиты GNU grep 3.5"  +6 +/
Сообщение от Аноним (11), 28-Сен-20, 23:51 
Тем, что не из BSD.
Ответить | Правка | Наверх | Cообщить модератору

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

Игорь всплыл

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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