Сергей П

А почему именно через sed?
tail -n +10 << my_file
Вернет все строки файла, начиная с десятой.
Только нельзя писать в тот же файл, откуда читаете, иначе получите путой файл.
Вот можно так:

tail -n +10 my_file > temp_file; mv temp_file my_file

Почитайте Марк Лутц - "Реализуем автоответчик в виде бота, реагирующего только на слова-триггеры" - том 1, 5 издание, 2019 год.
Нет, ну вы серьёзно сейчас?
Учитесь программировать и ваши вопросы отпадут. Можно по книжке указанного выше автора, но название "Изучаем Python".
Неужели вы думаете вам кто-то для нулевого уровня напишет подробное руководство по написанию "бота, реагирующего на слова"? Это тривиальная задача для тех, кто уже научился программировать.

Выглядит так, будто бы вам для решения достаочно тривиального однострочника на питоне, запускаемого в виде кманды py. Опишите более внятно формат входных данных, как именются файлы и в каких структурах каталогов они размещены.
Результат надо в один файл слить?
Общая схема такая:
- итерируемся по фходящим файлам с помощью glob или walk (если файлы в дереве каталогов, а не в одном каталоге).
- преобразуем содержимое файла в словарь: обычно достаточно сплита текста по пробелам и абзацам, потом сплит по "=" и получаем аргумент для конструктора словаря.
- печатаем в stdout f-строку с одстановкой данных из словаря, плученного выше.

Это если я правильно понял ваше сумбурное описание задачи.

UPD. Автор в изначальном вопросе не дал понять. что формат файла бинарный.
Решение на системных утилитах командной стоки будет громоздким и неремонтопригодным в плане поддержки.
Нужно на питоне делать. Если id гарантировано 12 цифр и такая последовательность встречется только в виде id, то можно парсить и регекспами.
Но сдаётся мне не просто вам будет, если не умеете в питон.

Интересно какая была схемотехника обвязки управляющих цепей этой самоделки.
Да, тут уже ответили, что есть заводские решения: https://www.phoenixcontact.com/ru-pc/produkty/pusk...

Вы смутили народ соей странной постановкой задачи.
В реальном мире смысл монеты ка краз в ее неуникальности и взаимной заменяемости с другими такими же. А у вас это не монеты, а, своего рода, токены. И если формулировать так, то станет гораздо понятнее.

У вас определённо должна быть таблица токенов и, если каждй токен кому-то принадлежит, то токен должен ссылаться на текущего владельца.
Вообще тут можно всё сделать очень по-разному в зависимости от того, какие операции и какие отчеты вам нужны чаще, а какие реже, какие агрегации надо делать.
К примеру, можно хранить у каждого токена ссылку на его текущего владельца, а в отдельном журнале историю движения токена в том виде в каком вы предложили.
Фактически это журнал транзакций передачи токенов между пользователями.

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

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

Эти три изменения должны быть в рамках атомарной транзакции. Если что-то пошло не так, то все три действия должны отмениться.

Вам стоит поизучать курс баз данных, чтобы понимать какие неочевидные для новичков проблемы кроются в бизнес логике, когда ваша система постянно осуществляет одновременные переводы между пользователями. Там целый мир и CAP-теорема. Почитайте.

Да, возможны более сложные ситуации, когда вам нужно быстро получать не только баланс пользователя на текущий момент, но и баланс пользователя на любой конкретный момент времени в прошлом.
Очевидно, что вм для этого пришлось бы сделать снимок текущего состояния балансов пользователя, а потом пройтись в обратном порядке по всем его транзакциям в которых он был источником и приемником токенов и обратить все операции над копией его баланса.
Чтобы делать это быстро, то балансы пользователей на момент транзакции можно размещать в жарнале. Это избыточность, но она позволит мгновенно получать баланс любого польщователя на любой момент времени. Для этого нажно лишь найти саму старую транзакцию этого пользователя не позднее заданного времени и там будет нужное число. Этот поиск делается с логарифмической сложность.

Не нужно пизать в БД лишнюю логику и лишние ограничения.
У вас с БД работает какой-то софт, например бэкенд. Там и делайте валидаторы данных. В случае пола раньше можно было 1 и 0 удобно хранить и всё было абсолютно интуитивно и понятно, а русскую букву в качестве индекса держать неудобно и неправильно. Во-первых, она в UTF-8, наверняка, что уже как-то изврат для бинарного поля.
Во-вторых, при локализации проблемы могут быть в логах надо юникодовую экранировку читать, если что... в общем либо международное F\M, либо кодами и 1\0 для мнемонического запоминания очень удобно. Вот угадайте что есть что и почему.=)

Но по нынешним временам за такую бинарность могут и засудить=) Не иначе нужна целая таблица гендеров небинарных с названиями, описаниями и локализацией. Да ещё и меняться она будет со временем, а потом при импортах мапить надо одну таблицу полов на другую=).
Шутки шутками, а 0\1 и тут хорошо лягут. Просто идентификаторы такие будут синтетические.

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

Ответ: на надо валидировать значения такого рода полей на уровне БД. Делайте так, чтобы нельзя было ввести неверно на уровне ввода данных от пользователя, и дополнительно валидируйте в бэкенде.

А в чем проблема?
В БД хранишь нужны результирующий путь. По факту аплоада делаешь таск на распаковку архива. Этот поцесс может оказаться не быстрым и закончиться ошибкой. Таск запускается, а его статус фронтенд запрашивает регулярно через АПИ, или слушает через перманентное подключение по веб-сокету - как уж реализуете. Важно, что распаковка это таск и у него есть статус и прогресс. По факту окончания загрузки помечаете в записи БД где путь, что путь актуален.
Можно не записывать путь пока не закончится распаковка, тогда путь должен записать таск по факту своего успешного завершения.

Ну можно SPA замутить и API на фласке.
Я трогал лифлет давным давно и тогда он мне не очень понравился. Особенно ступенчатостью зумма и видимой подгрузкой. Хотелоь всё сделаь максимально плавно. Сейчас, вроде, появились такие карты в сети, о я с исходниками не знакомился.
У меня вот так тогда поучилось на уровне прототипа:
https://sublayers.net
Там всё сырое и плохо написано. первый мой JS-код, с тех пор и не писал ничего на JS.
Надо, конечно отрефаторить.
Суть идеи такая: на базе канваса делается плавный рендер карты и всё это встраиватся в SPA, чтобы в браузере работало без перезагрузок и отчатси в оффлайне. Потом можно в электрон какой-нибудь запечь, или ещё как, чтобы прототип мобильного приложения в рамках MVP быстро сделать можно было.
На джанго тоже можно сделать SPA, к тому же структура проекта джанго позволяет навешивать на основной проект свои и сторонние приложения, которые смогут нормально друг с другом уживаться. Часто в проекте требуется блоговый движок, авторизации какие-то особенные, дугие интеграции... Все эти батарейки у Джанго в избытке доступны.
SPA на фласке проще потнятнее, но больше писать самому и нет админки из коробки. Хотя надо поискать, наверняка и для фласка того же есть готовые штуки.

Ктсати, в ыне поделились подробнее что хотите делать. Может там риалтайм и нагрузки будут... к примеру, мультиагентный трекинг множесва объектов. Тогда я бы посмотрел в стороно асинхронных фреймворков. Однако стартовать, конечно, проще с Джанги. Там тебе и оганично вписанная ОРМ с миграциями, и админка. и пользователи с правами.
Выщелкнуть что-то в микросервис да с асинхронными потрохами никогда не сложно.

Скрипт на питоне написать, если умеешь.
Если не умеешь, можно в экселе соорудить таблицу и сконкатенировать формулами командные строки, которые "попробуют" распаковать каждый архив каждым паролем.
Можно составить команду таким образом, что после успешной попытки сам архив будет удалён. Так можно наделать кучу батников (или шелл-скриптов) по одному на каждый архив и этот батник будет перебирать пароли.
Нужно всего лишь почитать хелп к параметрам командной строки архиватора и составить команду по шаблону с паролем.

VDS подойдёт точно, не факт, что это будет самый дешевый вариант, но уж точно самый удобный в плане изоляции. Если сайт не слишком нагруженный, то можно в контейнерах поднять и БД и бэк, и nginx, и что там еще потребуется...