Ну чего там с языками программирования и технологиями?

Серверный каспер это умеет. Шифровальщики нацелены на юзерские документы, вот каспер проверяет, что туда пишется, он для каждого файла поток создаёт (типа невидимого прицепа к файлу) и/или пишет в свою бд инфу по файлу. И если файл/часть вдруг сильно поменялся или есть сигнатура, похожая на aes шифрование, то файлу будет запрет на запись и прилетит алерт.

 

Понял. Спасибо за инфо.

 

штой-та меня тоже на программирование под старость лет потянуло.
на rust написал пару утилит, на go пропатчил проект snid и продал ехе-шник.
поругался немного с местными разработчиками на предмет "какого хера создатели современных языков не делают нормальную стандартную библиотеку для основных повседневных хотелок" .
разузнал у других местных разработчиков, что нахер не нужны "стандартные либы на все случаи жизни", а надо свой фреймворк под свои "все случаи жизни" писать.

куда ж девать багаж знаний, полученный изпод bash?
смотреть не могу на все эти "многострочные программистские потуги" типа "обход файлов, прочитать файл, найти в нём подстроку, вывести её на экран если нашлась, перейти к следующему файлу, обработать вручную ошибочки".
дайте мне функцию grep("regexp", "path")!

 

Напиши сам и пользуйся.

Дело не хитрое.

 

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

причём из года в год, с каждым релизом, разработчики языка обновляют свою stdlib, и в сети уже МОРЕ имплементаций "того, что нужно но чего нет в стдлибе", и на них в репозиториях - сотни тысяч "звёздочек" оценок и количества скачиваний - но нет, хер, "напиши сам и пользуйся"...
блять, заговор какой-то

https://www.google.com/search?q=gol...35i39j69i64.4540j0j7&sourceid=chrome&ie=UTF-8
только на первой странице с десяток тех, кто "напиши сам и пользуйся".
и ведь наверняка разрабам языка всё это показывали и предлагали...

речь ведь о СТАНДАРТНЫХ УТИЛИТАХ LINUX'а - coreutils и всяких там grep, sed, awk и прочая.
т.е. разработчики сами ведь живут в линухе и, по-идее, сами должны постоянно пользоваться этими утилитами.
и ведь наверняка они даже написали их себе! но, сцуки, зажали

 

Фишка в том что они не общеупотребимые.
Мне аналог твоего grep("regexp", "path") в работе был до сих пор не был нужен ни разу.

Такие вещи можно назвать "библиотеки инструментов под свои задачи".

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

 

и так 100500 раз - каждый профессионал, для каждого себя.

да какие там "разные вкусы"? man grep - всё стандартно.

Смысл - ровно тот, какой и в повседневной работе в командной строке bash.
Если чел привык искать слово или регексп в файлах, то он и мыслит этими же категориями. И писЯ (или пишА?) бинарный код для своей утилитки, которая должна будет искать в логах данную подстроку - он изначально будет желать именно реализацию функции grep(..., ..., ...). Конечно, можно его устоявшийся подход сломать об коленку и сказать "не выёбывайся и пиши вот так", но это - моветон какой-то. Насилие над привычками

Кстати, посмотрел некоторые реализации (что в результатах того поиска) - уёбищно. Кое-где навороченно, но скорее всего будет медленно или падать будет на больших файлах.

? И вот нафига мне своё время тратить на то, что уже В ПРИНЦИПЕ написано, и скорее всего переписано на go/rust другими, и даже в правильной реализации, но изза отсутствия рекламы (а вернее, изза нежелания некоторых) оно не вставлено в стдлиб ...

 

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

 

Понапишут этих своих фреймворков, а потом не работает нихрена, потому как надо фреймворк перелопачивать, и вот тут поменялось и вон там вот надо бы другую либу попользовать. цуки. Стандарные либы хороший вариант, ИМХО, ессно.

 

То что нужно всем - там есть.
А твое grep("regexp", "path") - это явно не то что нужно не то что "всем", а и даже большинству.

Для ленивых есть куча разных реализаций grep на гитхабе.

 

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

 

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

картинка "Шварц_произносящий_капыталызм.жпг"

А так - разработчики пишут языки исходя из того, что им видится полезным/важным, а не из того, что кажется одному конкретному потенциальному пользователю.

 

Рустам, спасибо что откликнулся

Я беден, и потому одним из желаемых результатов реализации своих задумок вижу в т.ч. и неприличный по обычным меркам достаток
Посему (лично для меня) ни о каком денежном (сколько-нибудь) существенном вливании в инструменты - речи быть не может.
Не, 100-200 баксов не вопрос - заплатил бы для спокойствия Но кто ж захочет за такую мелочь "сделать приятное" - раз, и на гитхабах - ну столько полезного и правильно-реализованного ЗАБЕСПЛАТНО, что даже и 200 баксов - жаль
Проблема - увидеть запихнутое с минимальным изменением этого "правильного и полезного" в стдлиб нового языка, пусть не в премьеру, а через 10 лет... (кстати, пример с улучшением С++ показателен).

В том-то и дело, что среди третьих поставщиков МОЖНО НАЙТИ , если постараться, либы на все случаи жизни.
Но получается потом использование нового языка - сильно НЕКРАСИВЫМ.
Это как библиотека Nokogiri в Ruby - попробуй догадаться про что она?
Или вот я напишу свою либу и назову её mcgru-lib, и будет народ вставлять в начало файла: import github.com/mcgru/mcgru-lib ... Красиво, правда же? (нет)

В том-то и дело, что НЕ ОДНОМУ конкретному потенциальному пользователю а ДЕСЯТКАМ ТЫСЯЧ (судя по кол-вам скачивания с crates.io[rust] и по звёздочкам оценок на github.com[go]).

Вот именно, что "разработчики вставляют в стдлиб" только то, что ИМ кажется полезным и важным.
Да, кое что они вставили в стдлиб и "подсмотренное у других", или с стдлибе есть "то, для чего предназначался сам язык" - для упрощения программирования в какой-то области.
Но почему б не стать ещё более гибкими и добавить с стдлиб (даже не сам язык модифицировать!) то, что нужно ОЧЕНЬ МНОГИМ?

 

Напиши свой язык, и вставляй в него все что тебе нравится.

 

не о языке речь. а о стдлибе к нему, что идёт искаропки.

 

Это неразрывные вещи.

 

давно ли тебе в своих программках нужно было копировать файлы?
а легонечко править xml-ки?

 

На C# все это делал через Linq в несколько строк буквально
Нужно было из каталога с вложениями подкаталогами извлекать xml находить нужные строки и тасовать рандомно и загружать в свою структуру данных.
Несколько строк кода буквально, и очень читабельно.
Позже появилась мысль распаралелить с помощью того же linq. Но объемы были не те чтобы усложнять, а выигрыш если бы и был то мизерный.

 

Не вижу проблем с этим.

 

Сколько строк в твоей программе (даже с использованием известных тебе библиотечек) займёт редактирование xml-файла , заменяя там значение (по xpath) /qwe/wer[@dfg='fgh']/@sfd на "zxc" ?
(со сведением всевозможных ошибок только к "мог/несмог заменить")

в баше это делается в одну строку:
xmlstarlet ed -L -u "//qwe/wer[@dfg='fgh']/@sfd" -v "zxc" file.xml

есть в твоей либе такая функция?
edit_xml_file_by_xpath("file.xml", "//qwe/wer[@dfg='fgh']/@sfd", "zxc" )