Vérification de cohérence :pour autant que je sache, le shell est l'interface par laquelle l'utilisateur peut interagir avec le système d'exploitation, c'est-à-dire :exécuter d'autres processus.
Oui, mais un "shell" est spécifiquement un utilisateur interface, pas une interface de programmation. Les autres programmes ne sont pas obligés d'interagir avec lui - ils peuvent utiliser directement les mêmes appels système pour créer de nouveaux processus.
Ainsi, le shell de ligne de commande est au même niveau que les autres programmes, par ex. gestionnaires de services ou interfaces utilisateur graphiques (shells graphiques).
Bien que le shell (par exemple, Bash) ne soit qu'un autre processus.
Oui. Sur les systèmes de type Unix, il s'agit d'un processus tout à fait normal et non privilégié.
Existe-t-il un moyen d'exécuter un processus qui ne sera pas un enfant d'un processus shell ?
Du point de vue de l'utilisateur :oui, il existe plusieurs façons.
-
La plupart des shells ont un
execmot-clé qui fait que le nouveau programme remplace le shell (conservant le même PID et la même parenté), ce qui n'est probablement pas ce que vous vouliez dire, mais techniquement ce que vous avez demandé. -
Les sessions de bureau graphiques démarrent souvent sans appeler bash ou tout autre shell, et cela s'applique automatiquement aux applications lancées via les menus graphiques. Le parent de l'application sera le processus responsable de l'affichage du menu (par exemple, le gestionnaire de fenêtres ou le panneau).
-
Le systemd actuellement populaire init system n'utilise pas du tout de shell lors du démarrage des services, vous pouvez donc définir un .service et le démarrer - le parent du service sera init lui-même. Il dispose également d'une fonctionnalité permettant de créer des services temporaires à la volée en utilisant
systemd-run, avec les mêmes résultats.
Du point de vue d'un programmeur, utilisez simplement le fork() et execve() appels système pour lancer un nouveau processus. (Il existe des détails spécifiques au système d'exploitation, par exemple fork() peut en fait être un wrapper pour un appel différent, mais cela fonctionne toujours de la même manière.)
En effet, même si le programme voulait invoquer un shell, il le ferait en créant un nouveau processus enfant et en exécutant /bin/sh en utilisant le même fork+exec. Il n'y a pas d'appel système spécial pour exécuter un shell. (Le programmeur peut utiliser par exemple system() lors de l'écriture en C, ou os.system() en Python, mais ce ne sont toujours que des wrappers pratiques autour de fork/exec.)
Variables d'environnement :dans bash, plusieurs scripts s'exécutent lorsque vous lancez un shell, par ex. .bashrc, .bash_profile, etc. (dépend du type de shell - interactif vs non interactif, connexion vs non connexion). Ces scripts définissent les variables d'environnement. S'il existe un moyen d'exécuter un processus indépendamment de n'importe quel shell, d'où viennent les variables d'environnement ?
Eh bien, parfois ils ne le font pas. (C'est un vrai problème pratique lorsque l'on essaie de faire en sorte que les applications graphiques prennent en charge les personnalisations de l'environnement, en fonction de la façon dont cet environnement graphique particulier démarre.)
Dans l'ensemble, cependant, les variables d'environnement ne sont pas unique aux shells CLI. Chaque processus, quelle que soit la manière dont il a été démarré (y compris même le processus init), reçoit un tableau de chaînes contenant sa ligne de commande - et un tableau de chaînes contenant ses variables d'environnement. Lors du lancement d'un processus enfant, il peut soit spécifier un environnement différent, soit autoriser l'héritage d'une copie de son propre environnement.
Ainsi, lorsque vous vous connectez, votre shell reçoit déjà quelques variables d'environnement initiales de son parent. Ces scripts de démarrage (bashrc, etc.) ne sont qu'un endroit pratique pour qu'un utilisateur personnalise les variables d'environnement dont les processus enfants du shell hériteront ensuite.
De nombreuses parties de cette réponse s'appliquent également pleinement à Windows - bien que son interface graphique soit un peu plus complexe, les shells CLI (cmd.exe et PowerShell) sont toujours des programmes ordinaires qui ne sont pas du tout utilisés en fonctionnement normal. La seule différence majeure est que Windows a un seul appel "CreateProcess" au lieu des appels séparés "fork + exec" de style Unix.
-
C'est exact. En fin de compte, le shell exécutera le
execappel système, qui est disponible dans tous les systèmes d'exploitation compatibles POSIX, et plus généralement dans tous les systèmes d'exploitation de type Unix, y compris Linux. D'autres systèmes d'exploitation ont des concepts similaires. Sous Linux, leexecl'appel système appellera finalement leexecvefonction, qui est fournie par le noyau et fait le travail réel de chargement du fichier exécutable et de son exécution. -
Oui. Tout processus peut appeler
exec, et n'a pas besoin d'être un "shell". Par exemple, lorsque vous lancez un programme en cliquant dans un navigateur de système de fichiers, le logiciel de bureau est celui qui effectue leexecappeler, il n'y a pas de coquille. Notez que le processus devient l'enfant du logiciel de bureau qui l'a lancé. Tous les processus sont les enfants d'un autre processus, sauf le tout premier, qui s'appelleinitet a le PID 1. Il est responsable de la configuration du système d'exploitation au démarrage et du lancement de tous les autres processus, tels que les services d'arrière-plan et la connexion au bureau. Sous Linux de nos jours,systemdest souvent utilisé commeinitprocessus, mais il existe d'autres alternatives. -
Il existe plusieurs variantes de
exec(execl,execle, ...) qui ont divers arguments en plus du nom du programme à exécuter. Au final, leexecveL'appel système prend un nom de programme, une liste de chaînes qui sont les arguments de la ligne de commande et une liste de chaînes qui sont les variables d'environnement. Par exemple, lors du lancement d'un logiciel à partir d'un navigateur de système de fichiers, les variables d'environnement peuvent être copiées à partir de celles du navigateur de système de fichiers lui-même, éventuellement modifiées par le navigateur de système de fichiers. Cela dépend entièrement des programmeurs du navigateur du système de fichiers.
Quelques lectures supplémentaires :
- https://en.wikipedia.org/wiki/Exec_(appel_système)
- https://en.wikipedia.org/wiki/Fork%E2%80%93exec
- https://man7.org/linux/man-pages/man2/execve.2.html