Pourquoi ls nécessite un processus séparé pour son exécution ?
Je connais la raison pour laquelle des commandes comme cd ne peut pas être exécuté par un mécanisme de fork mais y a-t-il un mal si ls est exécuté sans fork ?
Réponse acceptée :
La réponse est plus ou moins que ls est un exécutable externe. Vous pouvez voir son emplacement en exécutant type -p ls .
Pourquoi ls n'est-il pas construit dans la coque, alors? Eh bien, pourquoi devrait-il en être ainsi? Le travail d'un shell n'est pas d'englober toutes les commandes disponibles, mais de fournir un environnement capable de les exécuter. Certains shells modernes ont echo , printf , et leurs équivalents en tant qu'éléments intégrés, qui ne sont pas techniquement doivent être intégrés, mais le sont pour des raisons de performances lorsqu'ils sont exécutés à plusieurs reprises (principalement dans des boucles serrées). Sans les intégrer, le shell devrait bifurquer et exécuter un nouveau processus pour chaque appel, ce qui pourrait être extrêmement lent.
À tout le moins, en exécutant ls , un exécutable externe, nécessite l'exécution d'un des appels système de la famille exec. Vous pourriez faites-le sans bifurquer, mais cela remplacerait le shell principal que vous utilisez. Vous pouvez voir ce qui se passe dans ce cas en procédant comme suit :
exec ls; echo "this never gets printed"
Étant donné que l'image de processus de votre shell est remplacée, le shell actuel n'est plus accessible après cette opération. Pour que le shell puisse continuer à s'exécuter après avoir exécuté ls, la commande doit être intégrée au shell.
Le forking permet le remplacement d'un processus qui n'est pas votre shell principal, ce qui signifie que vous pouvez continuer à exécuter votre shell par la suite.