Comprendre les commandes intégrées du shell

Dans le manuel bash , il est écrit que

Builtin commands are contained >>> within <<< the shell itself

En outre, cette réponse indique que

A built-in command is simply a command that the shell carries out itself,
instead of interpreting it as a request to load and run some
>>> other program <<<

Quand je cours compgen -bsur bash 4.4, je reçois une liste de toutes les commandes SHELL. Je vois par exemple cela [et killsont répertoriés comme étant des commandes intégrées au shell. Mais leurs emplacements réels sont:

/usr/bin/[
/bin/kill

Je pensais que builtincela signifie que la commande est compilée dans l' /bin/bashexécutable. Alors qu'est-ce qui m'embrouille vraiment: Veuillez me corriger, mais comment une commande distincte peut-elle être une builtin, alors qu'elle ne fait en fait pas partie du shell?

Les commandes intégrées au shell sont souvent intégrées en raison de l'augmentation des performances que cela donne. Par exemple, appeler l' externe printf est plus lent que d'utiliser le intégré printf.

Étant donné que certains utilitaires n'ont pas besoin d'être intégrés, à moins qu'ils ne soient spéciaux, comme cd, ils sont également fournis en tant qu'utilitaires externes . Ceci afin que les scripts ne se cassent pas s'ils sont interprétés par un shell qui ne fournit pas d'équivalent intégré.

Certains éléments intégrés du shell fournissent également des extensions à la commande externe équivalente. Bash printf, par exemple, est capable de faire

$ printf -v message 'Hello %s' "world"
$ echo "$message"
Hello world

(imprimer dans une variable) ce que l'externe /usr/bin/printfne pourrait tout simplement pas faire car il n'a pas accès aux variables shell dans la session shell actuelle (et ne peut pas les changer).

Les utilitaires intégrés n'ont pas non plus la restriction que leur ligne de commande étendue doit être plus courte qu'une certaine longueur. Faire

printf '%s\n' *

est donc sûr si printfest une commande intégrée au shell. La restriction de la longueur de la ligne de commande provient de la execve()fonction de bibliothèque C utilisée pour exécuter une commande externe. Si la ligne de commande et l'environnement actuel sont plus grands que les ARG_MAXoctets (voir getconf ARG_MAXdans le shell), l'appel à execve()échouera. Si l'utilitaire est intégré au shell, il execve()n'est pas nécessaire de l'appeler.

Les utilitaires intégrés ont priorité sur les utilitaires trouvés dans $PATH. Pour désactiver une commande intégrée dans bash, utilisez par exemple

enable -n printf

Il y a une courte liste d'utilitaires qui doivent être intégrés dans un shell (extrait de la liste des standards spéciaux du standard POSIX )

break
colon (:)
continue
dot (.)
eval
exec
exit
export
readonly
return
set
shift
times
trap
unset

Ceux-ci doivent être intégrés car ils manipulent directement l'environnement et le flux de programme de la session shell actuelle. Un utilitaire externe ne serait pas en mesure de le faire.

Fait intéressant, cdne fait pas partie de cette liste, mais POSIX dit ce qui suit à ce sujet:

Comme cdaffecte l'environnement d'exécution du shell actuel, il est toujours fourni en tant que shell intégré standard. S'il est appelé dans un environnement d'exécution de sous-shell ou d'utilitaire distinct, tel que l'un des éléments suivants:

(cd /tmp)
nohup cd
find . -exec cd {} \;

cela n'affecte pas le répertoire de travail de l'environnement de l'appelant.

Je suppose donc que les incorporés "spéciaux" ne peuvent pas avoir d'homologues externes, alors cdqu'en théorie ils auraient pu (mais cela ne ferait pas grand-chose).

Vous êtes (tout à fait compréhensible) confus par le fait que certains buildins existent à la fois en tant que buildins et en tant que commandes externes. Donc, bien que vous ayez raison, par exemple, qu'il existe une /bin/[commande, cela ne signifie pas que son «emplacement réel» est /bin.

Tout moyen facile de tester cela est d'exécuter typeavec le -acommutateur qui affichera toutes les instances disponibles d'une commande. Sur mon système Arch, cela montre:

$ type -a [
[ is a shell builtin
[ is /sbin/[
[ is /usr/sbin/[
[ is /usr/bin/[

Notez que /sbin, /usr/sbinet que /bintous les liens symboliques pointent vers /usr/bin, il n'y a donc qu'un seul externe [:

$ readlink -f /usr/sbin /sbin /bin/
/usr/bin
/usr/bin
/usr/bin

Comme vous pouvez le voir, il [s'agit à la fois d'une commande intégrée et d'une commande externe, et il en va de même pour diverses autres commandes intégrées de shell. Cependant, cela ne change pas le fait qu'il s'agit également de commandes intégrées au shell, compilées dans le shell lui-même.