[Comm] перенаправление вывода в лог

[Comm] перенаправление вывода в лог

[Sinom]

Как перенаправить ВЕСЬ вывод идущий на экран в лог? Например необходимо
необходимо перенаправить вывод команды rpm --rebuild... Говорю: "rpm
--rebuild qwerty.src.rpm > rebuil.log", а в лог поподает не все, что
творится на экране. Как осуществить одноврименно весь вывод и на экран и
в лог?
--
Роман

Re: [Comm] перенаправление вывода в лог

[Sergey Vlasov]

On Fri, Oct 25, 2002 at 20:58:26 +0800, Sinom wrote:
> Как перенаправить ВЕСЬ вывод идущий на экран в лог? Например необходимо
> необходимо перенаправить вывод команды rpm --rebuild... Говорю: "rpm
> --rebuild qwerty.src.rpm > rebuil.log", а в лог поподает не все, что
> творится на экране. Как осуществить одноврименно весь вывод и на экран и
> в лог?

Так перенаправляется только stdout, а вся ругань, как правило, идет в
stderr. Нужно добавить еще 2>&1 (или почитать man на используемый shell и
найти там комбинацию символов, позволяющую сделать перенаправление stdout
и stderr одним махом).

Еще можно "... 2>&1 |tee some.log".

Также см. man script (хотя это в данном случае менее удобно, т.к. в лог
попадают управляющие последовательности терминала и ^M).

Re: [Comm] перенаправление вывода в лог

[Слава Гарелин]

25 Октябрь 2002 15:58, Sinom написал:
> Как перенаправить ВЕСЬ вывод идущий на экран в лог? Например необходимо
> необходимо перенаправить вывод команды rpm --rebuild... Говорю: "rpm
> --rebuild qwerty.src.rpm > rebuil.log", а в лог поподает не все, что
> творится на экране. Как осуществить одноврименно весь вывод и на экран и
> в лог?

2>&1 > rebuil.log
, где конструкция "2>" означает, что мы перенаправляем из потока с 
дескриптором 2 (стандартный поток ошибок) а "&1" означает, что в качестве 
приемника выступает не имя файла, а дескриптор (стандартный поток вывода)  
-- 
Slava Garelin

Re: [Comm] перенаправление вывода в лог

[Andy Gorev]

[-- Attachment #1: Type: text/plain, Size: 264 bytes --]

On Fri, 25 Oct 2002 20:58:26 +0800
Sinom <sinom@ktk.ru> wrote:

> Как перенаправить ВЕСЬ вывод идущий на экран в лог? Например
http://www.atmsk.ru/viewtopic.php?t=56

-- 
С Уважением,
Андрей Горев

------------------
Get free mailbox 20 Mb at http://www.hotbox.ru

Re: [Comm] перенаправление вывода в лог

[Андрей Булава]

On Fri, 25 Oct 2002, Слава Гарелин wrote:

<skip>

>
> 2>&1 > rebuil.log

Читайте нижеследующий отрывок man bash до просветления.

       Note  that  the order of redirections is significant.  For
       example, the command

              ls > dirlist 2>&1

       directs both standard output and  standard  error  to  the
       file dirlist, while the command

              ls 2>&1 > dirlist

       directs  only the standard output to file dirlist, because
       the standard  error  was  duplicated  as  standard  output
       before the standard output was redirected to dirlist.

> --
> Slava Garelin

--
С наилучшими пожеланиями,
 Андрей Булава [ AB1002-UANIC ]
Информационный центр ДонНТУ

Re: [Comm] перенаправление вывода в лог

[Sinom]

> Читайте нижеследующий отрывок man bash до просветления.
> 
>        Note  that  the order of redirections is significant.  For
>        example, the command
> 
>               ls > dirlist 2>&1
> 
>        directs both standard output and  standard  error  to  the
>        file dirlist, while the command
> 
>               ls 2>&1 > dirlist
> 
>        directs  only the standard output to file dirlist, because
>        the standard  error  was  duplicated  as  standard  output
>        before the standard output was redirected to dirlist.

-----------------
ls > dirlist 2>&1
перенаправляет оба стандартный вывод и стандартный поток ошибок в файл
"dirlist", тогда как команда 

ls 2>&1 > dirlist

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

Перевести то я перевел, но понять не могу. :-( Пожалуйста, объясните ещё
раз, почему эти комманды приводят к различным результатам.

Re: [Comm] перенаправление вывода в лог

[Sinom]

>    ls > dirlist 2>&1

А можно, все это добро ещё и на экран вытащить, а не только в файл?

Re[2]: [Comm] ÐÅÒÅÎÁÐÒÁ×ÌÅÎÉÅ ×Ù×ÏÄÁ × ÌÏÇ

[ASA]

Hello Sinom,

Friday, October 25, 2002, 8:09:08 PM, you wrote:

S> -----------------
S>   ls > dirlist 2>&1
S> перенаправляет оба стандартный вывод и стандартный поток ошибок в файл
S> "dirlist", тогда как команда 

S>   ls 2>&1 > dirlist

S> направляет только втандартный вывод в файл "dirlist", потому что
S> стандартный поток ошибок был дублирован как стандартный вывод перед
S> стандартным выводом был перенаправлен в "dirlist". 
S> ----------------- 

S> Перевести то я перевел, но понять не могу. :-( Пожалуйста, объясните ещё
S> раз, почему эти комманды приводят к различным результатам.
"комаанды", а не "комманды" (одно "м")

Сначала: bash, когда видит конструкцию N>&M, выполняет вызов
dup (т.е. копирование служебной информации об открытом файле).
А теперь посмотрим на это дело с точки зрения программы.
Как известно, имеются три стандартных файла: номер 0 -
стандартный ввод, номер 1 - стандартный вывод и номер 2 - вывод
ошибок.

сначала имеем
   0 < stdin
   1 > stdout
   2 > stderr
 ls >dirlist заставляет bash назначить файл номер 1 на вывод в
 файл dirlist.
   0 < stdin
   1 > "dirlist"
   2 > stderr
 Затем 2>&1 приводит к копированию в файл номер 2
 служебной информации об файле номер 1. То есть файл номер 2
 теперь тоже направлен в файл dirlist
   0 < stdin
   1 > "dirlist"
   2 > "dirlist" (скопировалось из 1)

 а теперь если ls 2>&1 то сначала в файл номер 2 скопируется
 информация о файле номер 1. То есть файл номер 2 будет
 перенаправен в стандартный вывод.
   0 < stdin
   1 > stdout
   2 > stdout  (скопировалось из 1)
 И после этого >dirlist назначит файл номер 1 на вывод в файл
 dirlist, но не затронет файл номер 2, который останется
 перенаправленным в стандартный выход.
   0 < stdin
   1 > "dirlist"
   2 > stdout

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] перенаправление вывода в лог

[Sergey Vlasov]

On Fri, 25 Oct 2002 23:09:08 +0800
Sinom <sinom@ktk.ru> wrote:

> -----------------
> ls > dirlist 2>&1
> перенаправляет оба стандартный вывод и стандартный поток ошибок в файл
> "dirlist", тогда как команда 
> 
> ls 2>&1 > dirlist
> 
> направляет только втандартный вывод в файл "dirlist", потому что
> стандартный поток ошибок был дублирован как стандартный вывод перед
> стандартным выводом был перенаправлен в "dirlist". 
> ----------------- 
> 
> Перевести то я перевел, но понять не могу. :-( Пожалуйста, объясните ещё
> раз, почему эти комманды приводят к различным результатам.

Перенаправления обрабатываются слева направо. Конструкция вида "2>&1" на
самом деле создает копию файлового дескриптора 1 и заменяет дескриптор 2
этой копией; последующие перенаправления исходного дескриптора не влияют
на его копии. В первом случае сначала дескриптор 1 (stdout)
перенаправляется, а потом создается его копия в stderr. Во втором случае
сначала создается копия, а потом перенаправляется только дескриптор 1.

Re: [Comm] перенаправление вывода в лог

[Sergey Vlasov]

On Fri, 25 Oct 2002 23:24:52 +0800
Sinom <sinom@ktk.ru> wrote:

> >    ls > dirlist 2>&1
> 
> А можно, все это добро ещё и на экран вытащить, а не только в файл?

А вот тут уже нужна команда tee:

xxxxxxxx 2>&1 | tee file

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

Re[3]: [Comm] ÐÅÒÅÎÁÐÒÁ×ÌÅÎÉÅ ×Ù×ÏÄÁ × ÌÏÇ

[ASA]

Hello ASA,

Friday, October 25, 2002, 8:31:49 PM, you wrote:

A> "комаанды", а не "комманды" (одно "м")
    ^^^^^^^^
"команды", конечно же :-/

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: Re[2]: [Comm] перенаправление вывода в лог

[Sinom]

>  а теперь если ls 2>&1 то сначала в файл номер 2 скопируется
>  информация о файле номер 1. То есть файл номер 2 будет
>  перенаправен в стандартный вывод.
>    0 < stdin
>    1 > stdout
>    2 > stdout  (скопировалось из 1)
>  И после этого >dirlist назначит файл номер 1 на вывод в файл
>  dirlist, но не затронет файл номер 2, который останется
>  перенаправленным в стандартный выход.
>    0 < stdin
>    1 > "dirlist"
>    2 > stdout

Я не понимаю вот это место.
Почему второе действие (>dirlist) не затрагивает stderr?

Мои рассуждения: первым действием назначается выход для stderr (stdout),
вторым назначается выход для stdout ("dirlist"), затем это все начинает
выполняться: 
1) stdout направляется в "dirlist", 
2) а stderr направляется в stdout,  который в свою очередь уже
направляется в "dirlist", а значит stderr тоже должен туда попадать.

Где моя ошибка? 
И почему второе действие (>dirlist) не затрагивает stderr?

Re[4]: [Comm] ÐÅÒÅÎÁÐÒÁ×ÌÅÎÉÅ ×Ù×ÏÄÁ × ÌÏÇ

[ASA]

Hello Sinom,

Friday, October 25, 2002, 9:05:12 PM, you wrote:

>>  И после этого >dirlist назначит файл номер 1 на вывод в файл
>>  dirlist, но не затронет файл номер 2, который останется
>>  перенаправленным в стандартный выход.
>>    0 < stdin
>>    1 > "dirlist"
>>    2 > stdout

S> Я не понимаю вот это место.
S> Почему второе действие (>dirlist) не затрагивает stderr?
Потому что операция 2>&1 - это _копирование_ (а не связывание)
данных из 1-го элемента во 2 элемент таблицы открытых файлов
процесса.

S> И почему второе действие (>dirlist) не затрагивает stderr?
Потому что нигде не сохраняется информация о том, что где-то
(то есть в данном случае во 2-м) хранится копия 1-го элемента
таблицы открытых файлов. Другими словами, нет информации о
связывании файлов. Дескрипторы копируются, а не связываются.

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: Re[4]: [Comm] перенаправление вывода в лог

[Sinom]

> >>  И после этого >dirlist назначит файл номер 1 на вывод в файл
> >>  dirlist, но не затронет файл номер 2, который останется
> >>  перенаправленным в стандартный выход.
> >>    0 < stdin
> >>    1 > "dirlist"
> >>    2 > stdout
> 
> S> Я не понимаю вот это место.
> S> Почему второе действие (>dirlist) не затрагивает stderr?
> Потому что операция 2>&1 - это _копирование_ (а не связывание)
> данных из 1-го элемента во 2 элемент таблицы открытых файлов
> процесса.
> 
> S> И почему второе действие (>dirlist) не затрагивает stderr?
> Потому что нигде не сохраняется информация о том, что где-то
> (то есть в данном случае во 2-м) хранится копия 1-го элемента
> таблицы открытых файлов. Другими словами, нет информации о
> связывании файлов. Дескрипторы копируются, а не связываются.
> 

Мммм... Наверное я просто устал. Утро вечера мудренее. Подумаю над этим утром.

Но у меня появился новый вопрос: как сделать так, чтобы получились три
файла: stdout.log, stderr.log, stdout_and_stderr.log плюс все это
попадало на экран? Или это невозможно?

[Comm] ðÏÞÅÍÕ ÂÕÆÅÒÉÚÁÃÉÑ ÍÅÎÑÅÔ ÐÏÒÑÄÏË ×Ù×ÏÄÉÍÙÈ × ÆÁÊÌ ÓÔÒÏË?

[Henri Bourbon]

On 25 Oct 2002  19:40, Sergey Vlasov wrote:

> xxxxxxxx 2>&1 | tee file

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

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

$ perl -we 'print "1-STDOUT\n"; warn "2-STDERR\n";'
1-STDOUT
2-STDERR

Что  может  быть  проще?  Сначала  печатаем  строку 1 в один файл, затем
строку  2  в  другой.  Т.  к.  оба  файла  оказываются  одним  и  тем же
(терминалом,  или,  грубо говоря, просто экраном), то сначала печатается
строка 1, затем -- строка 2. Как же может быть иначе? Ан нет, подключаем
перенаправления, получаем:

$ perl -we 'print "1-STDOUT\n"; warn "2-STDERR\n";' >out 2>&1
$ cat out
2-STDERR
1-STDOUT

Странно! Почему так?.. ладно, выключаем буферизацию:

$ perl -we '$| = 1; print "1-STDOUT\n"; warn "2-STDERR\n";' >out 2>&1
$ cat out
1-STDOUT
2-STDERR

Теперь все нормально... Каким же волшебным образом буферизация влияет на
то, в каком порядке стоки попадут в файл?

-- 
HB

Re[6]: [Comm] ÐÅÒÅÎÁÐÒÁ×ÌÅÎÉÅ ×Ù×ÏÄÁ × ÌÏÇ

[ASA]

Hello Sinom,

Friday, October 25, 2002, 9:57:44 PM, you wrote:

S> Но у меня появился новый вопрос: как сделать так, чтобы получились три
S> файла: stdout.log, stderr.log, stdout_and_stderr.log плюс все это
S> попадало на экран? Или это невозможно?
Просто редиректами bash - imho невозможно. Потому что
в bash нет операции "2|", которая бы направляла stderr в pipe

Иначе можно было бы записать вот такой бред наподобие
my_program | (tee stdout.log) 2| (tee stderr.log) 2>&1 |tee stouterr.log
что вообще-то бессмыслица, начиная с символов "2|".

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] ðÏÞÅÍÕ ÂÕÆÅÒÉÚÁÃÉÑ ÍÅÎÑÅÔ ÐÏÒÑÄÏË ×Ù×ÏÄÉÍÙÈ × ÆÁÊÌ ÓÔÒÏË?

[ASA]

Hello Henri,

Friday, October 25, 2002, 10:20:14 PM, you wrote:

HB> $ perl -we 'print "1-STDOUT\n"; warn "2-STDERR\n";' >out 2>&1
HB> $ cat out
HB> 2-STDERR
HB> 1-STDOUT

HB> Каким же волшебным образом буферизация влияет на
HB> то, в каком порядке стоки попадут в файл?
Потому что в общем случае нет гарантии, какой файловый
дескриптор закроется первым. Они оба указывают на один и тот же
файл, но буфер-то не у файла, а у файлового дескриптора (первого
и второго). Чей дескриптор первым закроется, тот и первым
сбросит буфер в файл.

imho. Пусть netch меня поправит, если что.

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] перенаправление вывода в лог

[Anton Kovalenko]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

>>>>> ASA  writes:

    S> Но у меня появился новый вопрос: как сделать так, чтобы получились три
    S> файла: stdout.log, stderr.log, stdout_and_stderr.log плюс все это
    S> попадало на экран? Или это невозможно?

    > Просто редиректами bash - imho невозможно. Потому что
    > в bash нет операции "2|", которая бы направляла stderr в pipe

Hикогда не говори никогда.

do_something  2> >(tee stderr.log >&2) |tee stdout.log ) > >(tee stderrout.log) 2>&1

Справедливости ради  надо сказать, что zsh от  таких извращений слегка
фигеет, и не делает wait везде, где надо бы. Hо вот собственно bash --
срабатывает нормально.

-- 
With Best Wishes, Anton Kovalenko /* http://kovalenko.webzone.ru */
#!/usr/bin/wish - best wish I have for you!

------------------
Get free mailbox 20 Mb at http://www.hotbox.ru

Re[2]: [Comm] ÐÅÒÅÎÁÐÒÁ×ÌÅÎÉÅ ×Ù×ÏÄÁ × ÌÏÇ

[ASA]

Hello Anton,

Saturday, October 26, 2002, 12:50:35 AM, you wrote:

AK>     > Просто редиректами bash - imho невозможно. Потому что
AK>     > в bash нет операции "2|", которая бы направляла stderr в pipe

AK> Hикогда не говори никогда.
было сказано imho

AK> do_something  2> >(tee stderr.log >&2) |tee stdout.log ) > >(tee stderrout.log) 2>&1
                                                           ^
                                             скобка не открыта

AK> Справедливости ради  надо сказать, что zsh от  таких извращений слегка
AK> фигеет, и не делает wait везде, где надо бы. Hо вот собственно bash --
AK> срабатывает нормально.

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] перенаправление вывода в лог

[Sinom]

> Hикогда не говори никогда.
> 
> do_something  2> >(tee stderr.log >&2) |tee stdout.log ) > >(tee stderrout.log) 2>&1
> 
> Справедливости ради  надо сказать, что zsh от  таких извращений слегка
> фигеет, и не делает wait везде, где надо бы. Hо вот собственно bash --
> срабатывает нормально.

Можно попросить расшифровать?
2> - stderr перенаправляет куда?
почему пишется два символа ">" с пробелом между ними "> >"

И что-то у меня это не работает... Говорит ошибка синтаксиса ")"
попробовал развернуть скобку, выходит тоже самое. При её убирании не
получается должного эффекта раскладывания по файлам.

Re: [Comm] перенаправление вывода в лог

[Anton Kovalenko]

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

>>>>> Sinom  writes:

    >> do_something  2> >(tee stderr.log >&2) |tee stdout.log ) > >(tee stderrout.log) 2>&1
    >> 
    >> Справедливости ради  надо сказать, что zsh от  таких извращений слегка
    >> фигеет, и не делает wait везде, где надо бы. Hо вот собственно bash --
    >> срабатывает нормально.

Забыл первую открывающую скобку. Прошу извинить.
(do_something  2> >(tee stderr.log >&2) |
  tee stdout.log ) > >(tee stderrout.log) 2>&1

    > Можно попросить расшифровать?
    2> - stderr перенаправляет куда?
    > почему пишется два символа ">" с пробелом между ними "> >"

  >(command) 
      подставляет "файл" из /dev/fd, который направлен на stdin команды
      command.
  2> >(command)
      перенаправление stderr текущей команды  в этот файл.


(do_something  2> >(tee stderr.log >&2) |
  tee stdout.log )

Эта конструкция выполнится в subshell'е.

Здесь мы перенаправляем do_something's stderr на вход "tee stderr.log",
а stdout "tee stderr.log" выводим на stderr , чтобы он "проскочил мимо"
команды tee stdout.log

 > >(tee stderrout.log) 2>&1

Здесь   мы  направляем   stdout  на   (tee  stderrout.log),   а  затем
перенаправляем в ту же сторону и stderr.

-- 
With Best Wishes, Anton Kovalenko /* http://kovalenko.webzone.ru */
#!/usr/bin/wish - best wish I have for you!

------------------
Get free mailbox 20 Mb at http://www.hotbox.ru

Re: [Comm] Почему буферизация меняет порядок выводимых в файл строк?

[Valentin Nechayev]

 Fri, Oct 25, 2002 at 21:20:14, useperl wrote about "[Comm] Почему буферизация меняет порядок выводимых в файл строк?": 

> From: Henri Bourbon <useperl@fastmail.fm>
> Да,   в  свое  время меня очень обескуражил этот эффект. Теперь с этим я
> разобрался,  непонятно  же  другое:  почему  буферизация  может поменять
> *порядок* выводимых в файл строк. Поясняю:

Могут быть и более странные эффекты.
Дело в том, что если буфера не сброшены явно, то они сбрасываются при
выполнении exit(). А обычно libc построена так, что они сбрасываются
в порядке обратном стандартному порядку перечисления, то есть stderr
сбрасывается раньше, чем stdout.

У Вас слишком простой тест был. Вот более навороченный:

$ perl -we 'print "1-STDOUT\n"; warn "2-STDERR\n"; print "1-STDOUT\n"; warn "2-STDERR\n";'
1-STDOUT
2-STDERR
1-STDOUT
2-STDERR
$ perl -we 'print "1-STDOUT\n"; warn "2-STDERR\n"; print "1-STDOUT\n"; warn "2-STDERR\n";' 2>&1 | cat
2-STDERR
2-STDERR
1-STDOUT
1-STDOUT

Это подтверждает то, что я описал в дополнение к описанному ранее:
1. Из-за того, что не терминал, а пайп - буферизация идет поблочно, а не
построчно.
2. Блоки для stdout и stderr разные.
3. Буфер для stderr сбрасывается раньше.

А еще веселее получается, если stdout и stderr направлены в один пайп,
а вывода по каждому из них больше чем стандартный размер буфера (обычно 4K,
AFAIR). Когда буфер сбрасывается не по exit(), строки могут быть разрезаны
пополам.

На логи make это обычно не влияет потому, что от каждого процесса
выдача короткая. Но тоже бывает (если, например, много ошибок и много
нормального вывода).


/netch

Re: [Comm] Почему буферизация меняет порядок выводимых в файл строк?

[Valentin Nechayev]

 Fri, Oct 25, 2002 at 22:42:22, llb wrote about "Re: [Comm] Почему буферизация меняет порядок выводимых в файл строк?": 

 HB> то, в каком порядке стоки попадут в файл?
> Потому что в общем случае нет гарантии, какой файловый
> дескриптор закроется первым. Они оба указывают на один и тот же
> файл, но буфер-то не у файла, а у файлового дескриптора (первого
> и второго). Чей дескриптор первым закроется, тот и первым
> сбросит буфер в файл.
> 
> imho. Пусть netch меня поправит, если что.

С заменой дескриптора (обычно так называется объект ядра, описываемый
целым числом) на объект stdio, указываемый типом FILE* - именно так.


/netch

[comm] ðÏÞÅÍÕ ÂÕÆÅÒÉÚÁÃÉÑ ÍÅÎÑÅÔ ÐÏÒÑÄÏË ×Ù×ÏÄÉÍÙÈ × ÆÁÊÌ ÓÔÒÏË?

[Henri Bourbon]

On 27 Oct 2002  13:53, Valentin Nechayev wrote:

>> Да,   в  свое  время меня очень обескуражил этот эффект. Теперь с этим я
>> разобрался,  непонятно  же  другое:  почему  буферизация  может поменять
>> *порядок* выводимых в файл строк. Поясняю:

> Могут быть и более странные эффекты.
> Дело в том, что если буфера не сброшены явно, то они сбрасываются при
> выполнении exit(). А обычно libc построена так, что они сбрасываются
> в порядке обратном стандартному порядку перечисления, то есть stderr
> сбрасывается раньше, чем stdout.

[skip]

> 1. Из-за того, что не терминал, а пайп - буферизация идет поблочно, а не
> построчно.
> 2. Блоки для stdout и stderr разные.
> 3. Буфер для stderr сбрасывается раньше.

> А еще веселее получается, если stdout и stderr направлены в один пайп,
> а вывода по каждому из них больше чем стандартный размер буфера (обычно 4K,
> AFAIR). Когда буфер сбрасывается не по exit(), строки могут быть разрезаны
> пополам.

> На логи make это обычно не влияет потому, что от каждого процесса
> выдача короткая. Но тоже бывает (если, например, много ошибок и много
> нормального вывода).

Даже не ожидал получить столь фундаментальный ответ :-) Спасибо большое.
/*  По   правде   говоря,   я,   непрограммист,  кое-чего даже недопонял
(насчет  логов make). Но это, может, просто потому, что сейчас 5 утра...
Высплюсь и утром доосмыслю :-)         */

-- 
HB

[Comm] Re: РЕТЕОБРТБЧМЕОЙЕ ЧЩЧПДБ Ч МПЗ

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 235 bytes --]

On Fri, 25 Oct 2002 20:31:49 +0500
ASA <llb@udm.ru> wrote:

> Hello Sinom,

У Вас Бат немножечко портит заголовки, отсылая их в 8bit plain
text.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[Comm] Re: [JT] Re: òåôåïâòôâþíåïêå þýþðäâ þ íðú

[ASA]

Hello Vitaly,

Monday, October 28, 2002, 11:16:50 AM, you wrote:

VO> У Вас Бат немножечко портит заголовки, отсылая их в 8bit plain
VO> text.
И это называется "портит"? Давай хидеры посмотрим как они
обратно ко мне пришли.

<skip />
A>> Received: from llb.udm.net (llb.udm.net [213.24.0.240])
A>>         by lota.izhcom.ru (8.12.5/8.12.5/Izhcom-V1.1m) with ESMTP id g9PFV44Q044193
A>>         for <community@altlinux.ru>; Fri, 25 Oct 2002 20:31:05 +0500 (SAMST)
A>> From: ASA <llb@udm.ru>
A>> X-Mailer: The Bat! (v1.60q)
A>> Message-ID: <13212772395.20021025203149@udm.ru>
A>> To: Sinom <community@altlinux.ru>
A>> Subject: Re[2]: [Comm] перенаправление вывода в лог
A>> In-Reply-To: <20021025230908.5aaf5f12.sinom@ktk.ru>
A>> References: <20021025130958.9BADC2EE5D@mail.off-club.com>
A>>  <Pine.BSF.4.44.0210251629440.88484-100000@elefant.dgtu.donetsk.ua>
A>>  <20021025230908.5aaf5f12.sinom@ktk.ru>
A>> MIME-Version: 1.0
A>> Content-Type: text/plain; charset=koi8-r
A>> Content-Transfer-Encoding: 8bit
<skip some irrelevant headers />
A>> Date: Fri, 25 Oct 2002 20:31:49 +0500
A>>
A>> Hello Sinom,
A>>
A>> Friday, October 25, 2002, 8:09:08 PM, you wrote:

Все в полном порядке. Кодировка письма указана, она
распространяется и на Subject:, а твоей Сильфиде, получается,
почему-то обязательно нужны костыли в виде =?KOI8-R?

Впрочем, если общественность еще раз попросит, сниму соотв.
флажок. До сих пор с ними не было проблем, кстати.

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

[Comm] Re: тефепвтфвюнепке юэюрдв ю нръ

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

On Mon, 28 Oct 2002 12:23:21 +0400
ASA <llb@udm.ru> wrote:

> Hello Vitaly,
> 
> Monday, October 28, 2002, 11:16:50 AM, you wrote:
> 
> VO> У Вас Бат немножечко портит заголовки, отсылая их в 8bit
> VO> plain text.
> И это называется "портит"? Давай хидеры посмотрим как они
> обратно ко мне пришли.

<skipped/>

> Все в полном порядке. Кодировка письма указана, она
> распространяется и на Subject:, а твоей Сильфиде, получается,

Она не распространяется на subject. Номер RFC не помню, но он
есть, и в нём рекомендуется кодировать 8bit заголовки.

> почему-то обязательно нужны костыли в виде =?KOI8-R?
> 
> Впрочем, если общественность еще раз попросит, сниму соотв.
> флажок. До сих пор с ними не было проблем, кстати.

Об этом сюда писали не один десяток раз.
В sylpheed это, кстати, заметно только на системе в cp1251.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[Comm] Re: [JT] Так лучше?

[ASA]

Hello Vitaly,

Monday, October 28, 2002, 12:41:21 PM, you wrote:

VO> Об этом сюда писали не один десяток раз.
VO> В sylpheed это, кстати, заметно только на системе в cp1251.

Сабж читается?
-- 
Best regards,
 ASA                            mailto:llb@udm.ru

[Comm] Re[2]: [Comm] Заголовок выпрямил.

[ASA]

Hello Andrey,

Monday, October 28, 2002, 1:45:33 PM, you wrote:

>> Об этом сюда писали не один десяток раз.
>> В sylpheed это, кстати, заметно только на системе в cp1251.

AG> А вот в этом не уверен - у меня КОИ-8, а заголовки от бата часто бывают
AG> кривыми
Огласите поименно.

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] Re: [JT] Так лучше?

[Maxim Tyurin]

[-- Attachment #1: Type: text/plain, Size: 161 bytes --]

> Сабж читается?

У меня нормально читается. (sylpheed 0.8.2)
-- 

With Best Regards, Maxim Tyurin
mailto: MrKooll@bigfoot.com
JID:	MrKooll@jabber.pibhe.com
			

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] Re: [JT] Re: РЕТЕОБРТБЧМЕОЙЕ ЧЩЧПДБ Ч МПЗ

[Anton Kovalenko]

[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]

>>>>> ASA  writes:

    VO> У Вас Бат немножечко портит заголовки, отсылая их в 8bit plain
    VO> text.
    > И это называется "портит"? Давай хидеры посмотрим как они
    > обратно ко мне пришли.

    A> Subject: Re[2]: [Comm] перенаправление вывода в лог
 [....]
    A> Content-Type: text/plain; charset=koi8-r
    A> Content-Transfer-Encoding: 8bit

    > Все в полном порядке. Кодировка письма указана, она
    > распространяется и на Subject:,

Кто это сказал?

    > а твоей Сильфиде, получается, почему-то обязательно нужны
    > костыли в виде =?KOI8-R?

Это не костыли, это RFC2047. Так что, если меряться "стандартностью" и
"общепринятостью", то VO будет более прав. И любой человек, который на
тебя заругается в ответ на личное мыло, будет прав по-настоящему.

Hо....

    > Впрочем, если общественность еще раз попросит, сниму соотв.
    > флажок. До сих пор с ними не было проблем, кстати.

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

Кроме  того, хочу  напомнить,  что в  этой  рассылке рекомендуется  не
использовать русских букв в заголовках вообще, потому что сделать так,
чтобы их нормально читали _все_,  невозможно. Так давайте хотя бы жить
дружно (в этом отношении) и не ругаться на нечитаемые заголовки -- уж
если человек озаботился правильно написать _тело_ сообщения, это надо
уважать ;-)

-- 
With Best Wishes, Anton Kovalenko /* http://kovalenko.webzone.ru */
#!/usr/bin/wish - best wish I have for you!

------------------
Get free mailbox 20 Mb at http://www.hotbox.ru

Re: [Comm] Re: [JT] Так лучше?

[W.Kondratev]

ASA wrote:

>Hello Vitaly,
>
>Monday, October 28, 2002, 12:41:21 PM, you wrote:
>
>VO> Об этом сюда писали не один десяток раз.
>VO> В sylpheed это, кстати, заметно только на системе в cp1251.
>
>Сабж читается?
>  
>
У меня Mozilla-Mail (под Windows).

Теперь нормально читается и тема, и собственно сообщение.
А раньше был мусор.

Re: [Comm] Re: тефепвтфвюнепке юэюрдв ю нръ

[Andrey Golovin]

On Mon, 28 Oct 2002 11:41:21 +0300
Vitaly Ostanin <vyt@vzljot.ru> wrote:

> On Mon, 28 Oct 2002 12:23:21 +0400
> ASA <llb@udm.ru> wrote:
 
> Об этом сюда писали не один десяток раз.
> В sylpheed это, кстати, заметно только на системе в cp1251.

А вот в этом не уверен - у меня КОИ-8, а заголовки от бата часто бывают
кривыми

[Comm] Re[2]: [Comm] Re: [JT] Re: РЕТЕОБРТБЧМЕОЙЕ ЧЩЧПДБ Ч МПЗ

[ASA]

Hello Anton,

Monday, October 28, 2002, 1:39:23 PM, you wrote:

AK>     > Впрочем, если общественность еще раз попросит, сниму соотв.
AK>     > флажок. До сих пор с ними не было проблем, кстати.

AK> В майлмановских  рассылках по  крайней мере я  бы попросил  не снимать
AK> этот  флажок. Дело  в  том,  что некодированные  заголовки  в koi8  --
AK> единственные,  которые  будут нормально  читаться  в текстовом  архиве
AK> рассылки.
Всем не угодишь. Кстати, что мешает маилману эти заголовки
раскодировать? Сделать раскодировку и все будут белые и
пушистые. Олег, ау?

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

[Comm] Re: [JT] Так лучше?

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

On Mon, 28 Oct 2002 12:54:19 +0400
ASA <llb@udm.ru> wrote:

> Hello Vitaly,
> 
> Monday, October 28, 2002, 12:41:21 PM, you wrote:
> 
> VO> Об этом сюда писали не один десяток раз.
> VO> В sylpheed это, кстати, заметно только на системе в cp1251.
> 
> Сабж читается?

Да, спасибо.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[Comm] Re: [JT] Re: РЕТЕОБРТБЧМЕОЙЕ ЧЩЧПДБ Ч МПЗ

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

On Mon, 28 Oct 2002 14:19:55 +0400
ASA <llb@udm.ru> wrote:

<skipped/>

> Всем не угодишь. Кстати, что мешает маилману эти заголовки
> раскодировать? Сделать раскодировку и все будут белые и
> пушистые. Олег, ау?

Некому доделать, хотя несколько раз знатоки python были are
welcome :)

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] Re[2]: [Comm] Заголовок выпрямил.

[Andrey Golovin]

On Mon, 28 Oct 2002 12:59:28 +0400
ASA <llb@udm.ru> wrote:

> Hello Andrey,
> 
> Monday, October 28, 2002, 1:45:33 PM, you wrote:
> 
> >> Об этом сюда писали не один десяток раз.
> >> В sylpheed это, кстати, заметно только на системе в cp1251.
> 
> AG> А вот в этом не уверен - у меня КОИ-8, а заголовки от бата часто
> бывают AG> кривыми
> Огласите поименно.
Кроме начала этого треда у меня ничего с кривыми заголовками не
осталось. В корзине нашел несколько писем, но все они - ответ на
что-нибудь и шли не из Бата, но, по-моему, начинались соответствующие
треды именно с Бата. Вот один из самых оригинальных сабджектов:     Re:
[Comm] Ответ: [Comm] йНМЯЕПБХПНБЮМХЕ кХМСЙЯ В исходнике:
Subject: Re: [Comm] =?KOI8-R?Q?=EF=D4=D7=C5=D4=3A_=5BComm=5D_=CA=EE=ED?=
 =?KOI8-R?Q?=F1=E5=F0=E2=E8=F0=EE=E2=E0=ED=E8=E5_=CB=E8=ED=F3=EA=F1?=
Справедливости ради - возможно, виноват не Бат, а Сильфида т.к. кажется,
что корежит subj ИМХО именно она.

Re: [Comm] Re: [JT] Так лучше?

[sam]

28 Октябрь 2002 11:54, Вы написали:

> Сабж читается?
Да - KMail.
-- 
С уважением, Степанов Алексей, СПб

Re: [Comm] Re: [JT] Так лучше?

[Ruslan N. Balkin]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

On Mon, 28 Oct 2002 12:54:19 +0400
ASA wrote:

> Hello Vitaly,
> 
> Monday, October 28, 2002, 12:41:21 PM, you wrote:
> 
> VO> Об этом сюда писали не один десяток раз.
> VO> В sylpheed это, кстати, заметно только на системе в cp1251.
> 
> Сабж читается?
И раньше читался, и сейчас читается. А вот с письма от
From: Vitaly Ostanin <vyt@vzljot.ru>
Subject: [Comm] Re: РЕТЕОБРТБЧМЕОЙЕ ЧЩЧПДБ Ч МПЗ
Reply-To: community@altlinux.ru
Date: Mon, 28 Oct 2002 10:16:50 +0300
Sender: community-admin@altlinux.ru
X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu)

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

-- 
С уважением,
Балькин Руслан.

[-- Attachment #2: For security, this message has been digitally signed. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[Comm] Re[2]: [Comm] Re: [JT] Так лучше?

[ASA]

Hello Ruslan,

Monday, October 28, 2002, 5:28:20 PM, you wrote:

RNB> И раньше читался, и сейчас читается. А вот с письма от
RNB> From: Vitaly Ostanin <vyt@vzljot.ru>
RNB> Subject: [Comm] Re: РЕТЕОБРТБЧМЕОЙЕ ЧЩЧПДБ Ч МПЗ
RNB> Reply-To: community@altlinux.ru
RNB> Date: Mon, 28 Oct 2002 10:16:50 +0300
RNB> Sender: community-admin@altlinux.ru
RNB> X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu)

Его сильфида, работая в локали CP1251, не поняла мой 8-битный
заголовок в koi8-r, что соответствует кодировке письма (может
это и не по RFC, но логично). Так кто из нас имеет кривый клиент?

--
Best regards,
 ASA                            mailto:llb@udm.ru

[Comm] Re: [JT] Так лучше?

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

On Mon, 28 Oct 2002 16:28:20 +0300
"Ruslan N. Balkin" <baron@dartel.ru> wrote:

> On Mon, 28 Oct 2002 12:54:19 +0400
> ASA wrote:
> 
> > Hello Vitaly,
> > 
> > Monday, October 28, 2002, 12:41:21 PM, you wrote:
> > 
> > VO> Об этом сюда писали не один десяток раз.
> > VO> В sylpheed это, кстати, заметно только на системе в
> > VO> cp1251.
> > 
> > Сабж читается?
> И раньше читался, и сейчас читается. А вот с письма от
> From: Vitaly Ostanin <vyt@vzljot.ru>
> Subject: [Comm] Re: РЕТЕОБРТБЧМЕОЙЕ ЧЩЧПДБ Ч МПЗ

Это проявление того, что sylpheed не смог прочитать не указанную
кодировку, поэтому оставил, как есть.

Обратите внимание на кодировку subject этого письма.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] Re[2]: [Comm] Re: [JT] Так лучше?

[Dmitry E. Oboukhov]

>
>
>Его сильфида, работая в локали CP1251, не поняла мой 8-битный
>заголовок в koi8-r, что соответствует кодировке письма (может
>это и не по RFC, но логично). Так кто из нас имеет кривый клиент?
>
>  
>
когда-то так же рассуждали писатели нецкапы и ввели возможность
переключения кодировок при просмотре. теперь имеем зоопарк.
стандарт он какой есть, логичный или нет, должен соблюдаться.
кривый клиент именно Ваш, так как шлет письма в разрез стандарту.

[Comm] Re[2]: [Comm] Re[2]: [Comm] Re: [JT] Так лучше?

[ASA]

Hello Dmitry,

Monday, October 28, 2002, 6:18:42 PM, you wrote:

>>Его сильфида, работая в локали CP1251, не поняла мой 8-битный
>>заголовок в koi8-r, что соответствует кодировке письма (может
>>это и не по RFC, но логично). Так кто из нас имеет кривый клиент?
>>
>>  
>>
DEO> когда-то так же рассуждали писатели нецкапы и ввели возможность
DEO> переключения кодировок при просмотре. теперь имеем зоопарк.
DEO> стандарт он какой есть, логичный или нет, должен соблюдаться.
DEO> кривый клиент именно Ваш, так как шлет письма в разрез стандарту.

А если стандарт нелогичный, и происходит его саботаж?
К примеру, я также из бата пишу в fido7, и требование шлюза -
поле subj обязательно должно быть чистым 8-битным в koi8.
К счастью, этот параметр в бате для каждого ящика независимый,
поэтому, отменив 8-битные заголовки, я ничего не потерял в
отношении fido7, "приобрел" "друзей", пишущих в Сильфиде, но
архивы mailman стали хуже. Если уж сами менеджеры рассылок
не полностью соблюдают стандарты, чего тогда требовать от
остальных?

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

[Comm] Re: [Comm] Re[2]: [Comm] Re[2]: [Comm] Re: [JT] Так лучше?

[Dmitry E. Oboukhov]

>
>
>DEO> когда-то так же рассуждали писатели нецкапы и ввели возможность
>DEO> переключения кодировок при просмотре. теперь имеем зоопарк.
>DEO> стандарт он какой есть, логичный или нет, должен соблюдаться.
>DEO> кривый клиент именно Ваш, так как шлет письма в разрез стандарту.
>
>А если стандарт нелогичный, и происходит его саботаж?
>К примеру, я также из бата пишу в fido7, и требование шлюза -
>поле subj обязательно должно быть чистым 8-битным в koi8.
>К счастью, этот параметр в бате для каждого ящика независимый,
>поэтому, отменив 8-битные заголовки, я ничего не потерял в
>отношении fido7, "приобрел" "друзей", пишущих в Сильфиде, но
>архивы mailman стали хуже. Если уж сами менеджеры рассылок
>не полностью соблюдают стандарты, чего тогда требовать от
>остальных?
>
>  
>
когда стандарт нелогичный надо пинать писателей стандарта в целях
его дополнения.
кстати о гейтах fido7 - один из таких - мной написанный (на 2:455) именно
так и делает: если никакими средствами нельзя определить кодировку
сабжа - считает её той, же что и кодировка тела. это мне пришлось сделать
как раз из-за таких кривых почтовых клиентов как Бат, а может быть из-за
того, что по умолчанию они не на стандарт настроены, а разбираться
с каждым отдельным случаем было недосуг. ИМХО - если уж вводится
в программу нестандартная возможность, то по умолчанию в дефолтных
настройках она должна быть отключена - в этом случае большинство софта
будет работать правильно.

[Comm] Re: [Comm] Re: [Comm] Re[2]: [Comm] Re[2]: [Comm] Re: [JT] Так лучше?

[ASA]

Hello Dmitry,

Monday, October 28, 2002, 6:42:22 PM, you wrote:

DEO> когда стандарт нелогичный надо пинать писателей стандарта в целях
DEO> его дополнения.
DEO> кстати о гейтах fido7 - один из таких - мной написанный (на 2:455) именно
DEO> так и делает: если никакими средствами нельзя определить кодировку
DEO> сабжа - считает её той, же что и кодировка тела.
Дополнить этим требованием стандарт и все!!!

DEO> это мне пришлось сделать
DEO> как раз из-за таких кривых почтовых клиентов как Бат, а может быть из-за
Опять навешиваем ярлык?

DEO> того, что по умолчанию они не на стандарт настроены, а разбираться
DEO> с каждым отдельным случаем было недосуг. ИМХО - если уж вводится
DEO> в программу нестандартная возможность, то по умолчанию в дефолтных
DEO> настройках она должна быть отключена - в этом случае большинство софта
DEO> будет работать правильно.
Между прочим, ПО ДЕФОЛТУ в Бате отключены 8-битные заголовки.
Где тут его кривость?

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] Re[2]: [Comm] Re: [JT] Так лучше?

[Sergey Vlasov]

On Mon, Oct 28, 2002 at 18:05:15 +0400, ASA wrote:
> Его сильфида, работая в локали CP1251, не поняла мой 8-битный
> заголовок в koi8-r, что соответствует кодировке письма (может
> это и не по RFC, но логично). Так кто из нас имеет кривый клиент?

А что прикажете делать, если частей text/plain несколько, и все в разных
кодировках?  Если text/plain вообще нет, а есть text/html?  А если сверху
вообще multipart/encrypted, под ним multipart/signed, под ним... ?

Нет, можно, конечно, вводить всякие предположения, типа "а вот если письмо
послано вот таким клиентом, то он, скорее всего, послал его в кодировке
XXX" - но для чего же тогда писали стандарты?  К тому же всякий такой
обход ведет к тому, что другие начинают считать это поведение нормальным,
что приводит к умножению бардака.

Re: [Comm] Re[2]: [Comm] Re[2]: [Comm] Re: [JT] Так лучше?

[Ruslan N. Balkin]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

On Mon, 28 Oct 2002 18:30:21 +0400
ASA wrote:

> А если стандарт нелогичный, и происходит его саботаж?
> К примеру, я также из бата пишу в fido7, и требование шлюза -
> поле subj обязательно должно быть чистым 8-битным в koi8.
> К счастью, этот параметр в бате для каждого ящика независимый,
> поэтому, отменив 8-битные заголовки, я ничего не потерял в
> отношении fido7, "приобрел" "друзей", пишущих в Сильфиде, но
Нормально читались ваши subjectы до и нормально читаются сейчас. Локаль
ru_RU.KOI8-R :)
> архивы mailman стали хуже. Если уж сами менеджеры рассылок
> не полностью соблюдают стандарты, чего тогда требовать от
> остальных?
Любым стандартам следуют не все, но наверное, лучше все же это делать - ибо
чем больше людей\программ соблюдают стандарт, тем меньше потом у них будет
проблем.

-- 
С уважением,
Балькин Руслан.

[-- Attachment #2: For security, this message has been digitally signed. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[Comm] Re: [Comm] Re: [Comm] Re: [Comm] Re[2]: [Comm] Re[2]: [Comm] Re: [JT] Так лучше?

[Dmitry E. Oboukhov]

>
>
>DEO> когда стандарт нелогичный надо пинать писателей стандарта в целях
>DEO> его дополнения.
>DEO> кстати о гейтах fido7 - один из таких - мной написанный (на 2:455) именно
>DEO> так и делает: если никакими средствами нельзя определить кодировку
>DEO> сабжа - считает её той, же что и кодировка тела.
>Дополнить этим требованием стандарт и все!!!
>  
>
только это надо делать _сперва_. а уж потом писать клиентский софт
так работающий.

>DEO> это мне пришлось сделать
>DEO> как раз из-за таких кривых почтовых клиентов как Бат, а может быть из-за
>Опять навешиваем ярлык?
>
опять ?

>Между прочим, ПО ДЕФОЛТУ в Бате отключены 8-битные заголовки.
>Где тут его кривость?
>
>  
>
они _сейчас_ отключены. На момент когда это все происходило наверно
было не так: очень много жалоб появилось на неправильную кодировку
сабжа именно от пользователей Бата. Мы тут тоже дали слабину: вместо
того, чтобы послать их куда подальше настраивать свои почтовики - мы
(учитывая что гейт крутится в русскоязычной среде) пошли на нарушения
стандарта. Кстати таких вещей много было: например WinPoint делает
переносы строк не по FTS0001, аттачи он ЮЮчит тоже из рук вон.
пришлось сделать так, что если гейт не может ничего сделать с письмом
(кодировка, атачи или еще чего), то он тело письма пакует и атачит, а
юзеру пишет письмо, что неплохо ему свой софт поднастроить.
Самый интересный перл - письма в КОИ-8 у которых чарсет выставлен
в US_ASCII ! и как вы думаете какой у них был выставлен маилер ?
- Бат.
о так от.
кстати со всеми этими мытарствами я сам тогда отказался от Бата.
сейчас под виндами юзаю Мозиллу. Сильфида под виндами к сожалению
глючная страшно была, не знаю, как сейчас с ней дело обстоит...

[Comm] Re[2]: [Comm] Re[2]: [Comm] Re: [JT] Так лучше?

[ASA]

Hello Sergey,

Monday, October 28, 2002, 6:56:56 PM, you wrote:

>> Его сильфида, работая в локали CP1251, не поняла мой 8-битный
>> заголовок в koi8-r, что соответствует кодировке письма (может
>> это и не по RFC, но логично). Так кто из нас имеет кривый клиент?

SV> А что прикажете делать, если частей text/plain несколько, и все в разных
SV> кодировках?
Ничего не делать.

SV> Если text/plain вообще нет, а есть text/html?  А если сверху
брать его кодировку.

SV> вообще multipart/encrypted, под ним multipart/signed, под ним... ?
Для encrypted в сабже вообще не будет ничего существенного ;)

SV> Нет, можно, конечно, вводить всякие предположения, типа "а вот если письмо
SV> послано вот таким клиентом, то он, скорее всего, послал его в кодировке
SV> XXX" - но для чего же тогда писали стандарты?  К тому же всякий такой
SV> обход ведет к тому, что другие начинают считать это поведение нормальным,
SV> что приводит к умножению бардака.
отквоченные предположения - это и есть бардак.

Предлагается простое правило: если для поля "Subject:" нет явно
указанной кодировки, то проверить выполнения условий:
1. игнорируем все binary/* или multipart/* более высокого уровня
вложенности.
2. Если все оставшиеся части письма - text/* и все они имеют
одну кодировку, то берем эту кодировку для "Subject:"
3. Если условие 2 не выполняется - то бардак и делаем что хотим.
4. Прописать все это в RFC.

Кстати, если бы США использовал бы русский алфавит, а СССР -
английский (при условии сохранения прочих условий), как бы
сейчас выглядели кодовые таблицы?

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

[Comm] Re: [Comm] Re: [Comm] Re: [Comm] Re: [Comm] Re[2]: [Comm] Re[2]: [Comm] Re: [JT] Так лучше?

[ASA]

Hello Dmitry,

Monday, October 28, 2002, 7:23:34 PM, you wrote:

DEO> Самый интересный перл - письма в КОИ-8 у которых чарсет выставлен
DEO> в US_ASCII ! и как вы думаете какой у них был выставлен маилер ?
DEO> - Бат.
Он по умолчанию пишет ответы в той же кодировке, в какой было
исходное письмо. Тоже по-своему логично, думаю, что то письмо
было именно ответом на другое в us-ascii, а юзер (и бат) не
проконтролировали ситуацию.

DEO> о так от.
Версия бата какая была-то?

DEO> кстати со всеми этими мытарствами я сам тогда отказался от Бата.
В пользу чего?

DEO> сейчас под виндами юзаю Мозиллу. Сильфида под виндами к сожалению
Пройдет года, допустим, два. И нынешняя версия Мозиллы (1.0 и
1.1) могут не удовлетворять будущим стандартам - и пойдут крики,
что она тоже глючная. Я вот когда разбираюсь с подобными
жалобами на Бат, выясняю, что большая часть жалоб оттого, что
либо версия старая, либо оттого, что ее (как выясняется,
по-своему логичное) поведение отличается от того, что "должно
быть". 

DEO> глючная страшно была, не знаю, как сейчас с ней дело обстоит...
Давай остановимся на таком утверждении - из области Closed
Source Бат является лучшим почтовиком под Вынду.

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

[Comm] Re: [Comm] Re: [Comm] Re: [Comm] Re: [Comm] Re: [Comm] Re[2]: [Comm] Re[2]: [Comm] Re: [JT] Так лучше?

[Dmitry E. Oboukhov]

ASA wrote:

>Hello Dmitry,
>
>Monday, October 28, 2002, 7:23:34 PM, you wrote:
>
>DEO> Самый интересный перл - письма в КОИ-8 у которых чарсет выставлен
>DEO> в US_ASCII ! и как вы думаете какой у них был выставлен маилер ?
>DEO> - Бат.
>Он по умолчанию пишет ответы в той же кодировке, в какой было
>исходное письмо. Тоже по-своему логично, думаю, что то письмо
>было именно ответом на другое в us-ascii, а юзер (и бат) не
>проконтролировали ситуацию.
>
нелогично писать в US-ASCII русские буковы ;)

>
>DEO> о так от.
>Версия бата какая была-то?
>
1.3-1.4

>DEO> глючная страшно была, не знаю, как сейчас с ней дело обстоит...
>Давай остановимся на таком утверждении - из области Closed
>Source Бат является лучшим почтовиком под Вынду.
>
>  
>
из области  Closed - полностью с тобой согласен

[Comm] Re: [JT] Так лучше?

[Sergey Vlasov]

On Mon, 28 Oct 2002 19:07:35 +0300
"Dmitry E. Oboukhov" <node@avanto.mpei.ac.ru> wrote:

> нелогично писать в US-ASCII русские буковы ;)

Один из источников подобного безобразия - yahoo.com (похоже, кроме
US-ASCII, других кодировок там не знают).

Вот еще одна тема для флейма: размножение Re: [Comm] в subject :-)

[Comm] Re: [Comm] Re: [JT] Так лучше?

[ASA]

Hello Sergey,

Monday, October 28, 2002, 8:44:49 PM, you wrote:

SV> Вот еще одна тема для флейма: размножение Re: [Comm] в subject :-)
А на это RFC есть? Если нет, то о чем разговор? ;)

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] [JT] Так лучше?

[Sergey Vlasov]

On Mon, 28 Oct 2002 20:53:51 +0400
ASA <llb@udm.ru> wrote:

> Hello Sergey,
> 
> Monday, October 28, 2002, 8:44:49 PM, you wrote:
> 
> SV> Вот еще одна тема для флейма: размножение Re: [Comm] в subject :-)
> А на это RFC есть? Если нет, то о чем разговор? ;)

А вот тут как раз виноват Mailman. Дело в том, что при кодировании
заголовков RFC2047 не рекомендует, но и не запрещает кодировать слова,
содержащие только ASCII-символы. Некоторые программы (например,
Sylpheed) кодируют только слова, которые этого требуют; другие (Mozilla)
кодируют весь заголовок целиком. Mailman не умеет раскодировать такие
заголовки, поэтому не видит [Comm] в полностью кодированном заголовке и
добавляет новый.

[Comm] MIME в заголовках - Re: [JT] Re: РЕТЕОБРТБЧМЕОЙЕ ЧЩЧПДБ Ч МПЗ

[Valentin Nechayev]

 Mon, Oct 28, 2002 at 12:23:21, llb wrote about "[Comm] Re: [JT] Re: РЕТЕОБРТБЧМЕОЙЕ ЧЩЧПДБ Ч МПЗ": 

> A>> Subject: Re[2]: [Comm] перенаправление вывода в лог
> A>> Content-Type: text/plain; charset=koi8-r
> A>> Content-Transfer-Encoding: 8bit
> Все в полном порядке. Кодировка письма указана, она
> распространяется и на Subject:, а твоей Сильфиде, получается,
> почему-то обязательно нужны костыли в виде =?KOI8-R?

Вообще-то в RFC на MIME нету правила, что кодировка тела распространяется
и на заголовок. Совсем нету. И это понятно: кто мешает сделать заголовок
в местной кодировке при теле полностью в ascii?
Так что это - костыль, очередная полумера из серии "русского MIME".
В котором были правила вида "если кодировка не задана - считать ее koi8".
Но, увы, где-то с 98-го, когда массово пошел OEx, это правило потеряло
всякий смысл.


/netch

[Comm] Re[2]: [Comm] [JT] Так лучше?

[ASA]

Hello Sergey,

Monday, October 28, 2002, 9:41:30 PM, you wrote:

SV> А вот тут как раз виноват Mailman. Дело в том, что при кодировании
SV> заголовков RFC2047 не рекомендует, но и не запрещает кодировать слова,
SV> содержащие только ASCII-символы. Некоторые программы (например,
SV> Sylpheed) кодируют только слова, которые этого требуют; другие (Mozilla)
SV> кодируют весь заголовок целиком. Mailman не умеет раскодировать такие
SV> заголовки, поэтому не видит [Comm] в полностью кодированном заголовке и
SV> добавляет новый.
Понятно. Итак, на будущие наезды по поводу кривости Бата буду
отвечать в стиле "... а у вас в Америке негров линчуют!!!", то
есть - "А ваш Mailman тоже кривой!!!"

;)  :)  :-D   ;-D   ;-E~~~~~

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

[Comm] MIME в звголовке - Re: [Comm] Re[2]: [Comm] Re: [JT] Так лучше?

[Valentin Nechayev]

 Mon, Oct 28, 2002 at 18:30:21, llb wrote about "[Comm] Re[2]: [Comm] Re[2]: [Comm] Re: [JT] Так лучше?": 

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

Саботаж - понятно. А нелогичность - здесь туманна.

> К примеру, я также из бата пишу в fido7, и требование шлюза -
> поле subj обязательно должно быть чистым 8-битным в koi8.

На самом деле news.fido7.ru сейчас воспринимает заголовки в RFC2047
с честно заданными koi8-r и koi8-u.
Правда, разбирает их некорректно. Если поток исходных символов разделен
на два =?...?= слова с CRLF+TAB между ними, то он вставляет табуляцию.
Если аналогично CRLF+SP - то вставляет пробел. Вот соберусь с духом
и переделаю домашний mutt, чтобы он вообще не разбивал так на слова...

> К счастью, этот параметр в бате для каждого ящика независимый,
> поэтому, отменив 8-битные заголовки, я ничего не потерял в
> отношении fido7, "приобрел" "друзей", пишущих в Сильфиде, но
> архивы mailman стали хуже. Если уж сами менеджеры рассылок
> не полностью соблюдают стандарты, чего тогда требовать от
> остальных?

Ну, mailman тоже корявый. В этой рассылке треть писем с мусором в конце,
который является результатом перевода sendmail'ом из base64 в 8bit
стандартного footer'а. Я еще понял бы такое поведение от majordomo, который
никогда не претендовал на понимание MIME, но тут та-акие аннотации были,
что он весь из себя маймовый...
А в архиве почему-то срезаются MIME поля, типа C-T-E - я взял community.mbox
(ящик! не после mhonarc и прочих вебных показывалок!) и не смог читать -
сплошные base64...


/netch

[Comm] Re: [JT] Так лучше?

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

On Mon, 28 Oct 2002 19:25:26 +0400
ASA <llb@udm.ru> wrote:

<skipped/>

> SV> А что прикажете делать, если частей text/plain несколько, и
> SV> все в разных кодировках?
> Ничего не делать.

Нечитаемые заголовки.

> SV> Если text/plain вообще нет, а есть text/html?  А если
> SV> сверху
> брать его кодировку.

Которая в теге html по стандарту w3c тоже запрещена. charset
в meta - очередной костыль. Кстати, в его полезности я не
сомневаюсь ;), но пользоваться лучше всё-таки xhtml.

Кстати, если text/html тоже может быть несколько...

> SV> вообще multipart/encrypted, под ним multipart/signed, под
> SV> ним... ?
> Для encrypted в сабже вообще не будет ничего существенного ;)

Будет, конверт не шифруется.

> SV> Нет, можно, конечно, вводить всякие предположения, типа "а
> SV> вот если письмо послано вот таким клиентом, то он, скорее
> SV> всего, послал его в кодировке XXX" - но для чего же тогда
> SV> писали стандарты?  К тому же всякий такой обход ведет к
> SV> тому, что другие начинают считать это поведение нормальным,
> SV> что приводит к умножению бардака.
> отквоченные предположения - это и есть бардак.
> 
> Предлагается простое правило: если для поля "Subject:" нет явно
> указанной кодировки, то проверить выполнения условий:

Вот верите - RFC придумали не на коленке и тоже долго обсуждали.

Прилюдно соглашусь насчёт лучшести бата под вин из closed source
:)

Есть предложение дальшейшее обсуждение бата перенести в talk-room
(если там это не offtopic). Лично меня пинайте личным мылом, в
talk room не хожу.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[Comm] Re: [Comm] Re: [JT] Так лучше?

[ASA]

Hello Vitaly,

Tuesday, October 29, 2002, 11:55:24 AM, you wrote:

>> SV> А что прикажете делать, если частей text/plain несколько, и
>> SV> все в разных кодировках?
>> Ничего не делать.
VO> Нечитаемые заголовки.
Алгоритм можно упростить. Брать кодирвку того text/*, который
идет первым в теле. Все и баста.

>> SV> Если text/plain вообще нет, а есть text/html?  А если
>> SV> сверху
>> брать его кодировку.

VO> Которая в теге html по стандарту w3c тоже запрещена. charset
VO> в meta - очередной костыль. Кстати, в его полезности я не
VO> сомневаюсь ;), но пользоваться лучше всё-таки xhtml.
Блин.

VO> Кстати, если text/html тоже может быть несколько...
См. выше

>> SV> вообще multipart/encrypted, под ним multipart/signed, под
>> SV> ним... ?
>> Для encrypted в сабже вообще не будет ничего существенного ;)

VO> Будет, конверт не шифруется.

Я имею в виду - если письмо секретное, то чел, который пишет
этот секрет - не станет светить его в сабже. В этом смысле и
говорю "ничего существенного".

VO> Вот верите - RFC придумали не на коленке и тоже долго обсуждали.
Архивы этих дебатов есть?

VO> Есть предложение дальшейшее обсуждение бата перенести в talk-room
VO> (если там это не offtopic). Лично меня пинайте личным мылом, в
там ничто не offtopic ;)

VO> talk room не хожу.
Проблема - общесетевая и касается всех платформ, в том числе
юзеров ALT ;)

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

[Comm] Re: [JT] Так лучше?

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

On Tue, 29 Oct 2002 12:31:08 +0400
ASA <llb@udm.ru> wrote:

> Hello Vitaly,
> 
> Tuesday, October 29, 2002, 11:55:24 AM, you wrote:
> 
> >> SV> А что прикажете делать, если частей text/plain
> >несколько, и> SV> все в разных кодировках?
> >> Ничего не делать.
> VO> Нечитаемые заголовки.
> Алгоритм можно упростить. Брать кодирвку того text/*, который
> идет первым в теле. Все и баста.

А вот text/* может и не быть вообще.

<skipped/>

> >> Для encrypted в сабже вообще не будет ничего существенного
> >;)
> 
> VO> Будет, конверт не шифруется.
> 
> Я имею в виду - если письмо секретное, то чел, который пишет
> этот секрет - не станет светить его в сабже. В этом смысле и
> говорю "ничего существенного".

Ok.

> VO> Вот верите - RFC придумали не на коленке и тоже долго
> VO> обсуждали.
> Архивы этих дебатов есть?

http://www.ietf.org/
Но это, наверное, Вы и так знаете :)

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]