Por que os aplicativos de console iniciam os argumentos com:
a) one dash (myapp -arg1 123; ls -al)
b) two dashes (myapp --arg1 123; git push origin master --force)
c) without dashes at all (myapp 123; man ls)
d) without dashes but with the equal sign (myapp arg1=123; dd if=/dev/zero)
Não existe uma convenção padrão? Mesmo entre os aplicativos padrão do Linux, todos os três casos a), b) e d) existem ao mesmo tempo. E é difícil lembrar quando devo usar, por exemplo, -help e quando --help.
Responder1
Traços são usados para denotaropções, que modificam o comportamento do comando. Argumentos sem travessões indicam os principais parâmetros do comando, geralmente são nomes de arquivos.
Hífens simples geralmente introduzem opções que consistem em apenas uma letra. Várias dessas opções podem ser agrupadas, portanto ls -a -lpodem ser abreviadas como ls -al. Esta era a convenção padrão para a maioria dos primeiros comandos do Unix.
Hífens duplos apresentam opções que são palavras inteiras. Esta convenção é necessária para distingui-los do agrupamento descrito acima. Esse estilo de opção foi popularizado pelas versões GNU de utilitários, porque muitas vezes tinham tantos recursos que ficavam sem letras mnemônicas únicas.
Às vezes, uma opção requer um parâmetro próprio. Os estilos variam: alguns comandos usam -o parameter, alguns usam -oparameter, alguns usam --option=parametere alguns permitem vários formulários.
Existem também alguns comandos que inventaram seus próprios estilos de argumento ideossincráticos. Normalmente, esses são comandos muito antigos, anteriores a um consenso sobre convenções de argumentos. Exemplos disso são tare dd. findtambém é incomum por ser um comando antigo que usava opções de palavras completas antes da --criação da convenção; seus argumentos são praticamente uma linguagem própria, porque suas necessidades não se enquadram no command -options parametersparadigma típico.
Outras razões para a variação entre os comandos é que o Unix não tinha originalmente uma função de biblioteca de análise de argumentos. Somente no início de sua vida é que as funções getopte getoptsforam criadas. O uso dessas bibliotecas essencialmente força você a seguir práticas comuns. Mas os programas mais antigos faziam a sua própria análise de argumentos ad hoc, e diferentes programadores tomavam decisões diferentes.
Responder2
@Barmar está correto, mas faltam alguns pontos de informação. O motivo pelo qual isso realmente acontece se deve apenas à forma como o código do programa foi escrito e, mais especificamente, ao que foi usado para analisar os argumentos.
Antes de falar mais sobre isso, quero esclarecer algumas terminologias. Em primeiro lugar, o que você chama de "opções" também são argumentos. Na verdade, tudo o que você digita na linha de comando é um argumento (incluindo o nome do programa). Esses argumentos são normalmente armazenados em um array (chamado argvem C). Em seguida, o programa escolhe como (ou se deve) analisar esses argumentos e se comportar de acordo. Agora, os argumentos normalmente assumem uma das três formas:
- sinalizadores (não discuta; simplesmente ative ou desative um comportamento)
- switches (aceitar um argumento; modificar o comportamento com base no argumento)
- parâmetros (dados simples não destinados a modificar o comportamento)
1e 2são frequentemente referidos como OPTIONSe têm como objetivo alterar o comportamento do programa, mas ambos aparecem em estilos diferentes (como também mencionado por Barmar). A biblioteca C getoptrealmente permite uma grande flexibilidade nesta área. Embora a convenção seja especificar as opções como uma única letra precedida por um único hífen ou uma palavra completa precedida por dois hífens, os programas escritos com getoptna verdade permitem que qualquer um dos seguintes seja equivalente (assumindo helpque é dado hcomo o índice ):
-h,--h,--help
No entanto, -helpna verdade não é permitido getopt(portanto, se uma ferramenta usa -helpseu sinalizador de uso, você pode ter certeza de que ela não foi escrita com a getoptbiblioteca). Isso ocorre porque getoptinterpreta um único hífen para sinalizar uma lista de opções combinadas, portanto é interpretado -helpcomo -h -e -l -p.
Além disso, quando as opções recebem argumentos (convencionalmente chamadas de “optargs”), existem algumas maneiras de especificá-las. O seguinte - dado que o índice para opté o,e isso optrequer uma opção¹ - também são equivalentes:
-oParameter,-o Parameter,--opt=Parameter,--opt Parameter
Embora a getoptbiblioteca seja um padrão amplamente utilizado atualmente, muitas ferramentas anteriores a ela (como tar) ainda usam sua própria configuração de análise, por isso tar -xjfé equivalente a tar xjf.
DR: getoptnem sempre existiu, então os programadores tiveram que analisar os argumentos à sua maneira. Porém, as ferramentas mais recentes normalmente o utilizam para que seu comportamento seja sensato e previsível.
1 Existe uma capacidade não bem documentada de que as opções possam optar por, mas nãoexigirum. Opgs opcionais causam todo tipo de coisas irritantes e fazem com que algumas das formas mais comuns de especificar opções sejam inválidas (uma vez que seriam ambíguas). Felizmente, argumentos que aceitam um argumento opcional não são muito comuns.
Responder3
opções começa com traço, geralmente uma letra, várias opções podem ser especificadas
ls -l -h
or
ls -lh
opções começa com dois travessões, geralmente contém palavras, múltiplas opções não podem funcionar
ls --list --human