Какую сеть безопасности вы используете в Perl?

Question

Какую страховочную сеть вы используете?

используйте предупреждения;

или

используйте строгий;

Я знаю, что

Потенциальная проблема, обнаруженная при строгом использовании;приведет к немедленной остановке вашего кода при обнаружении предупреждений;просто выдаст предупреждение (например, ключ командной строки -w) и позволит запустить ваш код.

Тем не менее, я хочу знать, какой из них чаще всего используется Perl-программистами.Кого из них они видели больше всего?

Answer 1

Оба, конечно.Если бы Perl был разработан сегодня, используйте строгое и используйте предупреждения по умолчанию.Это похоже на включение предупреждений в компиляторе - почему бы вам не сделать это по умолчанию?

Answer 2

То, что у вас есть, даже не начинает быть достаточным.

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

#!/usr/bin/env perl

use v5.12;
use utf8;
use strict;
use autodie;
use warnings; 
use warnings    qw< FATAL utf8      >;
use feature     qw< unicode_strings >;
use open        qw< :std  :utf8     >;
use charnames   qw< :full           >;

# These are core modules:
use Carp                qw< carp croak confess cluck >;
use File::Basename      qw< basename        dirname >;
use Unicode::Normalize  qw< NFD NFKD       NFC NFKC >;
use Getopt::Long        qw< GetOptions              >;
use Pod::Usage          qw< pod2usage               >;

our $VERSION = v0.0.1;

$0 = basename($0);  # shorter messages
## $| = 1;

$SIG{__DIE__} = sub {
    confess "Uncaught exception: @_" unless $^S;
};

$SIG{__WARN__} = sub {
    if ($^S) { cluck   "Trapped warning: @_" } 
    else     { confess "Deadly warning: @_"  }
};

END { 
    local $SIG{PIPE} = sub { exit };
    close STDOUT;
}

if (grep /\P{ASCII}/ => @ARGV) {
   @ARGV = map { decode("UTF-8", $_) } @ARGV;
}

binmode(DATA, ":utf8");

## Getopt::Long::Configure qw[ bundling auto_version ];

if (!@ARGV && -t STDIN) {
    print STDERR "$0: reading from stdin: type ^D to end, ^C to kill...\n";
} 

while (<>) {
    $_ = NFD($_);
    # ...
    print NFC($_);
}

exit;

=pod

=encoding utf8

=head1 NAME

=head1 SYNOPSIS

=head1 DESCRIPTION

=head1 OPTIONS

=head1 EXAMPLES

=head1 ERRORS   

=head1 FILES

=head1 ENVIRONMENT

=head1 PROGRAMS

=head1 AUTHOR

=head1 COPYRIGHT AND LICENCE

=head1 REVISION HISTORY

=head1 BUGS

=head1 TODO

=head1 SEE ALSO

=cut

__END__

Your UTF-8 data goes here.

Вы можете найти больше примеров такого рода вещей в действии в Perl Сундук с инструментами Unicode , в настоящее время до 50 файлов в диапазоне от простых до возвышенных.

Answer 3

use strict генерирует ошибку, если вы используете символьные ссылки (т. Е. Строки для представления имен символов).Он генерирует ошибку, если вы используете переменную, не объявляя ее (это поощряет использование лексических переменных 'my', но также будет удовлетворено, если вы правильно объявите глобальные переменные пакета).Он также генерирует ошибку, если вы оставляете в скрипте голые слова (строки без кавычек, по сути, по определению кавычек в Perl).С 'strict' вы можете включить или отключить любую из трех категорий стриктур, и я могу сделать это в пределах блоков с ограничениями.Рекомендуется включать ограничения, хотя иногда законный код требует, чтобы некоторые его функции были отключены локально.Однако нужно долго и усердно думать о том, действительно ли это необходимо, и является ли их решение идеальным.Вы можете прочитать о стриктурах в POD Perl под названием «строгий».

use warnings генерирует предупреждающее сообщение на основе многих критериев, которые описаны в POD «perllexwarn».Эти предупреждения не имеют ничего общего со стриктурами, а, скорее, следят за наиболее распространенными "хитростями", с которыми можно столкнуться при программировании.Рекомендуется также использовать предупреждения при написании сценариев.В некоторых случаях, когда сообщение может быть нежелательным, определенная категория предупреждений может быть локально отключена в области действия.Дополнительная информация описана в «предупреждениях».

use diagnostics делает предупреждения более многословными, и в среде разработки или обучения, особенно среди новичков, это крайне желательно.Диагностика, вероятно, не будет включена в «конечный продукт», но в процессе разработки она может быть действительно хорошим дополнением к кратким сообщениям, которые обычно генерируются.Вы можете прочитать о диагностике в Perl POD «диагностика».

Нет причин заставлять себя использовать только один из перечисленных выше вариантов или другой.В частности, используйте предупреждения и используйте строгий, как правило, оба должны использоваться в современных программах на Perl.

Во всех случаях (кроме диагностики, которую вы все равно используете только для разработки), отдельные ограничения или предупреждения могут быть лексически отключены.,Кроме того, их ошибки могут быть перехвачены с помощью eval{ .... }, с помощью блоков try / catch Try::Tiny и несколькими другими способами.Если существует беспокойство по поводу сообщения, дающего потенциальному злоумышленнику больше информации о скрипте, сообщения могут быть направлены в лог-файл.Если существует риск того, что указанный лог-файл будет занимать много места, имеется более серьезная проблема, и источник проблемы следует либо устранить, либо в некоторых редких случаях просто отключить сообщение.

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

Answer 4

Используйте оба, как сказано на связанной странице.

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

Answer 5

use strict;
#use warnings;
use diagnostics; # "This module extends the terse diagnostics..." by http://perldoc.perl.org/diagnostics.html

Оба! Но я предпочитаю диагностику, а не предупреждения, которые дают вам больше информации.