Подтвердить что ты не робот

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

Я использую инструмент CLI с использованием Perl. Каковы наилучшие методы, которыми мы можем следовать здесь?

4b9b3361

ОТВЕТЫ

Ответ 1

В качестве предисловия я потратил 3 года на разработку и внедрение довольно сложного набора инструментов командной строки в Perl для крупной финансовой компании. Представленные ниже идеи в основном являются частью руководящих принципов разработки нашей команды.

Пользовательский интерфейс

  1. Параметр командной строки: разрешить как можно большему количеству значений по умолчанию.

  2. НЕТ позиционных параметров для любой команды, которая имеет более 2 опций.

  3. Иметь читаемые варианты названий. Если длина командной строки является проблемой для неинтерактивных вызовов (например, некоторые неназванные устаревшие оболочки имеют короткие ограничения на командные строки), предоставьте короткие псевдонимы - GetOpt :: Long позволяет это легко.

  4. Как минимум, выведите все значения параметров по умолчанию в сообщении -help.

    А еще лучше вывести все "текущие" значения параметров (например, если параметр и значение указываются вместе с "-help", в справочном сообщении будет напечатано значение параметра из командной строки). Таким образом, люди могут собрать строку командной строки для сложной команды и проверить ее, добавив "-help" перед тем, как запускать.

  5. Следуйте стандартному соглашению Unix о выходе с ненулевым кодом возврата, если программа завершилась с ошибками.

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

  7. В идеале, разрешите пользователю указывать файлы ввода/вывода с помощью параметра командной строки вместо принудительного перенаправления "<"/">" - это позволяет НАМНОГО упростить жизнь людям, которым нужно строить сложные каналы с использованием вашей команды. То же самое для сообщений об ошибках - есть опция logfile.

  8. Если у команды есть побочный эффект, наличие опции "whatif/no_post" обычно является очень хорошей идеей.

Реализация

  1. Как отмечалось ранее, не изобретайте колесо заново. Используйте стандартные модули обработки параметров командной строки - MooseX :: Getopt или Getopt :: Long

  2. Для Getopt :: Long присвойте все параметры одному хешу, а не отдельным переменным. Многие полезные шаблоны включают в себя передачу этого хэш-аргумента CLI конструкторам объектов.

  3. Убедитесь, что ваши сообщения об ошибках четкие и информативные... Например, включите "$!" в любых сообщениях об ошибках, связанных с IO. Стоит потратить лишние 1 минуту и 2 строки в коде, чтобы иметь отдельные ошибки "файл не найден" и "файл не читается", в отличие от того, чтобы тратить 30 минут в аварийной ситуации на производстве, потому что "Производственная ошибка" была ошибочно диагностирована производством. Операции как "Нет входного файла" - это пример из реальной жизни.

  4. Не совсем специфично для CLI, но проверяет все параметры, в идеале сразу после их получения. CLI не допускает "фронтальную" проверку, как это делают веб-приложения, поэтому будьте очень бдительны.

  5. Как обсуждалось выше, модульная бизнес-логика. Среди других причин, перечисленных выше, количество раз, когда мне приходилось перестраивать существующий инструмент CLI в качестве веб-приложения, огромно - и не так сложно, если логика уже является правильно разработанным модулем perm.

Интересные ссылки

CLI Design Patterns - я думаю, что это ESR

Я постараюсь добавить больше пуль, когда я их вспоминаю.

Ответ 2

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

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

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

Вот небольшой скелет a script, который делает все это:

#!/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;
}

Ответ 3

Некоторые уроки, которые я узнал:

1) Всегда используйте Getopt:: Long

2) Предоставьте помощь по использованию через --help, в идеале с примерами общих сценариев. Это помогает людям не знать или забыть, как использовать этот инструмент. (I.e., вы через шесть месяцев).

3) Если это не кажется очевидным для пользователя, почему бы не пойти на длительный период ( > 5 секунд) без вывода пользователю. Что-то вроде "print" Строка $row...\n "если только ($ row% 1000)" идет длинный путь.

4) Для длительных операций, позвольте пользователю восстановить, если это возможно. Это действительно отстой, чтобы пройти через 500 000 миллионов, умереть и начать заново.

5) Отделите логику того, что вы делаете в модулях, и оставьте фактический .pl script в качестве barebones, насколько это возможно; варианты разбора, отображение справки, вызов основных методов и т.д. Вы неизбежно найдете что-то, что хотите повторно использовать, и это делает его намного проще.

Ответ 5

Самое главное - иметь стандартные опции.

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

Как, чтобы достичь этого, также важно, но только второй.

Собственно, это довольно общее для всех интерфейсов CLI.

Ответ 6

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

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

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