Мой текущий рабочий скрипт на python использует getopts, так как он переписывает скрипт perl, который использовал Getopt :: Long. Я хотел бы перейти на argparse, но потерпел неудачу, поскольку параметры не вписываются в работу argparse.
У меня тогда была блестящая идея [?], Что если у меня в сценарии 2имена, например: foo-ssh & foo-rsync
и символическая ссылка foo-rsync на foo-ssh (более 90% сценария - это foo-ssh, опция rsync - это дополнение, которое не подходиткак вариант), тогда код в сценарии обрабатывает только параметры для конкретного имени, под которым он выполняется.
Я знаю о подпарсаторах, но это не совсем похоже на то, что я ищуи дал еще более уродливый и запутанный вывод справки, чем тот, с которого я начал.
Если я попытаюсь придерживаться как можно ближе к пути getopts с помощью argparse, я получу следующее:
usage: foo-ssh [-h] [--version] [--debug] [--forward-agent HOST:PORT]
[--ipv4] [--knock HOST:PORT]
[--libvirt-vnc HOST:PORT | --rsync]
[USER@]HOST
Что не так, это правильно, но неправильно.
Со страницы справки сценария perl:
Usage: foo-ssh <options> [USER@]HOST
foo-ssh <options> --knock HOST:PORT [USER@]HOST
foo-ssh <options> --libvirt-vnc HOST:PORT [USER@]HOST
foo-ssh <options> --rsync -- <rsync options> [USER@]HOST:/path/file.name /tmp
Что бы я хотел:
usage: foo-ssh [-h] [--version] [--debug] [--forward-agent HOST:PORT]
[--ipv4] [--knock HOST:PORT]
[--libvirt-vnc HOST:PORT]
[USER@]HOST
foo-rsync [OPTION...] [USER@]HOST:SRC... [DEST]
foo-rsync [OPTION...] SRC... [USER@]HOST:DEST
Во-первых, яЯ бью мертвую лошадь здесь? Все упражнение бессмысленно, если я получу тот же или более код для замены того, что уже работает.
Во-вторых, возможно ли это и что я ищу, чтобы добиться этого?
Сноска: пример кода на Perl не включен, так как он написан как бегемот, обозначающий его территорию своей собственной коркой (то есть: повсюду), что является одной из причин переписывания.