Quelles sont les commandes intégrées shell dans Linux?

La série de built-ins varie de shell shell. Il y a:

• Spéciale utilitairesqui doivent être construits, parce qu'ils ont quelques propriétés spéciales
• Classique intégré dans les services publicsqui sont presque toujours construits, en raison de la performance ou d'autres considérations,
• Tout utilitaire standard peut être également intégré dans le si un shell opérateur le souhaite.

Vous permet de savoir si l'utilitaire est construit à l'aide de la type de commande, qui est pris en charge par la plupart des shells (même si sa production n'est pas normalisée). Un exemple de dash:

$ type ls
ls is /bin/ls
$ type cd
cd is a shell builtin
$ type exit
exit is a special shell builtin

Re cd utilitaire, théoriquement il n'y a rien qui empêche un shell responsable de l'implémentation de l'appliquer comme commande externe. cd ne peut pas changer la coque du répertoire courant directement, mais, par exemple, cd pouvez communiquer à nouveau répertoire pour le processus du shell via une socket. Mais personne ne le fait car il n'y a pas de point. À l'exception de très vieilles coques (où il n'y a pas une notion de built-ins), où cd utilisé certains sale système de hack pour faire son travail.

Comment est cd mis en œuvre à l'intérieur de la coquille? L'algorithme de base est décrite ici. Il peut aussi faire un peu de travail à l'appui de shell fonctionnalités supplémentaires.

Tous les Unix, shell a au moins quelques builtin commands. Ces builtin commandes sont partie de la coquille, et sont mis en œuvre dans le cadre de la coque du code source. Le shell reconnaît que la commande qu'il a été demandé de signer l'un de ses objets internes, et il effectue cette action sur son propre, sans faire appel à un exécutable séparé. Les différents interpréteurs ont différents objets internes, s'il y aura beaucoup de chevauchement dans le jeu de base.

Parfois, les objets internes sont intégrés pour des raisons de performances. Dans ce cas, il y a souvent aussi une version de cette commande dans $PATH (éventuellement avec un autre ensemble de fonctions, autre jeu de reconnu arguments de ligne de commande, etc), mais le shell a décidé de mettre en œuvre la commande intégrés en tant que bien de sorte qu'il peut sauver le travail de frai hors d'un processus à court terme pour faire un peu de travail qu'il pourrait le faire lui-même. C'est le cas pour bash et printf, par exemple:

$ type printf
printf is a shell builtin
$ which printf
/usr/bin/printf
$ printf
printf: usage: printf [-v var] format [arguments]
$ /usr/bin/printf
/usr/bin/printf: missing operand
Try `/usr/bin/printf --help' for more information.

Noter que dans l'exemple ci-dessus, printf est à la fois une commande interne du shell (mis en œuvre dans le cadre de bash), ainsi que d'une commande externe (situé dans /usr/bin/printf). Remarque qu'ils se comportent différemment que si appelé sans arguments, le groupe builtin de la version et de la syntaxe de la commande d'impression des messages d'erreur différents. Notez également la -v var option (stocker les résultats de cette printf dans une variable d'environnement nommée var) ne peut être fait dans le cadre de la coquille - sous-processus comme /usr/bin/printf n'ont pas accès aux variables de la coquille qui les ont exécutés.

Et cela nous amène à la 2ème partie de l'histoire: certaines commandes sont intégrés parce qu'ils ont besoin de l'être. Certaines commandes, comme chmodsont minces wrappers autour des appels système. Lorsque vous exécutez /bin/chmod 777 foola coque de la fourche, les execs /bin/chmod (passage du "777" et "foo") comme arguments, et les nouvelles chmodé processus s'exécute le code C chmod("foo", 777); et renvoie ensuite le contrôle de la coquille. Ce ne serait pas travailler pour le cd de commande. Même si cd ressemble le même cas que chmodil a de se comporter différemment: si le shell donné naissance à un autre processus pour exécuter le chdir appel système, il serait de changer le répertoire seulement pour que nouvellement généré processus, et non pas le shell. Puis, lorsque le processus est retourné, l'interpréteur de commandes devrait être laissé dans le même répertoire qu'il avait été dans le long - donc cd doit être mis en œuvre en tant que commande interne du shell.

http://ss64.com/bash/ cela va vous aider.

et voici shell scripting guide

http://www.freeos.com/guides/lsst/