J'ai remarqué qu'il existe un exécutable binaire /bin/echo sur mon système Ubuntu MATE 17.04.
J'ai pensé, c'est étrange, parce que
$ type echo
echo is a shell builtinDes tests sommaires suggèrent que /bin/echo fait le même genre de choses que l'utilitaire Bash echo :
$ /bin/echo foo
foo
$ /bin/echo $USER
zannaAlors, pourquoi existe-t-il une autre version de echo séparé du programme Bash, et pourquoi ou quand voudrais-je l'utiliser ?
Si vous ouvrez un bash et tapez un echo qui utilise une Shell builtin plutôt que d'exécuter /bin/echo . Les raisons pour lesquelles il est toujours important pour /bin/echo pour exister sont :
echo intégré. Ce n'est pas vraiment nécessaire.Pour développer le point 1, supposons que vous vouliez déplacer tous les fichiers réguliers dont les noms commencent par abc n'importe où dans src a dest . Il existe plusieurs façons de le faire, mais l'une d'entre elles est la suivante :
find src -name 'abc*' -type f -exec mv -nv {} dest/ \;Mais supposons qu'au lieu d'exécuter seulement cette commande, vous voulez voir toutes les commandes qui seront exécutées en premier. Dans ce cas, vous pouvez ajouter echo à la commande, tout comme vous le feriez dans d'autres contextes :
find src -name 'abc*' -type f -exec echo mv -nv {} dest/ \;Mais find n'utilise pas de Shell. Cela exécute /bin/echo .
Outre find con -exec o -execdir le /bin/echo exécutable sera appelé par d'autres programmes qui eux-mêmes exécutent des programmes mais pas par un Shell. Ceci se produit avec le xargs (qui est lié a find ), ainsi que dans un certain nombre d'autres contextes, tels que le site Exec= ligne de a .desktop archivo . Un autre exemple est lorsque vous exécutez sudo echo ce qui peut s'avérer utile pour vérifier si sudo fonctionne.
De même, certains obus ont un printf builtin mais /usr/bin/printf existe également.
Une raison moins courante pour laquelle vous pourriez délibérément utiliser /bin/echo c'est si vous vous basiez sur les différences entre lui et le echo fournie par votre Shell. man echo documents /bin/echo ; help echo sur bash documente le bash builtin. echo n'est pas très portable, parce que différentes implémentations - à la fois entre les systèmes d'exploitation et entre les shells sur le même système d'exploitation - prendre en charge différentes options (par exemple, -e ) et diffèrent dans leur traitement des antislashs . Bien sûr, il vaut mieux éviter de se fier à de tels détails, et utiliser printf à la place, qui est beaucoup plus portable .
Sur bash vous pouvez faire le type spectacle intégré /bin/echo aussi bien - en supposant que /bin est dans votre $PATH comme il se doit, par en lui transmettant le -a drapeau :
$ type -a echo
echo is a shell builtin
echo is /bin/echo
Eliah a fait un excellent travail pour répondre à cette question, mais je veux faire un commentaire sur le "pourquoi y a-t-il une autre version de echo séparément de la partie "programme Bash". C'est la mauvaise question.
La bonne question est : Pourquoi est-ce un buildin en premier lieu ? alors qu'il aurait pu s'agir (et s'agit toujours) d'une commande externe parfaitement adaptée ?
Pour simplifier, regardez les buildins dans dash, 38 à peine (bash en a 61, à titre de comparaison, si l'on se fie à la sortie de la commande 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 trueCombien de ces besoin de pour être des builtins ? [ , echo , false , printf , pwd , test et true Ne le fais pas. besoin de pour être intégrés : Ils ne font rien que seul un builtin peut faire (affecter ou obtenir l'état Shell qui n'est pas disponible pour les commandes externes). Les printf tire au moins profit du fait qu'il s'agit d'un buildin : printf -v var enregistre la sortie dans la variable var . time en bash est aussi spécial : en étant un mot-clé, vous pouvez chronométrer des listes de commandes arbitraires en bash (dash n'a pas d'icône time équivalent). pwd n'a pas besoin d'être un buildin non plus - toute commande externe va hériter du répertoire de travail courant (et c'est un commande externe aussi). : est une exception - vous avez besoin d'un NOP, et : c'est ça. Les autres font des actions qu'une commande externe peut facilement faire.
Donc, un cinquième de ces builtins n'ont pas besoin d'être des builtins. Pourquoi, alors ? En dash page d'accueil * explique en fait en passant pourquoi ce sont des builtins (c'est moi qui souligne) :
Builtins
This section lists the builtin commands which are builtin because they
need to perform some operation that can't be performed by a separate
process. In addition to these, **there are several other commands that may
be builtin for efficiency** (e.g. printf(1), echo(1), test(1), etc).C'est à peu près tout : ces builtins sont là parce qu'ils sont utilisés si souvent, de manière interactive et dans des scripts, et leur fonctionnalité est assez simple, que le scripts peut faire le travail. Et c'est ce qui s'est passé : certains (la plupart ?) shells ont fait le travail. le site sh de 2.9 BSD et vous ne trouverez pas de echo builtin.
Ainsi, il est tout à fait possible qu'un Shell minimal puisse ignorer l'implémentation de telles commandes en tant que builtins (je ne pense pas qu'un Shell actuel le fasse, cependant). Le projet GNU coreutils ne suppose pas que vous allez les exécuter dans un Shell particulier, et POSIX requiert ces commandes. Ainsi, coreutils les fournit de toute façon, et saute celles qui n'ont pas de signification en dehors du Shell.
* C'est presque identique à le texte de la page de manuel correspondant au Shell d'Almquist qui est la base de dash, le Shell de Debian Almquist.
** zsh pousse cette idée à l'extrême : les commandes que vous obtenez en chargeant différents modules, comme zmv , sont des choses que vous ne penseriez pas qu'un Shell ait besoin de faire. . A ce moment-là, la vraie question est : pourquoi utiliser bash au lieu de zsh, qui a tous ces modules intégrés ?
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
