Каковы лучшие практики для реализации инструмента CLI в Perl?

Используйте POD для документирования своего инструмента, следуйте указаниям на страницах руководства; включите как минимум следующие разделы: ИМЯ, ОПИСАНИЕ, ОПИСАНИЕ, АВТОР. После того, как у вас есть надлежащий POD, вы можете сгенерировать справочную страницу с помощью pod2man, просмотреть документацию на консоли с помощью perldoc your-script.pl.

Используйте модуль, который обрабатывает параметры командной строки за вас. Мне очень нравится использовать Getopt :: Long в сочетании с Pod :: Usage . Таким образом, вызов --help отобразит красивое справочное сообщение.

Убедитесь, что ваши скрипты возвращают сообщение правильное значение выхода, если он был успешным или нет.

Вот небольшой скелет сценария, который выполняет все эти функции:

#!/usr/bin/perl

=head1 NAME

simplee - simple program

=head1 SYNOPSIS

    simple [OPTION]... FILE...

    -v, --verbose  use verbose mode
    --help         print this help message

Where I<FILE> is a file name.

Examples:

    simple /etc/passwd /dev/null

=head1 DESCRIPTION

This is as simple program.

=head1 AUTHOR

Me.

=cut

use strict;
use warnings;

use Getopt::Long qw(:config auto_help);
use Pod::Usage;

exit main();

sub main {

    # Argument parsing
    my $verbose;
    GetOptions(
        'verbose'  => \$verbose,
    ) or pod2usage(1);
    pod2usage(1) unless @ARGV;
    my (@files) = @ARGV;

    foreach my $file (@files) {
        if (-e $file) {
            printf "File $file exists\n" if $verbose;
        }
        else {
            print "File $file doesn't exist\n";
        }
    }

    return 0;
}

Some lessons I've learned:

1) Always use Getopt::Long

2) Provide help on usage via --help, ideally with examples of common scenarios. It helps people don't know or have forgotten how to use the tool. (I.e., you in six months).

3) Unless it's pretty obvious to the user as why, don't go for long period (>5s) without output to the user. Something like 'print "Row $row...\n" unless ($row % 1000)' goes a long way.

4) For long running operations, allow the user to recover if possible. It really sucks to get through 500k of a million, die, and start over again.

5) Separate the logic of what you're doing into modules and leave the actual .pl script as barebones as possible; parsing options, display help, invoking basic methods, etc. You're inevitably going to find something you want to reuse, and this makes it a heck of a lot easier.

На CPAN есть несколько модулей, которые значительно упростят написание программ CLI:

• App :: CLI
• App :: Cmd

Если ваше приложение основано на Moose, также обратите внимание на MooseX :: Getopt и MooseX :: Runnable

Самая важная вещь - иметь стандартные параметры .

Не пытайтесь быть умным , просто согласуйтесь с уже существующими инструментами .

Как для этого также важно , но только приходит секунда .

На самом деле, это довольно типично для всех интерфейсов CLI.

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

Следующие пункты не являются специфическими для Perl, но я обнаружил, что многие сценарии Perl CL имеют недостатки в этих областях:

1. Используйте общие параметры командной строки. Чтобы показать номер версии, используйте -v или --version, а не --ver. Для рекурсивной обработки -r (или, возможно, -R, хотя в моем опыте с Gnu / Linux чаще встречается -r), а не --rec. Люди будут использовать ваш сценарий, если они смогут запомнить параметры. Выучить новую команду легко, если вы помните, что «она работает как grep» или другую знакомую утилиту.

2. Многие инструменты командной строки обрабатывают «вещи» (файлы или каталоги) в «текущем каталоге». Хотя это может быть удобно, убедитесь, что вы также добавили параметры командной строки для явной идентификации файлов или каталогов для обработки. Это упрощает включение вашей утилиты в конвейер без того, чтобы разработчикам приходилось вводить кучу команд cd и помнить, в каком каталоге они находятся.