Представлен (http://www.mail-archive.com/info-gnu@gnu.org/msg02306.html) выпуск утилиты для организации поиска данных в текстовых файлах - GNU Grep 3.1 (http://www.gnu.org/software/grep/), в котором примерно в 7 раз увеличена производительность обработки масок '[0-9]' при использовании многобайтовых локалей.
Кроме того, опция "-m" (прекратить чтение файла после N совпадений) отныне не влияет на вывод дополнительных строк контекста, число которых задаётся опцией "-A" (показать N строк, идущих после совпадения). Например, команда 'grep "^" -m1 -A1' теперь приведёт к выводу двух строк - одного совпадения и следующей за ним строки, а не одной как раньше. На платформе Windows опций "--binary" (-U) теперь включает ввод/вывод в режиме обработки бинарных данных, а опция "--unix-byte-offsets" (-u) игнорируется.URL: http://www.mail-archive.com/info-gnu@gnu.org/msg02306.html
Новость: http://www.opennet.me/opennews/art.shtml?num=46804
Ждем улучшенной версии grepd
не улучшенной, а Правильной, от Великого Нечитателя манов
>увеличена производительностьВот. Молодцы. А ведь сколько есть проектов, которые были завершены и которые стоило лишь оптимизировать да допиливать по мелочам, поддерживая работоспособность в условиях изменяющегося окружения, но нет -- шило в жопе толкает разработчиков на переписывание всего нахрен почти с нуля.
Потому что grep ничем уже не заменишь. Linux без grep что стол без ножки.
Будет хоть 10 крутых замен grep, а пользоваться всё равно будут им же.
Ничего не мешает написать какой-то perg на Rust+Lua с нардами и инкассаторшами. Сказать что он безопасней и хипстеры перебегут за пару недель. Но никто не пишет же. А почему? Потому что проект неспешно и адекватно развивается (да, это камень в огород КДЕ-Гномеров)
> Ничего не мешает написать какой-то perg на RustУже написано: https://github.com/BurntSushi/ripgrep
И уже быстрее Grep.
> Уже написано: https://github.com/BurntSushi/ripgrep
> И уже быстрее Grep.Совместимость?...
Сколько дистрибутивов gnu\linux полностью заменили им GNU grep? А при сборке всех своих пакетов из исходников, например?
0.0 ?....
Ох же ж, мы ж опечалены. Работайте лучше. ...и ещё быстрее!1
> Совместимость?...Отсутствие сомнстимости позволяет использовать более приятный синтаксис. Но да, делает эту штуку малополезной в скриптах.
Таких уже дофига было. Только быстрее оно в определенных случаях: на очень маленьких/больших текстах/шаблонах. А в среднем по скорости и переносимости хуже.
> Таких уже дофига было. Только быстрее оно в определенных случаях: на очень
> маленьких/больших текстах/шаблонах. А в среднем по скорости и переносимости хуже.Победитель по принципу "среднее по больнице" это значит ни в чём не хорош. А ИТ развивается в направлении узкой специализации. Например вместо обсолютно одинаковых по ТТХ mysql/postgres/oracle пришли разные НОСКЛ и унесли 80% рынка. С ЯП так же, появилось множество языков со своей нишей и унесли 95% задач у мощной сишечки.
p.s. Что лучше, прога которая час занимает 2.5ГБ ОЗУ и 1 ядро на 100% или другая, которая ест 8ГБ на 5 секунд? 8))))
а когда этих 8ГБ нет, прога просто падает не выполняя свою задачу
>а когда этих 8ГБ нетgrep сишный через час выпал в OOM на сервере с 96ГБ ОЗУ.
Ну значит очень тупая попытка использования утилиты. Я на 146% уверен что дело в ваших руках :)
Оно - жабист. У них не руки а лапки.
Про мозги я их жалости - даже не буду :)
Сколько всяких хадупов они понаписали ... а потом бац! и разгромная статья от аффтараф и гур как грепами не напрягаясь разобрать то на чём хадуп разрывает на части :)
> p.s. Что лучше, прога которая час занимает 2.5ГБ ОЗУ и 1 ядро
> на 100% или другая, которая ест 8ГБ на 5 секунд? 8))))Что, жаба не только съела память, но и часы остановила?
>the usability of The Silver Searcher (similar to ack) with the raw speed of GNU grepпогодите, у The Silver Searcher (ag) вроде же всё в порядке со скоростью?
>Сказать что он безопасней и хипстеры перебегут за пару недельОбозвал других хипстерами и сразу почуйствовал прилив крутизны?
В первую очередь все эти линуховые сишные утильки архитектурно убогие и тормозные, т.к. написаны во времена "640к хватит всем". Делаем чуть что сложнее банального grep -i blabla и приплыли.
Вот из прямо сейчас очередной факап грепа:
дано два файла с ОГРН (число 13 символов), в одном 4.5m, в другом 800k строчек. Надо сделать третий файл с содержимым f1 которого нет в f2.
grep -v -x -f f2 f1 >f3
съел 2.5ГБ рамы и задумался уже на много минут. Сервак с 12 ядрами, 100ГБ ОЗУ. И чё это грепу дало? В проге нормальной архитектуры это должно делаться за от силы 10 сек, а может и меньше 1.
> grep -v -x -f f2 f1 >f3А за хлебом ты тоже на грузовике ездишь?
man uniq
man comm
> дано два файла с ОГРН (число 13 символов), в одном 4.5m, в другом 800k строчек. Надо сделать третий файл с содержимым f1 которого нет в f2.Так как вы не написали, в каком файле сколько строк, сделал для верности:
% seq 1000000000000 1000005000000|shuf>f1
% seq 1000003000000 1000009000000|shuf>f2
head -3 f1 f2 && wc -l f1 f2
==> f1 <==
1000001476233
1000004330833
1000001025162==> f2 <==
1000006027753
1000007334577
1000007732550
5000001 f1
6000001 f2
11000002 total
Т.е. 5м и 6м. Cойдет?
> grep -v -x -f f2 f1 >f3
> съел 2.5ГБ рамы и задумался уже на много минут. Сервак с 12 ядрами, 100ГБ ОЗУ. И чё это грепу дало?Cервака под рукой нема, есть старенький ноут с i5 (первым еще) и "слегка" поменьше рамы.
НО! Есть чит, называется "man grep"!
> -F, --fixed-strings
> Interpret PATTERN as a list of fixed strings, separated by newlines, any of which is to be matched
> fgrep is the same as ‘grep -F’.
% time grep -v -x -F -f f1 f2|wc -l
4000000
grep -v -x -F -f f1 f2 16,20s user 0,90s system 99% cpu 17,117 total #1GB ОЗУ
wc -l 0,56s user 0,04s system 3% cpu 17,023 total% time grep -v -x -F -f f2 f1|wc -l
3000000
grep -v -x -F -f f2 f1 18,39s user 1,05s system 99% cpu 19,470 total # 1.2GB ОЗУ
wc -l 0,43s user 0,03s system 2% cpu 19,357 total# убираем -х, который тут нужен как рыбе зонтик
% time grep -v -c -F -f f2 f1
3000000
grep -v -c -F -f f2 f1 15,42s user 0,57s system 99% cpu 16,015 total # ~700MB озу% time awk 'NR==FNR {a[$0];next} !($0 in a){print $0}' f2 f1|wc -l
3000000
awk 'NR==FNR {a[$0];next} !($0 in a){print $0}' f2 f1 11,76s user 0,65s system 99% cpu 12,411 total
wc -l 0,40s user 0,05s system 3% cpu 12,334 total #~1ГБ
> Вот из прямо сейчас очередной факап грепа:А может, проблема в прокладке между спинкой стула и монитором? :)
> Надо сделать третий файл с содержимым f1 которого нет в f2.Ты grep с join перепутал, у жабистов это бывает.
>> Надо сделать третий файл с содержимым f1 которого нет в f2.
> Ты grep с join перепутал, у жабистов это бывает.
Important: FILE1 and FILE2 must be sorted on the join fields.Мы тут стараемся, seq-и shuf[fle]-им, а вы хотите сказать надо было sort-ить?! Неслыханно. >>?<<
sed лучше 8)
Седрик лучше.
Ну тогда уже perl, который заменяет собой сразу grep, sed, awk, tr, неинтерактивный шелл и кучу других утилит. Другое дело, что для простейших задач команда с grep получается короче, чем однострочник на perl.
А еще лучше питон
print( {e for e in open("f1", "r")} - {e for e in open("f2", "r")} )
А я умею на чистом SHELL заменять awk '{print $5}' например:gigi()
{
read LIST
NO="$1"
II=' '
TORBA=1
while [ "$NO" != "$TORBA" ]
do
LIST="${LIST#*$II}"
let TORBA++
done
echo "${LIST%%$II*}"
}
echo "1a 2b 3c 4d 5e 6x 7y 8z" | gigi 5
#!/bin/bash
gigi() {
local A
read -a A
echo "${A[$1-1]}"
}
echo "1a 2b 3c 4d 5e 6x 7y 8z" | gigi 5
Токо оно в SHELL не работает.
> Токо оно в SHELL не работает.С-с-слабак!
@@ -1,7 +1,9 @@//Вариант с рекурсией в активной разработке... Ждите коммитов.
-#!/bin/bash
+#!/bin/sh
+bibi() {
+ eval "echo \$$SHI"
+}
gigi() {
- local A
- read -a A
- echo "${A[$1-1]}"
+ local SHI="$1"
+ bibi `head -1`
}
echo "1a 2b 3c 4d 5e 6x 7y 8z" | gigi 5
$ python -c 'print( {e for e in open("f1", "r")} - {e for e in open("f2", "r")} ) '
set(['13\n', '12\n', '45\n'])И что этот типа однострочник должен был полезного делать, кроме вывода содержимого перфого файла в извращенном виде? Зачем был нужен второй файл?
Update: Понял, он читает в память оба файла и выдает строки из первого, которых нет во втором. То бишь соответствует примерно такому однострочнику на perl:
$ perl -e 'push @ARGV,"f2"; %h=map {$_=>1} <>;push @ARGV,"f1"; print for grep ! $h{$_},<>'
Только последний выводит в более удобном виде и читает в память только второй файл, что делает его более пригодным для практического использования.
> Ну тогда уже perl, который заменяет собой сразу grep, sed, awk, tr,"Ноги, крылья... Хвост!" B-)
$ time awk 'ARGIND==1{x[$0]=1}ARGIND==2&&!($0 in x)' <(seq 1000000000000 1000005000000|shuf) <(seq 1000003000000 1000009000000|shuf) |wc -l
4000000real 0m17.431s
user 0m10.712s
sys 0m0.232s
$ _> задач команда с grep получается короче, чем однострочник на perl.
$ time grep -vFf <(seq 1000000000000 1000005000000|shuf) <(seq 1000003000000 1000009000000|shuf) |wc -l
4000000real 0m55.920s
user 0m50.092s
sys 0m0.860s
$ _//с s|time|/usr/bin/time -f %e\\t%U\\t%M|,
16.88 10.36 323256
4000000и
58.31 49.62 1779584
4000000соответственно.
%M Максимальный резидентный размер процесса в течении его выполнения в килобайтах.
Ты процитировал фразы о perl, но при этом зачем-то сравнил grep с awk. Давай сравним с perl и для чистоты эксперимента сделаем на одном и том же наборе данных:
$ seq 1000000000000 1000005000000|shuf >f1
$ seq 1000003000000 1000009000000|shuf >f2$ /usr/bin/time -f %e\\t%U\\t%M grep -vFf f1 f2 | wc -l
64.12 62.94 1781788
4000000
$ /usr/bin/time -f %e\\t%U\\t%M perl -e 'push @ARGV,"f1"; %h=map {$_=>1} <>;push @ARGV,"f2"; print for grep ! $h{$_},<>' | wc -l
11.71 10.85 1441532
4000000Ну как бы perl однозначно в плюсе по потреблению ресурсов и это на крайне выгодной для grep задаче.
С awk сравнить на своей машине не могу, так как при знании perl нет никакого смысла изучать глубоко синтаксис для всех вариантов awk, а твой вариант у меня просто не работает:
$ awk 'ARGIND==1{x[$0]=1}ARGIND==2&&!($0 in x)' <(seq 1000000000000 1000005000000|shuf) <(seq 1000003000000 1000009000000|shuf) |wc -l
0
$ awk 'ARGIND==1{x[$0]=1}ARGIND==2&&!($0 in x)' f1 f2 | wc -l
0
$ awk -W version
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennancompiled limits:
max NF 32767
sprintf buffer 1020
> Ну как бы perl однозначно в плюсе по потреблению ресурсов и это
> на крайне выгодной для grep задаче.Странно. grep (2.27) у меня отрабатывает чуть, а gawk (4.1.4) и вовсе в полтора раза быстрее перла (5.24).
Питонятина для полноты:
$ python -c 'h=set(open("f1"));import sys;sys.stdout.writelines(l for l in open("f2") if l not in h)'
Третий питон по скорости cравним с перлом. Второй быстрее третьего, в два раза.> на крайне выгодной для grep задаче.
Крайне выгодно для grep было бы искать эти 5 миллионов паттернов в файле с более свободным форматом.
> Странно. grep (2.27) у меня отрабатывает чуть, а gawk (4.1.4) и вовсе в полтора раза быстрее перла (5.24).А что тут странного? Собственно сэта новость о новой версии, в которой определенные операции ускорили в 9 раз. Между 2.20(у меня) и 2.27(у вас) вполне могли оптимизировать поиск фиксированных строк.
> Третий питон по скорости cравним с перлом. Второй быстрее третьего, в два раза.
У меня тоже вариант с вторым питоном отрабатывает в два раза быстрее, чем с perl
> Крайне выгодно для grep было бы искать эти 5 миллионов паттернов в файле с более свободным форматом.
Ну было бы в perl и python поиск подстроки вместо сравнения строк, принципиально бы ничего не изменилось. А вот если бы стояла задача поиска с более интересными критериями, например в данном случае убрать из второго файла все строки, где числа между 1000000000000 и 1000005000000, то варианты perl/python выполнились бы быстрее и потребовали минимум памяти.
Но вообще я никогда не выбирал perl вместо grep или awk из-за скорости. Просто удобней выучить один раз его, чем синтаксис и ключи кучи разных утилит, которые к тому же будут по разному работать в зависимости от версии и реализации(awk может предоставляться gawk, а может mawk). А однострочник на perl у меня сработает одинаково, что на древней centos 5, что на последней ubuntu.
> Ты процитировал фразы о perl, но при этом зачем-то сравнил grep сНу, при не знании перл, я предпочёл про него не писать...
> $ /usr/bin/time -f %e\\t%U\\t%M grep -vFf f1 f2 | wc -l
> 64.12 62.94 1781788
> $ /usr/bin/time -f %e\\t%U\\t%M perl -e 'push @ARGV,"f1"; %h=map {$_=>1} <>;push
>11.71 >10.85 1441532
> Ну как бы perl однозначно в плюсе по потреблению ресурсов и это
> на крайне выгодной для grep задаче.
> С awk сравнить на своей машине не могу, так как при знании...ровно, как и ты про GNU awk.
#>>>16.88 10.36 323,256> perl нет никакого смысла изучать глубоко синтаксис для всех вариантов awk,
Ну, победил, молодец.
А чего с файлами-то? Одной строкой ваш перл не умеет или у тебя и bash "не завезли"?
/usr/bin/time -f %e\\t%U\\t%M <ваше заклининие для Арг1 и Арг2 вставить здесь> <(seq 1000000000000 1000005000000|shuf) <(seq 1000003000000 1000009000000|shuf) |wc -l
Сим приглашаю и питонистов померяться -- одной строкой, по шаблону выше^^^. GNU bash обязателен. На одной машине прогоните с GNU grep, GNU awk -- для сравнения же, да.
Желающие с agrep, bsdgrep также welkomen.
.
.
.
Хотя бесссмысленно это всё. Криворукого джависта утёрли и ладно, не писать же на Си вымученный образчик со sparse битовыми полями, чтобы накрутить пузомерку, првильно?
-
-
-
>Одной строкой ваш перл не умеет или у тебя и bash "не завезли"?Поленился чел просто, но я "дожал":
#!/bin/bash
awk -V | head -1
time awk 'ARGIND==1{x[$0]=1}ARGIND==2&&!($0 in x)' <(seq 1000000000000 1000005000000|shuf) <(seq 1000003000000 1000009000000|shuf) |wc -lgrep -V | head -1
time grep -vFf <(seq 1000000000000 1000005000000|shuf) <(seq 1000003000000 1000009000000|shuf) |wc -lperl -V | head -1
time perl -e 'push @ARGV,"'<(seq 1000000000000 1000005000000|shuf)'"; %h=map {$_=>1} <>;push @ARGV,"'<(seq 1000003000000 1000009000000|shuf)'"; print for grep ! $h{$_},<>' | wc -lИ на моём восьми-головом сионисте :) (X5482s) оно выдаёт так (+\- - ломы же в сингл грузиться):
$ ./testrun.sh
GNU Awk 4.1.4, API: 1.1 (GNU MPFR 3.1.5, GNU MP 6.1.2)
4000000real 0m12.221s
user 0m10.784s
sys 0m0.572s
grep (GNU grep) 2.27
4000000real 0m13.560s
user 0m11.476s
sys 0m0.464s
Summary of my perl5 (revision 5 version 24 subversion 1) configuration:
4000000real 0m17.468s
user 0m14.912s
sys 0m1.632s
>Сим приглашаю и питонистов померяться
>Желающие с agrep, bsdgrep также welkomen.
>Хотя бесссмысленно это всё.В жизни как известно - вообще со смыслом напряжёнка :) А так ... всё лучше чем шЫряться или в горькую нырять ... так что Ок!
>>Сим приглашаю и питонистов померятьсяpython -V | head -1
time python - <<EOF <(seq 1000000000000 1000005000000|shuf) <(seq 1000003000000 1000009000000|shuf) |wc -l
import sys
d = {}
with open(sys.argv[1]) as f1:
for line in f1:
d[line.rstrip("\n")]=1
with open(sys.argv[2]) as f2:
for line in f2:
if line.rstrip("\n") not in d : print line.rstrip("\n")
EOFPython 2.7.13
4000000real 0m11.104s
user 0m9.736s
sys 0m0.516s
> Python 2.7.13
> 4000000
> real 0m11.104s
> user 0m9.736s
> sys 0m0.516sPython 2.7.13
4000000real 0m20,490s
user 0m16,934s
sys 0m0,570s
> d[line.rstrip("\n")]=1Убираем вездесущий rstrip и получаем ускорение раза в полтора на ровном месте:
> for line in f1:
> d[line]=1real 0m13,029s
user 0m9,299s
sys 0m0,527sИли заменяем на однострочник:
% time python -c 'import sys;h=set(open(sys.argv[1]));sys.stdout.writelines(l for l in open(sys.argv[2]) if l not in h)' <(seq 1000000000000 1000005000000|shuf) <(seq 1000003000000 1000009000000|shuf) |wc -lreal 0m10,557s
user 0m7,168s
sys 0m0,442s
##>> > $ /usr/bin/time -f %e\\t%U\\t%M
>>Одной строкой ваш перл не умеет или у тебя и bash "не завезли"?
> Поленился чел просто, но я "дожал":Спасибо...
> #!/bin/bash
> awk -V | head -1
> time awk '..., но "я эе просил 400, а здесь 403 !?".
Время и _память_ мерять, в смысле.
> А чего с файлами-то? Одной строкой ваш перл не умеет или у
> тебя и bash "не завезли"?Очевидно же:
>> и для чистоты эксперимента сделаем на одном и том же наборе данныхКО
Не КО - а ко-ко-ко! :)
Потому как наступишь в гов^W - на то что скорость дисков у людей отличается на порядки, а памяти - максимум в разы.
> Не КО - а ко-ко-ко! :)
> Потому как наступишь в гов^W - на то что скорость дисков у
> людей отличается на порядки, а памяти - максимум в разы.tmpfs? Не, не слышал.
> perl нет никакого смысла изучать глубоко синтаксис для всех вариантов awk,
> $ awk -W version
> mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennanmawk 'FNR==1{a++}a==1{x[$0]=1}a==2&&!x[$0]'
с gawk-ом тоже работает. и с gawk --posix.
А чего они никак less не догонят по версиям? Поднапрячься нужно парням!
Чем GNU grep лучше BSD grep?
> Чем GNU grep лучше BSD grep?Поциент, почему вы думаете, что ваш BSD grep хуже, чем GNU grep? Вас это беспокоит? Расскажите нам больше.
Чем армяне!
Ничем не лучше и не хуже:$ uname -a
FreeBSD freebsd110-amd64 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
$ grep --version
grep (GNU grep) 2.5.1-FreeBSDCopyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Ну то есть похуже, конечно, тем, что версия допотопная.
> Ну то есть похуже, конечно, тем, что версия допотопная.Ох уж эти эксперты опеннета:
% bsdgrep --version
bsdgrep (BSD grep) 2.5.1-FreeBSD
git log --pretty=format:"%h%x09%an%x09%ad%x09%s" /usr/src/usr.bin/grep
77e420848ad gjb Mon May 22 15:51:17 2017 +0000 MFC r313955 (emaste): bsdgrep: document ignored option -u
521ece6e40b dim Tue Aug 9 19:20:53 2016 +0000 MFC r303676:
92100036c84 ngie Wed May 4 23:20:53 2016 +0000 Merge ^/user/ngie/release-pkg-fix-tests to unbreak how test files are installed after r298107
086e6f562ff gjb Mon Mar 14 18:54:29 2016 +0000 MFH
5d2092c908f ian Sun Mar 13 14:53:12 2016 +0000 Fix a bug in bsdgrep that caused the program to hang in a tight loop for some combinations of command line options and search patterns. The code was examining regexec flags looking for a regcomp flag value. The fix is to look in the struct field where the decoded regcomp flag was stored when the regex was compiled.
1c7e318a9a3 gjb Thu Mar 10 21:16:01 2016 +0000 MFH
aab40fdc3dd bdrewery Wed Mar 9 22:46:01 2016 +0000 DIRDEPS_BUILD: Connect MK_TESTS.
#>>>$ grep --version
#>>> grep (GNU grep) 2.5.1-FreeBSD
> Ох уж эти эксперты опеннета:
> % bsdgrep --version
> bsdgrep (BSD grep) 2.5.1-FreeBSDВот зачем ты так?! Изя же запутался! Фу таким быть.
> % bsdgrep --versionНу и на фига он там, если им всё равно никто кроме пары маргиналов не пользуется?
К тому же$ ldd /usr/bin/bsdgrep | grep gnu
libgnuregex.so.5 => /usr/lib/libgnuregex.so.5 (0x800e82000)И это неспроста, ибо фряшная реализация регулярок с0сёт.
> К тому же
> $ ldd /usr/bin/bsdgrep | grep gnu
> libgnuregex.so.5 => /usr/lib/libgnuregex.so.5 (0x800e82000)
> И это неспроста,Конечно неспроста, правда не обязательно по причине озвученных фантазий анонимных знатоков.
man src.conf
WITHOUT_GNU_GREP_COMPAT
Set this option to omit the gnu extensions to grep from being
included in BSD grep
more /usr/src/usr.bin/grep/Makefile
.if ${MK_GNU_GREP_COMPAT} != "no"
CFLAGS+= -I${DESTDIR}/usr/include/gnu
LIBADD+= gnuregex
.endif
> ибо фряшная реализация регулярок с0сёт.Предпочитаю гнутый греп из портов, а не замороженное это-самое-мамонта.
> gnu extensions to grepДело даже не в гнутых расширениях, без них можно жить. Но то, что BSD-POSIX регулярки почему-то считают пустое (под)выражение синтаксической ошибкой люто бесит.
В релизе GNU grep. (Твой вывод говорит о том, что ты не забумываешься о перекомпиляции FreeBSD и о переходе на BSD grep, который включается опцией WITH_BSD_GREP=true в /etc/src.conf).
> В релизе GNU grep.Ой, и https://wiki.freebsd.org/GPLinBase правда.
Соболезнования. Как вас Эппл-то -- во имя Всепобеждающего Пермиссива -- истязает. Бедненькие!
---Век грядущий, век 22-ой, успокоит меня, сударыня?!
..."Ждём FreeBSD 10+" Team. Основатель.http://www.opennet.me/openforum/vsluhforumID3/68588.html#53&...//Семь лет ждал он!
http://www.opennet.me/openforum/vsluhforumID3/108834.html#24
http://www.opennet.me/openforum/vsluhforumID3/111284.html#97
Тем что менее распространен и местами не совместим.
> Чем GNU grep лучше BSD grep?Тем же, чем homo sapiens лучше изеня.
>> Чем GNU grep лучше BSD grep?
> Тем же, чем homo sapiens лучше изеня.Невероятно жгёшь.
> Ничего не мешает написать какой-то perg на Rust+Lua с нардами и инкассаторшами. Сказать что он безопасней и хипстеры перебегут за пару недель. Но никто не пишет же. А почему?вроде пару лет назад была мания все переписывать на go, там уже маразм доходил до переписывания ls на go. Но вроде уже наигрались и забросили
Сейчас стали шутить в стиле: "Мне теперь с Go на Rust это переписывать, да?" Я совсем не эксперт, но привычка писать на Go, как мне кажется, появилась после удачных волн маркетинга (у гугла с этим проблем не было никогда, на мой взгляд). Сейчас весь этот "накал страстей" явно спадает
Маркетинг удачный, да. Теперь мульярды на ём рубят.
> На платформе WindowsЗачем у них же там есть свой, как они любят выражаться, лучший powershell пусть на нем изворачиваются.
Ты шеллы с околошелловой шайкой-братией не путай.
> Ты шеллы с околошелловой шайкой-братией не путай.В винде нет композиции "других" инструментов, как coreutils-ов "около" шела.
Поэтому "у них" каждый раз вижуял бейсик получается.
git.exe без diff.exe не работает. вы, конечно, можете рассказать линусу, что ему срочно надо переписать всё на powershell, но результат предсказуем.
>> На платформе Windows
> Зачем у них же там есть свой, как они любят выражаться, лучший powershell пусть на нем изворачиваются.Да, чего только свои собственные, "неудаляемые", алиасы для curl/wget стоят. Зато ООП и молодежность во все поля.
https://github.com/PowerShell/PowerShell/pull/1901
> initialsession: remove curl and wget aliases
> They block use of the commonly used command line tools without providing even an attempt to offer the same functionality. They serve no purpose for PowerShell users but cause confusion and problems to existing curl and wget usersJason Shirk, Software engineer on @PowerShell:
> Your change would only affect Windows PowerShell (the version of PowerShell that ships in Windows). Those aliases have existed for multiple releases, so removing them would be a breaking change.
> We are rejecting this PR as it introduces "Unacceptable Changes", see our breaking change contract.
>