Ну, раз это понадобилось тебе, то значит нужно и кому-нибудь еще. Выложи как gist на гитхабе, например.

>>14611
Отбой пока, надо допиливать.
Оказывается, закодированные в utf8 письма перекодируются (или могут быть перекодированы) в "=<hexcode>=hexcode>…", и я не отлавливаю этот момент (и участок, отвечающий за некие исправления писем после вывода gpg был скопипижжен без особых разбирательств что и зачем) (хотя часть писем читается нормально, странно) (email сложный формат x_x)

>>14612
Окей, проблема в том, что я не переношу все заголовки из расшифрованного письма, которые нужно. Content-Transfer-Encoding был благополучно выброшен на свалку лол.
Мне надо ДУМАТЬ.

Еще мне надо заткнуться и не превращать этот торедо в бложек разработки.

>>14613
>я не переношу все заголовки из расшифрованного письма
байты экономишь, или в чем проблема перенести их все?

>>14619
Они частично дублируют заголовки исходного (зашифрованного) письма, и мне надо думать, какие переносить, а какие лучше оставить (может, просто переписать их все будет неплохой идеей, поскольку пока что они являются копиями).

Собственно, забыл упомянуть, что я пытаюсь сохранить ВСЕ заголовки исходного письма, которые не противоречат расшифрованному письму (ну, типа, я заменяю Content-Type: multipart/encrypted или multipart/signed на multipart/mixed (заменить просто, эти заголовки находятся в расшифровке) или text/plain). Перетащить заголовки почти без изменений — это фича, которая сделала этот скрипт несколько сложнее, чем он мог бы быть (и, также, уникальным, поскольку простых скриптов для передачи сообщения gpg с минимальной обработкой есть по меньшей мере один (pine-pgp-filters для alpine), который я использовал в качестве отправной точки).

>>14620 ну так сделай слияние двух массивов по заранее определённым правилам. тебе же не произвольные строки парсить, всё можно сделать при помощи while и case

и да
>awk...
...в sh = телега с реактивным двигателем. хотя я по молодости делал perl в sh, что вообще Ы, если учесть, что оно таки работало
>sed, grep
sed может делать всё то же, что и grep, и даже больше. тащить в скрипт лишнюю зависимость — плохая идея
>bash
на операционках с rc это дурной тон, там системный интерпретатор — sh

>>14636
Не, там абы как сливать нельзя все равно. В зависимости от типа контента, надо поступать по-разному.
Хотя, может, под "правилами" ты это и имеешь в виду. Проблема в том, что я с трудом представляю себе эти правила. Пока у меня нагромождение логики, отвечающей за различные специфические случаи, на старой логике. Возможно, я переработаю это полностью. Очень "неприятное" место — именно где требуется совместить типы контента зашифрованного и незашифрованного писем. Думаю, я как раз с этим разобрался.
>в sh = телега с реактивным двигателем
Что ты имеешь в виду? У меня он в довольно простом варианте используется.
>sed может делать всё то же, что и grep, и даже больше.
Я использую grep для МНОГОСТРОЧНЫХ РЕГУЛЯРНЫХ ВЫРАЖЕНИЙ (с ключом -P). x_x
sed такого не может, насколько мне известно. Правда, опять же, возможно я смогу обойтись sed'ом для тех задач.
Еще я использую exit code от grep для if в паре мест (sed не вернет мне ненулевой код завершения если ничего не было найдено).
>на операционках с rc это дурной тон
Ну, в первой строке у меня написано #!/bin/sh вообще-то.
Правда я использую штуки вроде ${variable} местами, как и $(code with output) для заполнения переменных, как и наверно что-то еще не свойственное чистому Bourne Shell.

>>14637 просто надо определить, какие заголовки подлежат модификации, а какие удалению. это и будет набором правил
>Что ты имеешь в виду?
у телеги есть своё предназначение, глупо от нёе хотеть скорости феррари и проходимости Урала
>с ключом -P
>This option is not supported in FreeBSD.
sadfrog.jpg вообще, если так нужны PCRE, стоит задуматься о том, не переписать ли всё на PERL
>sed не вернет мне ненулевой код завершения если ничего не было найдено
он вернёт пустую строку, проверяешь её: [ -z "$string" ] — если строка пустая; [ "$string" ] — если строка не пустая
>что-то еще не свойственное чистому Bourne Shell
http://mywiki.wooledge.org/Bashism

>>14636
> sed может делать всё то же, что и grep
$ grep -P '\p{P}?\p{Cyrillic}\p{P}?' <<<'‘You’re full of shit’ – сказалъ я с позированнымъ взглядомъ. Гдѣ ж ты набрался такого, Ѳетюкъ?'
$ grep -P '\p{P}(?=\w)|\p{P}(?<=\w)' <<<'‘You’re full of shit’ – сказалъ я с позированнымъ взглядомъ.
$ grep -P '(?i)(?|(цалуй)|(лобызай))-\1 лягушонку!' <<<'Цалуй-цалуй лягушонку! Лобызай-лобызай лягушонку!'
Ваш ход, маэстро.
> тащить в скрипт лишнюю зависимость — плохая идея
Это да, нефиг юзать
$ grep -q '^Found$' <<<'Found' && found=t
когда можно православным седом
$ sed -rn 's/^Found$/&/;T;Q1' <<<'Found' || found=t
Красота же. И читабельность на уровне!
> на операционках с rc это дурной тон, там системный интерпретатор — sh
Я надеюсь, вы мох регулярно с пекарен счищаете в своей конторе? А то не дай бог в вентилятор попадёт, у-у…

>>14637
> Я использую grep для МНОГОСТРОЧНЫХ РЕГУЛЯРНЫХ ВЫРАЖЕНИЙ (с ключом -P).
sed тоже может обрабатывать многострочные паттерны. Вопрос в том, искать тебе надо или заменять что-то в них. Если последнее, то лучше, конечно, sed.
> sed такого не может, насколько мне известно.
Один пример. http://www.rtfiber.com.tw/~changyj/sed/html/p.20051024a.html
> sed не вернет мне ненулевой код завершения если ничего не было найдено
Я иногда пользуюсь костылём, когда нужно что-то найти, заменить и сказать получилось ли. Если нужно только найти лучше grep -q.
> Ну, в первой строке у меня написано #!/bin/sh вообще-то.
Нельзя так писать, если не пишешь под POSIX shell. Пишешь для баша? Так и пиши #! /usr/bin/env bash
> Правда я использую штуки вроде ${variable} местами, как и $(code with output) для заполнения переменных, как и наверно что-то еще не свойственное чистому Bourne Shell.
То, что ты написал — это как раз стандартный POSIX shell. Башизмы это когда ${var/abc/def},

echo true

или ref_list=${!ref*}, например.

>>14642
> вообще, если так нужны PCRE, стоит задуматься о том, не переписать ли всё на PERL
И ебаться с файлами и потоками вместо >file <file < <(find …) ?
Сам топи урановые ломы.
> он вернёт пустую строку, проверяешь её: [ -z "$string" ] — если строка пустая; [ "$string" ] — если строка не пустая
man bash открывал вообще?
[ "$str" ] && { echo doing job; echo ok; } || { echo doing other job; echo fail; }

>кому-то это нужно
Мне. Выкладывай сейчас, а лучше — на гитхаб, где его можно будет коллективно допиливать.

>>14998
>Выкладывай сейчас
Хорошо.

http://pastebin.com/6HZtY7xr
На тему коллективного допиливания: вы можете сами взять этот код. Я его никак не "лицензирую" и, наверно, не стоит этого делать (там еще есть следы кода pgp-alpine-filters).

P.S: выглядит оно как Франкенштейн, но оно "works for me" и вроде неплохо охватило все случаи писем, создаваемых thunderbird и claws-mail.

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

>>15018
О, забыл сказать, что для работы скрипта надо указать в нем самом пассфразу для используемого ключа на месте %passphrase% (то есть, оно расшифрует только те письма, что зашифрованы одним и тем же ключом, для остального его требуется запускать отдельно). Я не нашел иного достаточно быстрого способа расшифровать целую пачку писем. Изначально этот скрипт был "фильтром", то есть дополнительной обработкой для alpine, то есть ручной ввод пассфразы каждый раз виделся там разумным ходом. Можно легко изменить поведение скрипта на такое.