☰

As opções de linha de comando recebem um sinal de igual entre o nome e o valor da opção?

tag-icon • tag-icon command-line options
As opções de linha de comando recebem um sinal de igual entre o nome e o valor da opção?

Apenas usando kubectlcomo exemplo, observo que

kubectl run --image nginx ...

e

kubectl run --image=nginx ...

ambos funcionam.

Para programas de linha de comando em geral, existe uma regra sobre se um sinal de igual é permitido/obrigatório entre o nome da opção e o valor?

Responder1

Em geral, a implementação de como os argumentos da linha de comando são interpretados fica completamente a critério do programador.

Dito isto,em muitos casos, o valor de uma opção "longa" (como é introduzida com --option_name) é especificado com um =entre o nome da opção e o valor (ou seja --option_name=value), enquanto para opções de uma letra é mais comum separar o sinalizador e o valor com um espaço , como -o value, ou não use nenhuma separação (como em -oValue).

Um exemplo da página de manual do utilitário de data GNU:

  -d, --date=STRING
        display time described by STRING, not 'now'

  -f, --file=DATEFILE
        like --date; once for each line of DATEFILE

Como você pode ver, o valor seria separado por um espaço da opção switch ao usar o formato "curto" (ou seja, -d), mas por um =quando usar o formato "longo" (ou seja, --date).

Editar

Como apontado por Stephen Kitt, oPadrão de codificação GNUrecomenda o uso getopte getopt_longa análise de opções de linha de comando. A página de manual dos getopt_longestados:

Uma opção longa pode receber um parâmetro no formato --arg=paramou --arg param.

Portanto, um programa que utiliza essa função aceitará ambas as formas.

Responder2

Para programas de linha de comando em geral, existe uma regra sobre se um sinal de igual é permitido/obrigatório entre a opção e o valor?

Não, não há. Existem muitos padrões concorrentes no mundo do código aberto e na computação em geral (xkcd obrigatório) e todos podem criar novas regras e padrões sempre que quiserem. Sintaxe de argumento do utilitário POSIX por exemplo, não menciona =nada, por exemplo, enquantocara, optemenciona isso. Na prática você pode encontrar todos os tipos de programas de linha de comando:

Aqueles que assumem valor de opção longo após =ou após um espaço em branco:

$ touch a b c d
$ ls --format=verbose
total 0
-rw-r--r-- 1 ja users 0 Mar 17 14:39 a
-rw-r--r-- 1 ja users 0 Mar 17 14:39 b
-rw-r--r-- 1 ja users 0 Mar 17 14:39 c
-rw-r--r-- 1 ja users 0 Mar 17 14:39 d
$ ls --format verbose
total 0
-rw-r--r-- 1 ja users 0 Mar 17 14:39 a
-rw-r--r-- 1 ja users 0 Mar 17 14:39 b
-rw-r--r-- 1 ja users 0 Mar 17 14:39 c
-rw-r--r-- 1 ja users 0 Mar 17 14:39 d

Aqueles que não levam valor de opção longo depois =, mas exigem um espaço em branco:

$ readelf  -a main | grep  'program interpreter'
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
$ patchelf --set-interpreter=fake main
patchelf: getting info about '--set-interpreter=fake': No such file or directory
$ patchelf --set-interpreter fake main
$ readelf  -a main | grep  'program interpreter'
      [Requesting program interpreter: fake]

Aqueles que assumem valor depois =, mas não assumem opções com -ou --:

dd if=/dev/urandom of=~/Desktop/test.txt bs=1M count=3

Pode haver muitas razões pelas quais um determinado programa de linha de comando aceita entradas de uma determinada maneira: a visão do autor, porque ninguém se importa, porque o autor não sabia que alguém já criou um padrão, porque o programa foi portado para Unix de sistemas operacionais diferentes com convenções ou convenções completamente diferentesfoi feito para parecer que foi.

informação relacionada