STDOUT и STDERR вышли из строя

С двумя отдельными дескрипторами файлов нет контракта или гарантии, что вы увидите их в реальном времени. На это влияют различные настройки и буферы, поэтому вы видите автоматическую очистку ($|). То же самое и с файлами, и с терминалом.

Поймите, что это архитектурная проблема, а не синтаксическая. За один и тот же ресурс конкурируют две вещи. Обычно это заканчивается слезами. Я не решаюсь предлагать решение, когда я не знаю, в чем проблема, но подумайте о том, чтобы все, что пытается написать, STDOUT или STDERR записывается в какой-то брокер сообщений, который собирает все сообщения и является единственным, что записывает в конечный (общий) пункт назначения. Например, вещи, которые хотят добавить записи в системный журнал, не записываются в системный журнал; они отправляют сообщения тому, что пишет в системный журнал.

Еще один пример Perly: в Log4perl вы не пишете в конечные пункты назначения. Вы просто регистрируете сообщение, и регистратор - единственное, что решает, как его обработать. Когда мне нужно такое поведение модуля, я не использую напрямую средства вывода:

debug( "Some debug message" );

sub debug {
    my $message = shift;
    output( "DEBUG: $message" );
    }

sub output { # single thing that can output message
    ...
    }

Затем делайте все, что вам нужно, в output.

Но вы не всегда можете контролировать это в других вещах, которые также пытаются что-то выводить. Perl позволяет вам обойти это, переопределив то, что делают warn и его друзья, поместив ссылку на код в $SIG{__WARN__}. Вы можете записывать предупреждающие сообщения и делать с ними все, что захотите (например, отправлять их на стандартный вывод). Помимо этого есть черная магия, которая вновь открывает STDERR то, что вы можете контролировать. Это не так уж и плохо, и он изолирован в одном месте.

В какой-то момент, когда другой человек не хочет объединять выходные данные, а навязчивые решения делают невозможным их разделение. Я бы предпочел гибкость жестко запрограммированным ограничениям. Если мне нужны только ошибки, мне нужен способ получить только ошибки. Есть много других способов обхода, например обертки, которые собирают как выходные потоки (так что совсем не навязчиво), так и различные перенаправления команд.

У вас будет два дескриптора файлов, пишущих в $logfile. Если File::Tee не позаботится о поиске конца дескриптора файла перед каждой записью (чего, по-видимому, не происходит), вы получите состояние гонки, при котором один дескриптор файла перезапишет другой.

Обходной путь - использовать параметр reopen для функции File::Tee::tee, которая будет закрывать файл после каждой записи и повторно открывать его (в правильном конце файла) перед следующей записью. Однако это может повредить вашей производительности, в зависимости от того, как часто вы пишете в эти дескрипторы файлов.

Возможно, вам больше повезет с IO::Tee, который является более простой реализацией (с использованием связанных файловых дескрипторов), чем то, что использует File::Tee (фоновый процесс для каждого File::Tee::tee вызова), поэтому вы можете получить меньше сюрпризов. Вот как может выглядеть IO::Tee решение:

use IO::Tee;
$| = 1;
open my $stdout, ">&=1";  # to write to original stdout
open my $stderr, ">&=2";  # to write to original stderr
open my $fh_log, ">>", $logfile;
*STDOUT = IO::Tee->new($stdout, $fh_log);
*STDERR = IO::Tee->new($stderr, $fh_log);
...

Нет никаких фоновых процессов, дополнительных потоков или чего-либо еще, что могло бы вызвать состояние гонки. И STDOUT, и STDERR будут писать в один и тот же дескриптор файла журнала из одного и того же процесса.

Примечание Первая часть выполняется с помощью привязных ручек; решение во второй части использует Capture::Tiny

Простое подтверждение концепции подхода с использованием маркеров tie -d.

Пакет, который связывает дескриптор, печатая из него в файл и в (копию) STDOUT потока

package DupePrints; 

use warnings; 
use strict; 
use feature 'say'; 

my $log = 't_tee_log.out'; 
open my $fh_out, '>', $log or die $!;  # for logging

# An independent copy of STDOUT (via dup2), for prints to terminal
open my $stdout, '>&', STDOUT or die $!;

sub TIEHANDLE { bless {} } 

sub PRINT { 
    my $self = shift; 

    print $fh_out @_; 
    print $stdout @_;
}

1;

Программа, которая его использует

use warnings;
use strict;
use feature 'say';

use DupePrints;    
$| = 1;
tie *STDERR, 'DupePrints';
tie *STDOUT, 'DupePrints';

say "hi";

warn "\t==> ohno";

my $y;
my $x = $y + 7;

say "done";

Это печатает как на терминал, так и на t_tee_log.out текст

hi
        ==> ohno at main_DupePrints.pl line 14.
Use of uninitialized value $y in addition (+) at main_DupePrints.pl line 17.
done

См. perltie и Tie :: Handle и этот пост со связанными примерами и, возможно, этим сообщением

Запись в файл потоков STDOUT и STDERR (вместе с копией распечатки) работает и в других модулях, которые также могут быть used в основной программе.

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

С уточнением в редакции вопроса, вот другой подход: оберните вызов в Capture :: Tiny, который захватывает весь вывод любого кода, а затем управляет захваченными отпечатками по мере необходимости.

use warnings;
use strict;
use feature qw(say state);

use Capture::Tiny qw(capture);

sub log_streams {
    my ($cr, @args) = @_;  # code reference, with its arguments

    # Initialize "state" variable, so it runs once and stays open over calls
    state $fh_log = do {
        open my $fh, '>', 'tee_log.txt' or die $!;
        $fh;
    };

    my ($out, $err, $exit) = capture { $cr->(@args) };

    if ($out) {
        print $fh_log $out;
        print         $out;
    }
    if ($err) {
        print $fh_log $err;
        print         $err;
    }
}

log_streams( sub { say "hi" } );
log_streams( sub { warn "==> ohno" } );
log_streams( sub { my $y; my $x = $y + 7; } );

log_streams( sub { system('perl', '-wE', q(say "external perl one-liner")) } );

log_streams( sub { say "done" } );

Обратной стороной всего этого является то, что все должно работать через этот суб. Но опять же, это действительно хорошо, даже если иногда и неудобно.

функция состояния используется для «инициализации» дескриптора файла, поскольку переменная, объявленная как state, никогда не инициализировался повторно; поэтому файл открывается только один раз при первом вызове и остается открытым.

Это также демоверсия, которую нужно доработать.

Получив подсказку из ответа @mob на использование IO :: Tie вместо File :: Tee (поскольку последний использует вилку, вызывающую нарушение порядка STDERR vs STDOUT), я немного изменил исходное решение моба, и оно сработало (почти - читайте дальше) :

use IO::Tee
...
...
open (my $log, ">", $logfilename) ;
*MYSTDOUT = *STDOUT ;
*MYSTDERR = *STDERR ;
*STDOUT = IO::Tee->new(\*MYSTDOUT, $log);
*STDERR = IO::Tee->new(\*MYSTDERR, $log);

Это привело к правильному порядку как на консоли, так и в файле журнала (исходное решение mob с использованием open to dup STDOUT / STDERR не сработало - это привело к правильному порядку в файле журнала, но не в порядке на консоли. Вместо этого использовался псевдоним typeglob of dup работает по какой-то странной причине).

Однако, как бы хорошо это ни звучало, оно пропустило печать некоторых сообщений из пакета, который я вызываю в файле журнала (хотя они печатаются на консоли). Мой исходный код, в котором был File :: Tee, действительно приводил к тому, что эти же сообщения из пакета отображались в файле журнала, так что где-то происходит какое-то вуду. Конкретный рассматриваемый пакет представляет собой файл .so, поэтому я не знаю, как именно он печатает свои сообщения.

РЕДАКТИРОВАТЬ: Я предполагаю, что файл .so так же хорош, как печать внешней системной команды на stdout / stderr. Поскольку он не проходит через ввод-вывод perl, дескрипторы, на которые указывают группы типов STDOUT / STDERR внутри perl, не будут отражать вывод внешних программ, вызываемых из perl. Я думаю, что лучшим решением было бы использовать комбинацию этого решения для сообщений, поступающих из кода perl, и использование Capture :: Tiny :: capture, как указано @zdim, для захвата и перенаправления сообщений из системных вызовов / вызовов, проходящих через интерфейс swig.