Trattini singoli `-` per le opzioni a carattere singolo, ma trattini doppi` --` per le parole?

Da dove viene la convenzione di usare singoli trattini per le lettere e raddoppia i trattini per le parole e perché continua ad essere usata?

Ad esempio, se scrivo ls --help, vedrai:

  -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 ~
...

Ho provato a cercare su Google - and -- conventionanche con le virgolette con scarso successo.

In The Art of Unix Programming Eric Steven Raymond descrive come si è evoluta questa pratica:

Nella tradizione originale di Unix, le opzioni della riga di comando sono singole lettere precedute da un singolo trattino ... Lo stile originale di Unix si è evoluto su teletipi lenti ASR-33 che hanno reso la terseness una virtù; quindi le opzioni a lettera singola. Tenere premuto il tasto MAIUSC richiede uno sforzo effettivo; quindi la preferenza per le lettere minuscole e l'uso di “-” (piuttosto che forse il “+” forse più logico) per abilitare le opzioni.

Lo stile GNU utilizza le parole chiave delle opzioni (anziché le lettere delle parole chiave) precedute da due trattini. Si è evoluto anni dopo, quando alcune delle utility GNU piuttosto elaborate hanno iniziato a rimanere senza chiavi di opzione a lettera singola ( questo costituiva una patch per il sintomo, non una cura per la malattia di base ). Resta popolare perché le opzioni GNU sono più facili da leggere rispetto alla zuppa alfabetica degli stili più vecchi. ¹

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

Uno dei motivi per continuare a utilizzare le opzioni a lettera singola è perché possono essere uniti: ls -ltrè molto più facile da digitare di ls --sort=time --reverse --format=long. Ci sono molte volte in cui entrambi sono buoni da usare. Per quanto riguarda la ricerca di questo argomento, provare "convenzione opzioni opzioni riga di comando unix".

La citazione di Raymond di @jasonwryan contiene alcune informazioni utili, ma inizia nel mezzo della storia:

• Tieni presente che Unix è iniziato come una versione a ambito ridotto di Multics e che nel corso della sua storia, le funzionalità di Unix erano spesso imitazioni o adattamenti di funzionalità viste e utilizzate su altri sistemi.
• Il '-'carattere opzione è stato utilizzato in Multics. Bitsavers ha un manuale per i suoi comandi utente .
• Altri sistemi utilizzavano caratteri diversi, alcuni con una maggiore pretesa di essere più efficienti da tastiera (come quelli '/'usati per TOPS e VMS) e altri meno (come quelli '('usati in VM / SP CMS).
• Le opzioni Multics erano multi-carattere, ad esempio parole chiave separate da trattino basso.
• Le opzioni Multics più lunghe hanno spesso una forma abbreviata, più breve, come -printvs -pr(pagina 3-8).
• Le opzioni Unix erano a carattere singolo e, dopo diversi anni, getoptfurono introdotte. Poiché non faceva parte della versione originale di Unix, esistono utilità che non sono state utilizzate getopte sono rimaste così come sono. Ma aver getoptcontribuito a rendere coerenti i programmi.

D'altra parte, le opzioni Unix che utilizzavano getopterano a carattere singolo. Altri sistemi, in particolare tutti quelli più grandi, utilizzavano parole chiave. Alcuni (non tutti) hanno permesso di abbreviare quelle parole chiave , ovvero non tutti i caratteri forniti purché l'opzione non fosse ambigua. Ci sono insidie ​​in quel test per l'ambiguità. Per esempio:

• all'inizio del 1985, stavo lavorando a un programma che doveva essere portato su PrimOS . Gli sviluppatori di Prime hanno gareggiato con diverse altre società offrendo un linguaggio di comando che (ha cercato di) imitare ognuna di quelle altre, fornendo i comandi più comunemente usati da ciascuna. Ovviamente, hanno supportato le abbreviazioni (così come VMS). Dopo aver letto la guida in linea, ho digitato sta, pensando di ottenere status. Era l'abbreviazione di start, e non avendo dato nulla per iniziare , l'interprete dei comandi mi ha disconnesso.
• X Toolkit (utilizzato da xterm ) consente opzioni abbreviate. Per usarlo efficacemente in xterm, deve preelaborare i parametri di comando da preferire -v(per la versione) rispetto a -vb(visual bell). X Toolkit non ha un modo diretto per specificare un'opzione preferita in caso di ambiguità.

A causa di questo potenziale di ambiguità, alcuni sviluppatori preferiscono non consentire le abbreviazioni. Lynx , ad esempio, utilizza opzioni multi-carattere senza consentire abbreviazioni.

Non tutti i programmi utilizzati getopt: tare psnon lo hanno fatto. Nemmeno rcs(o sccs), come puoi vedere notando dove il trattino era facoltativo e i valori delle opzioni erano facoltativi.

Tenendo conto di tutto ciò, gli sviluppatori GNU hanno adattato le opzioni di parole chiave utilizzate in altri sistemi estendendosi getoptper fornire una versione lunga di ciascuna opzione breve. Ad esempio, dice il log delle modifiche di 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.

La modifica di fileutils era precedente:

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.

e qualcuno potrebbe trovarne uno ancora prima, ma sembra che l'intestazione del file mostri la prima data:

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

che è (per esempio) in concomitanza con X Toolkit (1987). La maggior parte dei programmi di utilità Unix con cui si ha familiarità (come ls, ps) ha utilizzato le opzioni esistenti a carattere singolo che richiedono visite periodiche al manuale. Durante l'introduzione getopt_long, gli sviluppatori GNU non hanno fatto ciò aggiungendo prima nuove opzioni; hanno iniziato tabulando le opzioni esistenti e fornendo un'opzione lunga corrispondente.

Poiché si stavano aggiungendo a un repertorio esistente, c'era (di nuovo) il problema del conflitto con le opzioni esistenti. Per evitarlo, hanno cambiato la sintassi, usando due trattini prima di lunghe opzioni.

Questi programmi continuano a essere utilizzati getopt_longin questo modo per i soliti motivi:

• gli script dipendono dalle opzioni; gli sviluppatori non sono ansiosi di infrangere gli script
• c'è uno standard di codifica scritto (che può essere efficace)
• nessuno ha escogitato un set di strumenti in competizione che è marcatamente incompatibile (sia gli sviluppatori BSD che gli sviluppatori GNU copiano i nomi delle opzioni gli uni dagli altri)

Nell'interfaccia della riga di comando di wikipedia è riportato:

Nei sistemi simili a Unix, il trattino ASCII-meno è comunemente usato per specificare le opzioni. Il personaggio è generalmente seguito da una o più lettere. Un argomento che è un singolo trattino da solo senza lettere di solito specifica che un programma dovrebbe gestire i dati provenienti dall'input standard o inviare i dati all'output standard. Due caratteri trattino-meno (-) vengono utilizzati su alcuni programmi per specificare "opzioni lunghe" in cui vengono utilizzati nomi di opzioni più descrittivi. Questa è una caratteristica comune del software GNU.

La mia ipotesi è che fossero desiderate opzioni più descrittive e anche con opzioni più lunghe non dovrai preoccuparti di rimanere senza opzioni a carattere singolo.

Una volta deciso che desideri opzioni lunghe, allora hai un problema, almeno se prevedi di supportare entrambe le opzioni lunghe e brevi. Non sono positivo, ma credo che la risposta di Arcege sia la chiave del perché - e -. Una routine di elaborazione generica, ad es. getopt_long (), dovrebbe sapere se un singolo argomento della riga di comando può contenere più opzioni, ad es. -ltr. Pertanto, una routine di elaborazione dovrebbe essere in grado di distinguere tra i due. Se leggo un singolo trattino, -, il resto dell'argomento della riga di comando può corrispondere a più opzioni. Se leggo un doppio trattino, -, il resto dell'argomento della riga di comando deve corrispondere a una singola opzione.

Recentemente ho fatto uso di getopt_long () e sto iniziando ad apprezzare le opzioni lunghe in quanto sono più facili da ricordare e auto-documentare. Se ho i seguenti due comandi:

./aggregator -f 15

./aggregator --flush-time 15

Direi che il secondo che utilizza l'opzione lunga è più autoesplicativo.

Probabilmente ci sono alcuni motivi per cui vengono utilizzati i due metodi. Uno, ovviamente, è la tradizione. I programmatori e gli utenti sono umani e gli umani si aspettano che le cose funzionino in un certo modo. Se non c'è motivo di cambiare (e davvero, per una riga di comando, non c'è molto motivo di cambiare), allora non farlo.

Detto questo, so che ci sono strumenti là fuori che usano il trattino singolo per una lunga opzione o addirittura eliminano del tutto i trattini. Questi strumenti all'inizio possono essere difficili e tendono a sporgere come verruche in un sistema altrimenti unificato.

Quando stavo imparando la differenza tra i due (e prima che diventasse una seconda natura), ricorderei sempre che il trattino "corto" corrisponde alle opzioni "corte", mentre il trattino "lungo" (o doppio) corrisponde al "lungo" opzioni. Non so se quel ragionamento sia stato usato nello sviluppo dello stile a doppio trattino, ma è una possibilità.