Серверный каспер это умеет. Шифровальщики нацелены на юзерские документы, вот каспер проверяет, что туда пишется, он для каждого файла поток создаёт (типа невидимого прицепа к файлу) и/или пишет в свою бд инфу по файлу. И если файл/часть вдруг сильно поменялся или есть сигнатура, похожая на 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]). Вот именно, что "разработчики вставляют в стдлиб" только то, что ИМ кажется полезным и важным. Да, кое что они вставили в стдлиб и "подсмотренное у других", или с стдлибе есть "то, для чего предназначался сам язык" - для упрощения программирования в какой-то области. Но почему б не стать ещё более гибкими и добавить с стдлиб (даже не сам язык модифицировать!) то, что нужно ОЧЕНЬ МНОГИМ?
На 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" )