Ответ 1
Обоснование коротких опций описано в POSIX Соглашения об утилитах. Большинство парсеров параметров позволяют привязать значение к букве (-n10
), главным образом из-за обширного исторического прецедента.
Длинное опционное обоснование определяется GNU в их Стандартах кодирования и на странице руководства getopt_long()
.
Когда-то давно, в StackOverflow давным-давно, возник вопрос о стилях параметров команды. Не очень хороший вопрос, но я думаю, что ответы спасли его (но я допускаю предубеждение). Во всяком случае, с тех пор он был удален, поэтому я собираюсь реанимировать свой ответ здесь, потому что (а) это был болезненный процесс, чтобы заново открыть ответ и (б) он имеет полезную информацию в нем, связанную с параметрами.
Сколько различных типов опций вы узнаете? Я могу думать о многих, в том числе:
- Однобуквенные опции, которым предшествует одиночная тире, сгруппированы, когда нет аргумента, аргумент может быть присоединен к букве опциона или в следующем аргументе (многие, многие команды Unix, большинство команд POSIX).
- Однобуквенные опции, которым предшествует одиночная тире, группировка недопустима, аргументы должны быть присоединены (RCS).
- Однобуквенные опции, которым предшествует одиночная тире, группировка недопустима, аргументы должны быть отдельными (pre-POSIX SCCS, IIRC).
- Многобуквенные параметры, которым предшествует одна тире, аргументы могут быть присоединены или в следующем аргументе (программы X11).
- Многобуквенные опции, которым предшествует одиночная тире, могут быть сокращены (Atria Clearcase).
- Многобуквенные опции, которым предшествует одиночный плюс (устаревший).
- Многобуквенные опции, которым предшествует двойная тире; аргументы могут следовать за "=" или быть отдельными (утилиты GNU).
- Параметры без префикса/суффикса, некоторые имена имеют аббревиатуры или подразумеваются, аргументы должны быть раздельными. (AmigaOS Shell, добавленный porneL)
Параметры, требующие необязательного аргумента, иногда должны быть прикреплены, иногда должны следовать знаку '='. POSIX не поддерживает значимые необязательные аргументы (POSIX getopt() позволяет им использовать только последний параметр в командной строке).
Все разумные системы опций используют параметр, состоящий только из двойной тире ('--
'), что означает "конец опций" - следующие аргументы - это "необязательные аргументы" (обычно имена файлов), даже если они начинаются с тире. (Я считаю, что это обозначение является императивом.) Обратите внимание, что если у вас есть команда cmd
с опцией -f
, которая ожидает аргумент, то если вы вызываете ее с помощью --
вместо аргумента (cmd -f -- -other
, многие версии getopt()
будут обрабатывать --
как имя файла для -f
, а затем анализировать -other
как обычные параметры. То есть --
не останавливает параметры, если их нужно интерпретировать как аргумент другому параметру.
Многие, но не все программы принимают одиночную тире в качестве имени файла для обозначения стандартного ввода (обычно) или стандартного вывода (иногда). Иногда, как и в случае с GNU 'tar
', оба они могут использоваться в одной командной строке:
tar -cf - -F - | ...
Первая персональная тире означает 'write to stdout'; второй означает "читать имена файлов из stdin".
Некоторые программы используют другие условные обозначения — то есть параметры, которым не предшествует тире. Многие из них относятся к самым старым дням Unix. Например, "tar" и "ar" принимают параметры без тире, поэтому:
tar cvzf /tmp/somefile.tgz some/directory
Команда dd
использует opt=value
исключительно:
dd if=/some/file of=/another/file bs=16k count=200
Некоторые программы позволяют полностью чередовать параметры и другие аргументы; примерами являются компилятор C, make и утилиты GNU без POSIXLY_CORRECT в среде. Многие программы ожидают, что опции будут предшествовать другим аргументам.
В современных программах, таких как git
, все чаще используется базовое имя команды (git
), за которым следует подкоманда (commit
), а затем параметры (-m "Commit message"
). Это было задано интерфейсом sccs
для команд SCCS, а затем cvs
и также используется svn
(и все они являются системами контроля версий). Тем не менее, другие большие группы команд используют аналогичные стили, когда это кажется уместным.
У меня нет сильных предпочтений между различными системами. Если вариантов достаточно, то удобны одиночные буквы с мнемоническим значением. GNU поддерживает это, но рекомендует создать резервную копию с многобуквенными опциями, которым предшествует двойная тире.
Есть некоторые вещи, на которые я возражаю. Одно из худших - это одно и то же письмо варианта, используемое с разными значениями в зависимости от того, какие другие буквы опций предшествуют ему. В моей книге, что нет-нет, но я знаю программное обеспечение, где это делается.
Другим нежелательным поведением является несогласованность в стиле обработки аргументов (особенно для одной программы, но также и в рамках набора программ). Любой из них требует приложенных аргументов или требует отделить аргументы (или разрешить их), но не имеет некоторых параметров, требующих прикрепленного аргумента, а другим - требуемого отдельного аргумента. И будьте последовательны в отношении того, может ли "=
" использоваться для разделения опции и аргумента.
Как и многие, многие (связанные с программным обеспечением) вещи — согласованность важнее индивидуальных решений.
Что бы вы ни делали, прочитайте Параметры командной строки TAOUP и рассмотрите Стандарты для интерфейсов командной строки. (Добавлено J F Sebastian Спасибо, я согласен.)