ошибка perl, когда закрываются STDIN, STDOUT и STDERR?

Question

При написании демона я хочу закрыть STDIN, STDOUT и STDERR для «хорошего поведения демона». Но я удивился. Для последующего открытия файлов требуются те же свойства, что и у старых STDIN, STDOUT и STDERR (потому что их fileno-ы были повторно открыты?)

Вот это предупреждение.pl:

use warnings;

my $nrWarnings = 0;
$SIG{__WARN__} = sub {
    no warnings;
    $nrWarnings++;
    open my $log, '>>', '/tmp/log.txt'
        or die;
    printf $log "%d: %s", $nrWarnings, @_;
    close $log;
};

close STDOUT;
close STDERR;
close STDIN;

open my $o, '>', '/tmp/foobar.txt'
    or die;
open my $i, '<', '/etc/passwd'
    or die;
open my $i2, '<', '/etc/passwd'
    or die;
open my $i3, '<', '/etc/passwd'
    or die;

exit $nrWarnings;

И вот я запускаю это:

> rm -f /tmp/log.txt ; perl warn.pl; echo $? ; cat /tmp/log.txt 
3
1: Filehandle STDIN reopened as $o only for output at warn.pl line 20.
2: Filehandle STDOUT reopened as $i only for input at warn.pl line 22.
3: Filehandle STDERR reopened as $i2 only for input at warn.pl line 24.

Я не ожидал предупреждений и $? == 0. Где ошибка? В моем коде или в Perl?

Это может выглядеть как Как я могу заново инициализировать Perl STDIN / STDOUT / STDERR? , но там было принято решение закрыть STDIN, STDOUT и STDERR, как я.

Answer 1

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

Этовполне законно подавлять предупреждения, когда вы уверены, что знаете, что делаете.В этом случае вы просто добавили бы no warnings 'io'; перед своими open с.

Answer 2

Теперь, сразу после нажатия кнопки отправки, я думаю о поиске в perldoc perldiag, и там есть текст предупреждения. Это приводит меня к ошибке Perl # 23838 , которая в основном гласит: «Ну, не закрывайте эти маркеры, вместо этого снова откройте их в« / dev / null »».

И ошибка помечается как исправленная после этого.

Я не согласен с тем, что повторное открытие в '/ dev / null' является правильным способом (tm), но теперь мы рискуем прийти к мнению, которое не по теме для stackoverflow, поэтому я отмечу это как ответ. *

Извините за шум.