Одиночні тире "-` для однозначних параметрів, а подвійні тире" - "для слів?

Звідки взялася умова використання одинарних тирев для букв та подвійних тире для слів і чому продовжує застосовуватися?

Наприклад, якщо я набираю текст 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 Eric Steven Raymond описує , як ця практика розвивалася:

У оригінальній традиції Unix параметри командного рядка - це одні літери, яким передує окремий дефіс ... Оригінальний стиль Unix розвивався на повільних телетипах ASR-33, що зробило терміновість добродією; таким чином однолітерні варіанти. Утримування клавіші зсуву вимагало фактичних зусиль; таким чином перевага в нижньому регістрі та використання “-” (а не можливо більш логічне “+”) для включення параметрів.

У стилі 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), а деякі менші (наприклад, що '('використовуються у VM / SP CMS).
• MULTICS варіанти були кілька символів, наприклад, ключові слова розділені підкресленням.
• Параметри довших мультимедійних файлів часто мали більш коротку, скорочену форму, наприклад -printvs -pr(стор. 3-8).
• Варіанти Unix були однозначними, і через кілька років getoptбуло введено. Оскільки він не входив до оригінального Unix, є утиліти, які не використовувались getoptта залишалися як є. Але getoptдопомогли зробити послідовні програми.

З іншого боку, використовувані параметри Unix getoptбули однозначними. Інші системи, зокрема всі більші, використовували ключові слова. Деякі (не всі) дозволили скоротити ці ключові слова , тобто не всі символи надані до тих пір, поки параметр був однозначним. У цьому тесті є підводні камені на неоднозначність. Наприклад:

• На початку 1985 року я працював над програмою, яку довелося перенести в PrimOS . Розробники Prime конкурували з кількома іншими компаніями, пропонуючи мову команд, яка (намагалася) наслідувати кожну з цих інших, надаючи команди, що найчастіше використовуються. Звичайно, вони підтримували абревіатури (як і VMS). Прочитавши Інтернет-допомогу, я набрав sta, думаючи отримати status. Це було абревіатурою для start, і, не даючи нічого для початку , інтерпретатор команд відійшов від мене.
• X Toolkit (використовується 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.

Зміна файлевих програм була раніше:

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.

Я здогадуюсь, що потрібні були більш описові варіанти, а також із довшими варіантами, вам не доведеться турбуватися про те, що не вичерпаються варіанти одного символу.

Як тільки ви вирішите, що вам потрібні довгі варіанти, у вас виникне проблема, принаймні, якщо ви плануєте підтримувати і довгі, і короткі варіанти. Я не позитивний, але я вважаю, що відповідь Арджежа є ключовим щодо того, чому - і -. Загальний розпорядок обробки, наприклад. getopt_long (), повинен знати, чи може аргумент одного командного рядка містити кілька варіантів, наприклад. -ltr. Таким чином, процедура обробки повинна мати можливість розмежовувати їх. Якщо я прочитав один тире, -, тоді решта аргументу командного рядка може відповідати декільком параметрам. Якщо я прочитав подвійний тире, -, тоді решта аргументу командного рядка повинна відповідати одному параметру.

Нещодавно я скористався getopt_long () і мені починають подобатися довгі варіанти, оскільки їх легше запам’ятовувати та самостійно документувати. Якщо у мене є дві наступні команди:

./aggregator -f 15

./aggregator - час змивання 15

Я б сказав, що другий варіант, що використовує довгий варіант, є більш зрозумілим.

Ймовірно, є кілька причин того, що ці два методи використовуються. Одне, звичайно, традиція. Програмісти та користувачі - це людина, і люди очікують, що справи працюватимуть певним чином. Якщо немає причини змінюватись (і справді, для командного рядка причин для зміни не так багато), тоді не робіть цього.

Якщо говорити, я знаю, що є інструменти, які використовують один дефіс для тривалого вибору або взагалі позбавляються від дефісів. Спочатку ці інструменти можуть бути важкими і, як правило, стирчать як бородавки в інакше об'єднаній системі.

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