Perché c'è un / bin / echo e perché dovrei usarlo?

Ho notato che c'è un eseguibile binario /bin/echosul mio sistema Ubuntu MATE 17.04.

Ho pensato, è strano, perché

$ type echo
echo is a shell builtin

I test di cursori suggeriscono che /bin/echofa lo stesso tipo di cose che incorpora Bash echo:

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

Quindi, perché esiste un'altra versione di echoseparata dal programma Bash e perché o quando dovrei usarla?

Se si apre un bashprompt e si digita un echocomando, che utilizza una shell incorporata anziché in esecuzione /bin/echo. Le ragioni per cui è ancora importante /bin/echoesistere sono:

1. Non stai sempre usando una shell. In una varietà di circostanze, si esegue un eseguibile direttamente e non attraverso una shell.
2. Almeno in teoria, alcune shell non hanno un echobuiltin. Questo non è effettivamente richiesto.

Per espandere il # 1, si supponga di voler spostare tutti i file regolari i cui nomi iniziare con abcqualsiasi parte srca dest. Esistono diversi modi per farlo, ma uno di questi è:

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

Supponiamo, invece di eseguirlo, di vedere tutti i comandi che verranno eseguiti per primi. Bene, allora puoi anteporre echoal comando, proprio come potresti fare in altri contesti:

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

Ma findnon usa una shell. Funziona /bin/echo.

Inoltre findcon -execo-execdir , l' /bin/echoeseguibile verrà chiamato da altri programmi che eseguono essi stessi programmi ma non attraverso una shell. Ciò avviene con il xargscomando (che è legato a find), così come in molti altri contesti, come la Exec=linea di una .desktoplima . Un altro esempio è quando si esegue sudo echo, che può essere utile per verificare se sudofunziona.

Allo stesso modo, alcune shell hanno un printfbuiltin ma /usr/bin/printfesiste anche.

Un motivo meno comune possibile che potresti usare deliberatamente /bin/echoè se ti affidassi alle differenze tra esso e il echocomando fornito dalla tua shell. man echodocumenti /bin/echo; help echonei bash documenti l' bashintegrato. echonon è molto portabile, poiché implementazioni diverse, sia tra i sistemi operativi che tra le shell sullo stesso sistema operativo, supportano diverse opzioni (ad esempio, -e) e differiscono nel trattamento delle barre rovesciate . Naturalmente, è meglio evitare di fare affidamento su tali dettagli e utilizzare printfinvece, che è molto più portatile .

In bash, puoi anche typemostrare il builtin /bin/echo- supponendo che /binsia nel tuo $PATHcome dovrebbe sempre essere - passando la -abandiera :

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

Eliah ha fatto un ottimo lavoro nel rispondere a questa domanda, ma voglio commentare la parte "perché c'è un'altra versione di echoseparata dal programma Bash". Questa è la domanda sbagliata.

La domanda giusta è: perché in primo luogo si tratta di un comando incorporato , quando avrebbe potuto essere (ed è) un comando esterno perfettamente perfetto?

Per semplicità, dai un'occhiata al builtin in trattino, un misero 38 (bash ha 61, per confronto, andando dall'output di 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

Quanti di questi devono essere integrati? [, echo, false, printf, pwd, test, E truenon hanno bisogno di essere builtins: Non fanno nulla che solo un incorporato può fare (influenzare o ottenere lo stato di shell che non è disponibile a comandi esterni). printfAlmeno Bash si avvantaggia di essere un builtin: printf -v varsalva l'output nella variabile var. timein bash è anche speciale: essendo una parola chiave, puoi cronometrare elenchi di comandi arbitrari in bash (il trattino non ha un timeequivalente). pwdnon è nemmeno necessario che sia incorporato: qualsiasi comando esterno erediterà l'attuale directory di lavoro (ed è anche un comando esterno ).:è un'eccezione: è necessario un NOP ed :è così. Il resto fa azioni che un comando esterno può facilmente fare.

Quindi, un quinto di questi builtin non ha bisogno di essere builtin. Allora perche? La dashmanpage * spiega in realtà perché questi sono builtin (sottolineatura mia):

builtins
 Questa sezione elenca i comandi integrati che sono integrati perché
 è necessario eseguire alcune operazioni che non possono essere eseguite da un altro
 processi. Oltre a questi, ci sono molti altri comandi che possono
 essere integrato per efficienza (es. printf (1), echo (1), test (1), ecc.).

È praticamente tutto: questi builtin sono lì perché sono usati così spesso, interattivamente e negli script, e la loro funzionalità è abbastanza semplice, che la shell può fare il lavoro. E così accade: alcuni (?) La maggior parte delle conchiglie hanno preso sul lavoro ** Torna. Ilsh da 2.9 BSD , e non troverete un echoincorporato.

Quindi, è del tutto possibile che una shell minima possa saltare l'implementazione di comandi come builtin (non credo che ci sia nessuna shell corrente). Il progetto GNU coreutils non presuppone che tu li esegua in una particolare shell e POSIX richiede questi comandi. Quindi, coreutils fornisce questi comunque e salta quelli che non hanno alcun significato al di fuori della shell.

* Questo è quasi identico al corrispondente testo di manpage per la shell Almquist , su cui si basa il trattino, la shell Debian Almquist.

** zshporta questa idea all'estremo: i comandi che ricevi caricando vari moduli, come zmv, sono cose in cui non pensi che una shell debba nemmeno entrare . A quel punto, la vera domanda è: perché dovresti usare bash invece di zsh, che ha tutti questi builtin?