Короткие/длинные варианты с аргументом option - это какая-то конвенция?

Кажется, что большинство (очень много) команд реализуют аргументы параметров следующим образом:

  • если для короткой опции требуется аргумент параметра, параметр разделяется пробелом из аргумента параметра, например.

    $ head -n 10

  • Если для длинной опции требуется аргумент параметра, параметр разделяется символом = из аргумента параметра, например.

    $ head --lines=10

Это какая-то конвенция и да, где я могу ее найти? Кроме того, какие рассуждения?

Почему, например, это не

    $ head --lines 10

?

ОТВЕТЫ

Ответ 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 Спасибо, я согласен.)