As diferentes formas de passar os argumentos para aplicativos de console

Question

Por que os aplicativos de console recebem os argumentos iniciados 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) ed) existem ao mesmo tempo. E é difícil lembrar quando devo usar, por exemplo, -help e quando --help.

    

Answer 1

Os traços são usados para denotar opções , que modificam o comportamento do comando. Argumentos sem traços denotam os principais parâmetros do comando, geralmente são nomes de arquivos.

Os hífens simples geralmente apresentam opções que consistem em apenas uma letra. Várias dessas opções podem ser agrupadas, por isso ls -a -l pode ser abreviado como ls -al . Essa foi a convenção padrão para os comandos mais antigos do Unix.

Os hifens duplos introduzem opções que são palavras inteiras. Essa convenção é necessária para distingui-los do agrupamento descrito acima. Este estilo de opção foi popularizado pelas versões GNU dos utilitários, porque eles frequentemente tinham tantos recursos que eles ficavam sem letras mnemô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=parameter e alguns permitem vários formulários.

Há também um punhado de comandos que inventaram seus próprios estilos de argumentos ideoincráticos. Estes são tipicamente comandos muito antigos, desde antes de haver um consenso sobre convenções de argumentos. Exemplos disso são tar e dd . find também é incomum em ser um comando antigo que usou 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 encaixam no paradigma típico command -options parameters .

Outras razões para a variação entre comandos é que o Unix não possuía originalmente uma função de biblioteca de análise de argumentos. Não foi até a metade da sua existência que as funções getopt e getopts foram criadas. O uso dessas bibliotecas essencialmente força você a seguir práticas comuns. Mas os programas mais antigos fizeram sua própria análise de argumentos ad hoc e diferentes programadores tomaram decisões diferentes.

    

Answer 2

@Barmar está correto, mas falta alguns pontos de informação. Por que isso realmente acontece é apenas por causa de como o código do programa foi escrito e, mais especificamente, o que foi usado para analisar os argumentos.

Antes de falar mais sobre isso, quero esclarecer algumas terminologias. Primeiro de tudo, o que você chama de "opções" também são argumentos. Na verdade, tudo que você digita na linha de comando é um argumento (incluindo o nome do programa). Esses argumentos são normalmente armazenados em uma matriz (chamada argv em C). Então, o programa escolhe como (ou se) analisar esses argumentos e se comportar de acordo. Agora, os argumentos geralmente assumem uma de três formas:

1. flags (não leve um argumento; basta ligar ou desligar um comportamento)
2. switches (use um argumento; modifique o comportamento com base no argumento)
3. parâmetros (dados simples não destinados a modificar o comportamento)

1 e 2 são geralmente chamados de OPTIONS e devem mudar o comportamento do programa, mas ambos aparecem em estilos diferentes (como também mencionado pelo Barmar). A biblioteca getopt do C, na verdade, permite uma grande flexibilidade nessa área. Embora a convenção seja ter as opções especificadas como uma única letra precedida por um único hífen ou uma palavra inteira precedida por dois hífens, os programas escritos com getopt na verdade permitem que qualquer um dos seguintes seja equivalente (assumindo help recebe h como o índice):

-h, --h, --help

No entanto, -help na verdade não é permitido por getopt (portanto, se uma ferramenta usa -help para seu sinalizador de uso, você pode ter certeza de que ela não foi gravada com a biblioteca getopt ). Isso ocorre porque getopt interpreta um único hífen para sinalizar uma lista de opções combinadas, por isso interpreta -help as -h -e -l -p .

Além disso, quando as opções aceitam argumentos (convencionalmente chamadas de “opçõesgs”), há algumas maneiras de especificá-las. O seguinte - dado que o índice para opt é o , e que opt requer que escolherg ¹ - também são equivalentes:

-oParameter, -o Parameter, --opt=Parameter, --opt Parameter

Embora a biblioteca getopt seja um padrão amplamente usado agora, muitas ferramentas anteriores a ela (como tar ) ainda usam sua própria configuração de análise, daí porque tar -xjf é equivalente a tar xjf .

TL; DR : getopt nem sempre existiu, então os programadores tiveram que analisar os argumentos do seu próprio jeito. No entanto, as ferramentas mais novas geralmente usam esse recurso para que seu comportamento seja sensato e previsível.

1 Existe uma habilidade não bem documentada de que as opções possam ser aceitas, mas não requerem uma. As opções opcionais causam todo tipo de coisas irritantes e fazem com que algumas das maneiras mais comuns de especificar opções sejam inválidas (já que seriam ambíguas). Felizmente, os argumentos que aceitam um argumento opcional não são muito comuns.

    

Answer 3

as opções começam com traço, geralmente uma letra, várias opções podem especificar

ls -l -h 
or
ls -lh

as opções começam com dois traços, geralmente levam palavras, várias opções não funcionam

ls --list --human