Esta é uma regra "como se".

Simplificando: o comportamento do shell como os usuários veem não deve mudar se uma implementação decidir tornar um comando externo padrão também disponível como shell embutido.

O contraste que mostrei em https://unix.stackexchange.com/a/496291/5132 entre os comportamentos (por um lado) dos shells PD Korn, MirBSD Korn e Heirloom Bourne; (por outro lado) os shells Z, 93 Korn, Bourne Again e Debian Almquist; e (na mão que agarra) a concha de Watanabe destaca isso.

Para os shells que não possuem printfum built-in, removendo /usr/binde PATHfaz uma invocação de printfparar de funcionar. O comportamento conforme POSIX, exibido pelo shell Watanabe em seu modo conforme, causa o mesmo resultado. O comportamento do shell que possui um printfbuilt-in é como se estivesse invocando um comando externo.

Considerando que o comportamento de todos os shells não conformes não se altera se /usr/binfor removido de PATH, e eles não se comportam como se estivessem invocando um comando externo.

O que o padrão está tentando garantir a você é que os shells podem incorporar todos os tipos de comandos normalmente externos (ou implementá-los como suas próprias funções de shell), e você ainda obterá o mesmo comportamento dos built-ins que você fez com os comandos externos se você ajustar PATHpara impedir que os comandos sejam encontrados. PATHcontinua sendo sua ferramenta para selecionar e controlar quais comandos você pode invocar.

(Como explicado em https://unix.stackexchange.com/a/448799/5132 , anos atrás, as pessoas escolhiam a personalidade de seu Unix alterando o que estava acontecendo PATH.)

Pode-se opinar que fazer o comando sempre funcionar, independentemente de ele ser encontrado, PATH é, na verdade, o objetivo de criar comandos normalmente externos embutidos. (É por isso que meu conjunto de ferramentas nosh ganhou um printenvcomando embutido na versão 1.38, na verdade. Embora isso não seja um shell.)

Mas o padrão está lhe dando a garantia de que você verá o mesmo comportamento para comandos externos regulares que não estão no PATHshell, como você verá em outros programas não shell invocando a execvpe()função, e o shell não será magicamente capaz de execute (aparentemente) comandos externos comuns que outros programas não podem encontrar com o mesmo arquivo PATH. Tudo funciona de forma auto-consistente do ponto de vista do usuário e PATHé a ferramenta para controlar como funciona.

Leitura adicional

• Por que os utilitários obrigatórios POSIX não estão embutidos no shell?
• Por que o echo é um shell embutido no comando?
• Como o bash executa comandos

Isso é bastante absurdo e é por isso que nenhum shell o está implementando em seu modo padrão.

A lógica do padrão e seu exemplo ilustrativo sugerem que esta foi uma tentativa fracassada de ter um built-in regular associado a um caminho, e deixar o usuário substituí-lo por ter seu próprio binário aparecendo antes dele PATH(por exemplo, um printfbuilt-in associado com /usr/bin/printfpode ser substituído pelo /foo/bin/printfcomando externo definindo PATH=/foo/bin:$PATH).

No entanto, o padrão acabou não exigindo isso, mas algo completamente diferente (e também inútil e inesperado).

Você pode ler mais sobre isso neste relatório de bug . Citando do texto final aceito :

Muitas implementações existentes executam um built-in regular sem realizar uma pesquisa PATH. Esse comportamento não corresponde ao texto normativo e não permite que os autores de script substituam os utilitários internos regulares por meio de um PATH especialmente criado. Além disso, a justificativa explica que a intenção é permitir que os autores substituam os built-ins modificando o PATH, mas não é isso que diz o texto normativo .

FWIW, também não acho que haja nenhum shell implementando os requisitos revisados ​​do texto aceito.

Acompanhamento vis-a-vis echovs printf:

(Abaixo, builtin significa "embutido especial" e "embutidos regulares" não são considerados embutidos por mim, pois não são embutidos no shell)

O primeiro comitê de padronização do POSIX não conseguiu concordar em como padronizar o echo, então eles se comprometeram ao emitir que se fossem passados ​​sinalizadores ( -e,-n,-E, etc. \n,\c,\t) o shell de implementação em vez de POSIX. Em vez disso, o printfcomando foi adicionado e recebeu um comportamento bem definido. (fonte: Classic Shell Scripting, de Robbins e Beebe).

Embora printfseja bem definido, alguns shells não possuem printfcomo comando embutido (ex mksh. ). Em vez disso, eles usam printffrom /usr/bin/. Isso significava que todos os scripts executados a partir desse shell imprimiriam o mesmo em um determinado sistema operacional (Ubuntu, Fedora, etc.), mas não necessariamente imprimiriam o mesmo em todos os sistemas operacionais (na verdade, muitos usuários alteraram o printfpara /usr/binisso razão).

Alternativamente, shells com printfbuiltin imprimiriam o mesmo independentemente do sistema operacional, mas apenas se usados ​​como implementados para o shell. No entanto, como printfo comportamento é definido pelo padrão POSIX, isso não é necessariamente uma preocupação para os programadores. No entanto, se PATHfosse substituído por shells que usam printffrom /usr/bin/, printfnão seria encontrado.

Embora todos os shells tenham echocomo built-in, alguns interpretam sequências de escape diretamente (por exemplo ash, ) enquanto outros (a maioria) exigem um -esinalizador: o comportamento não é definido pelo POSIX, mas pelo shell.

Um dos principais aborrecimentos do echovs. printfé que echoimprime novas linhas no final da string por padrão, mas printfnão. printf requer a \nsequência de escape para imprimir novas linhas. Por outro lado, para evitar echoa impressão de uma nova linha, a \csequência de escape é necessária (potencialmente, exigindo também o -esinalizador).

printférecomendado para a máxima portabilidade uma vez que o seu comportamento é definido pelo POSIX, mas pessoalmente acho que imprimir explicitamente uma nova linha no final de cada linha é bastante aborrecido (a maioria das linhas que escrevo requerem uma nova linha no final e raramente preciso suprimir echoimpressão de novas linhas). Por outro lado, echoestá sempre disponível, pois é um builtin (sem risco de não ser encontrado em $PATH) e uma simples verificação pode ser realizada para determinar se o -esinalizador é necessário e um alias correspondente echofeito:

#! /bin/sh -

# Determine if "builtin" command exists.
BUILTIN='builtin'
  
if ! ("${BUILTIN}" echo 123 >/dev/null 2>&1); then
  BUILTIN=''
fi
export BUILTIN

ECHO='echo -e'

if ${BUILTIN} [ "`echo -e test`" = '-e test' ]; then
  ECHO='echo'
fi
export ECHO

# Now use "${ECHO}" where you would normally use "echo"...

Pessoalmente, prefiro fazer isso e só usar printfse precisar de formatação especial.

ATUALIZAÇÃO: Devo dar o devido crédito onde o crédito é devido. O código do shell acima foi retirado diretamente do shunit2. O crédito vai para Kate Ward e a shunit2equipe de desenvolvimento por isso! (Bem feito ;) )

Adicionando isso também ( Classic Shell Scripting de Robbins e Beebe é um ótimo livro):

O shell tem vários comandos embutidos. Isso significa que o próprio shell executa o comando, em vez de executar um programa externo em um processo separado. Além disso, o POSIX distingue entre built-ins “especiais” e built-ins “regulares”. [A maioria dos built-ins regulares] precisa ser embutido para que o shell funcione corretamente (por exemplo, read). Outros são normalmente embutidos no shell apenas para eficiência (por exemplo, truee false). O padrão permite que outros comandos sejam embutidos para eficiência também, mas todos os embutidos regulares devem ser acessíveis como programas separados que podem ser executados diretamente por outros programas binários.A distinção entre comandos internos especiais e regulares entra em jogo quando o shell procura comandos a serem executados. A ordem de pesquisa de comando é primeiro os internos especiais, depois as funções do shell, depois os internos regulares e, finalmente, os comandos externos encontrados pesquisando os diretórios listados em $PATH. Essa ordem de pesquisa torna possível definir funções de shell que estendem ou substituem as funções de shell regulares. Esse recurso é usado com mais frequência em shells interativos. Por exemplo, suponha que você queira que o prompt do shell contenha o último componente do nome do caminho do diretório atual. A maneira mais fácil de fazer isso acontecer é fazer com que o shell seja alterado PS1toda vez que você alterar os diretórios. Você poderia simplesmente escrever sua própria cdfunção [ ] [para isso].Há uma pequena mosca na pomada aqui. Como a função shell acessa a funcionalidade do comando "real" cd?...O que é necessário é uma "escotilha de escape" que diga ao shell para ignorar a busca por funções e acessar o comando real. Este é o trabalho do commandcomando embutido.

[No entanto] o commandcomando não é um comando embutido especial! Ai do programador shell que define uma função chamada command! O padrão POSIX fornece as duas qualidades especiais adicionais a seguir para os comandos integrados especiais:

1. Um erro de sintaxe em um utilitário interno especial pode fazer com que um shell executando esse utilitário seja abortado, enquanto um erro de sintaxe em um utilitário interno regular não fará com que um shell executando esse utilitário seja abortado. Se um utilitário interno especial encontrando um erro de sintaxe não abortar o shell, seu valor de saída deve ser diferente de zero.
2. As atribuições de variáveis ​​especificadas com utilitários integrados especiais permanecem em vigor após a conclusão do integrado; este não deve ser o caso de um utilitário regular embutido ou outro. [Ou seja] você pode especificar a atribuição de variável na frente de um comando e a variável terá esse valor apenas no ambiente do comando executado, sem afetar a variável no shell atual ou comandos subsequentes. (por exemplo PATH=/bin:/usr/bin: awk '...', ) No entanto, quando tal atribuição é usada com um comando interno especial, a atribuição permanece em vigor a partir de então, mesmo após a conclusão do interno especial.

Arnold Robbins e Nelson HF Beebe. Shell Scripting Clássico: Comandos Ocultos que Desbloqueiam o Poder do Unix (p. 262-5). Mídia O'Reilly. Edição Kindle.

Observe que o commandcomando faz com que o shell trate o comando e os argumentos especificados como um comando simples, suprimindo a pesquisa de função do shell. Dos Documentos IBM

Normalmente, quando um / (barra) não precede um comando (indicando um caminho específico), o shell localiza um comando pesquisando nas seguintes categorias:

funções de shell integradas de shell especiais variáveis ​​de ambiente PATH integradas de shell Por exemplo, se houver uma função com o mesmo nome de uma built-in regular, o sistema usará a função. O comando command permite que você chame um comando que tenha o mesmo nome de uma função e obtenha o comando simples.

Os comandos command -v e command -V gravam na saída padrão qual nome de caminho será usado pelo shell e como o shell interpreta o tipo de comando (integrado, função, alias e assim por diante). Como os sinalizadores -v e -V produzem saída em relação ao ambiente shell atual, o comando command é fornecido como um shell Korn ou um comando interno regular do shell POSIX. O comando /usr/bin/command pode não produzir resultados corretos, porque é chamado em um subshell ou ambiente de execução de comando separado. No exemplo a seguir, o shell não consegue identificar aliases, sub-rotinas ou comandos especiais do shell:

(PATH = comando foo -v) comando nohup -v

Assim, no meu exemplo anterior, usei o bash builtinem vez de commandporque se eu o colocasse em um subshell, ele não funcionaria corretamente.

Eu apoio @mosvy: parece que o texto padrão e normativo não combinam (muito absurdo mesmo).