Por que existe um / bin / echo e por que eu gostaria de usá-lo?

Notei que há um executável binário /bin/echono meu sistema Ubuntu MATE 17.04.

Eu pensei, isso é estranho, porque

$ type echo
echo is a shell builtin

O teste superficial sugere que /bin/echofaz o mesmo tipo de coisa que o Bash embutido echo:

$ /bin/echo foo
foo
$ /bin/echo $USER
zanna

Então, por que há outra versão echoseparada do programa Bash e por que ou quando eu gostaria de usá-lo?

Se você abrir um bashprompt e digitar um echocomando, ele utilizará um shell embutido em vez de executar /bin/echo. As razões pelas quais ainda é importante /bin/echoexistir são:

1. Você não está sempre usando um shell. Em várias circunstâncias, você executa um executável diretamente e não através de um shell.
2. Pelo menos em teoria, algumas conchas não têm um echointerior. Isso não é realmente necessário.

Para expandir o número 1, suponha que você deseje mover todos os arquivos regulares cujos nomes começaram com abcqualquer lugar srcpara dest. Existem várias maneiras de fazer isso, mas uma delas é:

find src -name 'abc*' -type f -exec mv -nv {} dest/ \;

Mas suponha que, em vez de apenas executá-lo, você queira ver todos os comandos que serão executados primeiro. Bem, você pode anexar echoao comando da mesma maneira que em outros contextos:

find src -name 'abc*' -type f -exec echo mv -nv {} dest/ \;

Mas findnão usa um shell. Isso corre /bin/echo.

Além de findcom -execou-execdir , o /bin/echoexecutável será chamado por outros programas que se executam programas, mas não através de um shell. Isso acontece com o xargscomando (que está relacionado a find), bem como em vários outros contextos, tais como a Exec=linha de um .desktoparquivo . Outro exemplo é quando você executa sudo echo, o que pode ser útil para testar se sudoestá funcionando.

Da mesma forma, algumas conchas têm um printfbuiltin, mas /usr/bin/printftambém existe.

Uma razão possível menos comum que você pode usar deliberadamente /bin/echoé se estiver contando com as diferenças entre ela e o echocomando fornecido pelo seu shell. man echodocumentos /bin/echo; help echoem bash documentos do bashbuiltin. echonão é muito portátil, porque implementações diferentes - tanto em sistemas operacionais quanto em shells no mesmo sistema operacional - suportam opções diferentes (por exemplo, -e) e diferem no tratamento de barras invertidas . Obviamente, é melhor evitar confiar nesses detalhes e usá-lo printf, o que é muito mais portátil .

Em bash, você pode fazer o typeshow embutido /bin/echotambém - assumindo que /binestá no seu $PATHcomo sempre deveria ser - passando a -abandeira :

$ type -a echo
echo is a shell builtin
echo is /bin/echo

Eliah fez um ótimo trabalho em responder a isso, mas quero comentar sobre a parte "por que há outra versão do echoprograma Bash separado"? Essa é a pergunta errada.

A pergunta certa é: por que isso é embutido em primeiro lugar , quando poderia ter sido (e é) um comando externo perfeitamente adequado?

Por uma questão de simplicidade, dê uma olhada nos builtins no dash, um mísero 38 (o bash tem 61, para comparação, seguindo a saída de compgen -b):

.               continue        getopts         readonly        type
:               echo            hash            return          ulimit
[               eval            jobs            set             umask
alias           exec            kill            shift           unalias
bg              exit            local           test            unset
break           export          printf          times           wait
cd              false           pwd             trap
command         fg              read            true

Quantos destes precisam ser construídos? [, echo, false, printf, pwd, test, E truenão precisa ser builtins: Eles não fazem nada que só um builtin pode fazer (afectam ou obter estado shell que não está disponível para comandos externos). O Bash's, printfpelo menos, tira vantagem de ser um builtin: printf -v varsalva a saída na variável var. timeO bash também é especial: sendo uma palavra-chave, você pode cronometrar listas de comandos arbitrárias no bash (o dash não tem um timeequivalente). pwdtambém não precisa ser incorporado - qualquer comando externo herdará o diretório de trabalho atual (e também é um comando externo ).:é uma exceção - você precisa de um NOP, e :é isso. O restante executa ações que um comando externo pode executar facilmente.

Portanto, um quinto desses componentes não precisa ser construído. Porquê então? A página de dashmanual * na verdade explica de passagem por que esses recursos estão embutidos (ênfase minha):

Builtins
 Esta seção lista os comandos internos que estão embutidos porque eles
 precisa executar alguma operação que não possa ser executada por um
 processo. Além desses, existem vários outros comandos que podem
 ser construído para eficiência (por exemplo, printf (1), eco (1), teste (1), etc.).

É praticamente isso: esses built-in estão lá porque são usados ​​com frequência, de forma interativa e em scripts, e sua funcionalidade é simples o suficiente para que o shell possa fazer o trabalho. E assim acontece: algumas conchas (a maioria?) Assumiram o cargo. ** Volte para ash partir do 2,9 BSD e você não encontrará um echobuiltin.

Portanto, é perfeitamente possível que um shell mínimo possa pular a implementação de comandos como builtins (acho que nenhum shell atual o faz). O projeto coreutils do GNU não pressupõe que você os execute em um shell específico, e o POSIX requer esses comandos. Portanto, o coreutils os fornece de qualquer maneira e ignora aqueles que não têm nenhum significado fora do shell.

* Isso é quase idêntico ao texto da página de manual correspondente do shell Almquist , no qual o dash, o shell Debian Almquist, é baseado.

** zshleva essa idéia ao extremo: os comandos que você obtém ao carregar vários módulos, como zmv, são coisas que você não acha que um shell precisa entrar . Nesse ponto, a verdadeira questão é: por que você usaria o bash em vez do zsh, que possui todos esses recursos?