Одиночные черточки `-` для односимвольных опций, но двойные черточки` --` для слов?

Откуда взялось соглашение об использовании одинарных тире для букв и двойных тире для слов и почему оно продолжает использоваться?

Например, если я наберу ls --help, вы увидите:

  -a, --all                  do not ignore entries starting with .
  -A, --almost-all           do not list implied . and ..
      --author               with -l, print the author of each file
  -b, --escape               print octal escapes for nongraphic characters
      --block-size=SIZE      use SIZE-byte blocks
  -B, --ignore-backups       do not list implied entries ending with ~
...

Я пытался гуглить - and -- conventionдаже с цитатами без особого успеха.

В книге «Искусство программирования Unix» Эрик Стивен Рэймонд описывает, как развивалась эта практика:

В оригинальной традиции Unix параметры командной строки - это отдельные буквы, перед которыми стоит один дефис ... Оригинальный стиль Unix развивался на медленных телетайпах ASR-33, которые делали краткость добродетелью; таким образом, однобуквенные варианты. Удерживание клавиши Shift потребовало фактического усилия; таким образом, предпочтение в нижнем регистре и использование «-» (а не, возможно, более логичный «+») для включения опций.

Стиль GNU использует ключевые слова параметров (а не буквы ключевых слов), перед которыми стоят два дефиса. Он развивался годами позже, когда в некоторых из довольно сложных утилит GNU стали заканчиваться однобуквенные ключи опций ( это представляло собой патч для симптома, а не лекарство от основного заболевания ). Он остается популярным, потому что опции GNU легче читать, чем алфавитный суп старых стилей. ¹

[1] http://www.faqs.org/docs/artu/ch10s05.html

Одной из причин для продолжения использования одиночных вариантов письма, потому что они могут быть нанизанные: ls -ltrэто намного проще , чем набрать ls --sort=time --reverse --format=long. Есть несколько случаев, когда оба хороши для использования. Что касается поиска по этой теме, попробуйте "соглашение о параметрах командной строки Unix".

Цитата из Raymond по @jasonwryan имеет некоторую полезную информацию, но начинается в середине истории:

• Имейте в виду, что Unix начинался как версия Multics с ограниченной областью действия, и что на протяжении всей своей истории функции Unix часто были имитацией или адаптацией функций, замеченных и используемых в других системах.
• '-'Вариант символ был использован в Multics. Bitsavers имеет руководство для своих пользовательских команд .
• В других системах использовались разные символы, некоторые с большей заявленностью более эффективны при нажатии клавиш (например, '/'используемые для TOPS и VMS), а некоторые - менее (например, '('используемые в CMS VM / SP).
• MULTICS варианты были несколько символов, например, ключевые слова разделены подчеркиванием.
• Более длинные варианты Multics часто имеют более короткую сокращенную форму, например, -printvs -pr(стр. 3-8).
• Варианты Unix были односимвольными и через несколько лет getoptбыли введены. Поскольку он не был частью оригинального Unix, есть утилиты, которые не использовались getoptи были оставлены как есть. Но getoptпомогая сделать программы последовательными.

С другой стороны, используемые опции Unix getoptбыли односимвольными. Другие системы, в частности все более крупные, использовали ключевые слова. Некоторые (не все) допускают сокращение этих ключевых слов , т. Е. Не все символы предоставляются, если параметр был однозначным. В этом тесте на неоднозначность есть подводные камни. Например:

• В начале 1985 года я работал над программой, которую нужно было перенести в PrimOS . Разработчики Prime конкурировали с несколькими другими компаниями, предлагая командный язык, который (пытался) имитировать каждый из этих других, предоставляя наиболее часто используемые команды от каждого. Конечно, они поддержали сокращения (как и VMS). Прочитав онлайн-справку, я набрал sta, подумав получить status. Это была аббревиатура start, и, не дав ничего начать , интерпретатор команд отключил меня.
• Набор инструментов X (используемый xterm ) позволяет использовать сокращенные параметры. Чтобы эффективно использовать это в xterm, он должен предварительно обработать параметры команды, чтобы предпочесть -v(для версии), чем -vb(визуальный звонок). X Toolkit не имеет прямого способа указать предпочтительный вариант, когда есть неоднозначность.

Из-за этой потенциальной неопределенности некоторые разработчики предпочитают не допускать сокращений. Например, Lynx использует многосимвольные параметры без аббревиатур.

Не все программы использованы getopt: так tarи psнет. Как и rcs(или sccs), как вы можете заметить, отметив, где тире был необязательным, а значения параметров были необязательными.

Принимая все это во внимание, разработчики GNU адаптировали опции ключевых слов, используемые в других системах, расширив их, getoptчтобы предоставить длинную версию каждой короткой опции. Например, в журнале изменений textutils 1.0 написано

Tue May  8 03:41:42 1990  David J. MacKenzie  (djm at abyss)

        * tac.c: Use regular expressions as the record boundaries.
        Give better error messages.
        Reformat code and make it more readable.
        (main): Use getopt_long to parse options.

Изменение в fileutils было ранее:

Tue Oct 31 02:03:32 1989  David J. MacKenzie  (djm at spiff)

        * ls.c (decode_switches): Add long options, using getopt_long
        instead of getopt.

и кто-то может найти его еще раньше, но кажется, что заголовок файла показывает самую раннюю дату:

/* Getopt for GNU.
   Copyright (C) 1987, 1989 Free Software Foundation, Inc.

который (например) совпадает с X Toolkit (1987). Большинство утилит Unix, с которыми вы знакомы (например ls, ps), использовали существующие односимвольные опции, которые требуют периодического посещения руководства. При представлении getopt_longразработчики GNU не делали этого, сначала добавляя новые опции; они начали с табулирования существующих опций и предоставления соответствующей длинной опции.

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

Эти программы продолжают использовать getopt_longтаким образом по обычным причинам:

• сценарии зависят от параметров; разработчики не хотят ломать скрипты
• есть письменный стандарт кодирования (который может быть эффективным)
• никто не придумал конкурирующий набор инструментов, который явно несовместим (разработчики BSD и GNU копируют названия опций друг у друга)

В википедии интерфейс командной строки сообщается:

В Unix-подобных системах ASCII-дефис-минус обычно используется для указания опций. За символом обычно следуют одна или несколько букв. Аргумент, который является единственным дефисом-минусом сам по себе без каких-либо букв, обычно указывает, что программа должна обрабатывать данные, поступающие со стандартного ввода, или отправлять данные на стандартный вывод. Два дефиса-минус (()) используются в некоторых программах для указания «длинных опций», где используются более описательные имена опций. Это общая черта программного обеспечения GNU.

Я предполагаю, что было желательно больше описательных опций, а также с более длинными опциями, вам не придется беспокоиться об исчерпании односимвольных опций.

Как только вы решите, что вам нужны длинные варианты, у вас возникнет проблема, по крайней мере, если вы планируете поддерживать как длинные, так и короткие варианты. Я не уверен, но я полагаю, что ответ arcege содержит ключ к тому, почему - и -. Общая процедура обработки, например getopt_long (), необходимо знать, может ли один аргумент командной строки содержать несколько параметров, например. -ltr. Таким образом, подпрограмма обработки должна была бы иметь возможность различать два. Если я прочитаю одну черту, -, то остальная часть аргумента командной строки может соответствовать нескольким параметрам. Если я прочитаю двойную черту, -, то остальная часть аргумента командной строки должна соответствовать одной опции.

Я только недавно использовал getopt_long (), и мне начинают нравиться длинные опции, так как они легче запомнить и самодокументируются. Если у меня есть следующие две команды:

./aggregator -f 15

./aggregator --flush-time 15

Я бы сказал, что второй, использующий опцию long, более понятен.

Вероятно, есть несколько причин, по которым используются два метода. Одним из них, конечно же, является традиция. Программисты и пользователи - люди, и люди ожидают, что все будет работать определенным образом. Если нет причин для изменения (и действительно, для командной строки не так много причин для изменения), то не делайте этого.

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

Когда я изучал разницу между ними (и до того, как она стала второй натурой), я всегда помнил, что «короткий» дефис соответствует «коротким» вариантам, а «длинный» (или двойной) дефис соответствует «длинному». параметры. Я не знаю, использовались ли эти рассуждения при разработке стиля двойных дефисов, но это возможно.