Короткие/длинные варианты с аргументом 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 Спасибо, я согласен.)