Por que os parâmetros para `command` e `type` do Bash são opcionais?

Por que os parâmetros para `command` e `type` do Bash são opcionais?

Igual aPor que os parâmetros integrados do Bash são opcionais?, esses comandos não imprimem nada e retornam o código de saída 0 se nenhum parâmetro for fornecido. Mas, ao contrário builtin, sua helpsaída afirma quepelo menos um parâmetro é obrigatório. Isso é um bug, um recurso ou entendi algo errado?

$ bash --version
GNU bash, version 4.2.10(1)-release (x86_64-pc-linux-gnu)
$ type -a command
command is a shell builtin
$ type -a type
type is a shell builtin
$ help -s command
command: command [-pVv] command [arg ...]
$ help -s type
type: type [-afptP] name [name ...]
$ command
$ echo $?
0
$ type
$ echo $?
0

Responder1

POSIX acha que o parâmetro de comando é necessário. Então pode ser um bug.

Especificação de comando POSIX 2008

Responder2

Pois command, a explicação imediata é provavelmente que ksh faz a mesma coisa (pelo menos ATT ksh93, pdksh e mksh não fazem nada quando você executa commandsem argumento, não tenho ATT ksh88 para testar).

Por que ksh se comporta dessa maneira, eu não sei. Uma explicação provisória é que command fooé muito parecido com foo, e se você omitir foo, receberá um comando shell que não faz nada (mas ainda executa redirecionamentos). Estranhamente, com ksh 93s+ 2008-01-31 (mas não com pdksh, mksh, bash, ash ou zsh), ksh -c 'foo=bar command; echo $foo'exibe bar, o que significa que a atribuição é tratada como uma atribuição de variável de shell e não como uma atribuição de ambiente local de comando. Esse comportamento é esperado apenas deutilitários integrados especiais, qualcommandnão é (a justificativa explica por que não). Isso parece um bug no ksh93.

No ksh, builtinexibe uma lista de utilitários integrados, o que é útil.

typeé um caso diferente: ele aceita vários argumentos e relata cada um deles (por exemplo, type ls cd). Ter zero argumentos é uma continuação natural desse comportamento.

informação relacionada