Параметры командной строки, стандартный подход для разбора? - PullRequest
4 голосов
/ 26 октября 2011

Я немного читал о том, как программы обрабатывают параметры командной строки. Но информация кажется «неполной», то, что я прочитал:

  • Опции могут иметь предшествующий знак «-» или «/» перед ними.
  • Опции могут иметь дополнительные аргументы (без знака -)
  • аргументы опции следуют за опцией напрямую, с пробелом или без него.
  • Опции могут быть одной буквой или полным словом.
  • параметры могут быть объединены в один «параметр»: -abc равно -a -b -c

(Источник)

Теперь мне действительно интересно: какие варианты вы даете знаком "-", а какие нет. Кроме того, объединение опций в 1 кажется несовместимым с опциями полного слова? «-file» может быть полным словом, но оно также может означать «-f», «-i», «-l», «-e», 4 разных ключа. Или даже: "-f" с "ile" в качестве option_argument.

Я что-то не так понимаю?

Ответы [ 2 ]

4 голосов
/ 26 октября 2011

В системах, таких как Linux, существует соглашение, что в полных словах используются две черты (например, --file), а в однобуквенных опциях используется одна черта (например, -f.)

Использование косой черты для ввода параметров взято из старой DOS и хранится в Windows.

Кроме того, если в параметре используется целое слово, его нельзя разделить на несколько вариантов. Это относится к вашему примеру с -file: -file может быть либо одним вариантом, либо четырьмя различными вариантами (-f, -i, -l и -e).

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

Я бы посоветовал вам найти способ, который вам нравится, и затем использовать его.

0 голосов
/ 09 ноября 2011

Не существует стандартов Windows для опций / аргументов / параметров и т. Д.

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

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

...