Une chose qui me laisse perplexe sur Linux de bureau, au moins, c'est que presque tout est dans mon CHEMIN. Par tout, je veux dire toutes les applications de bureau, y compris des choses comme gnome-character-map et glchess. Ceux-ci n'ont pas d'interfaces de ligne de commande à proprement parler, donc je ne peux pas penser à un cas où je les lancerais régulièrement depuis un terminal - et, dans ce cas peu probable, je ne peux pas imaginer être gêné en ayant besoin de taper leur plein chemins. Cela semble juste encombrant, mais il y a peut-être une bonne raison.
Alors, pourquoi ne cela se produise? Y a-t-il un impact notable sur les performances ou la maintenabilité?
Toutes les commandes qu'un utilisateur pourrait vouloir exécuter sont dans le CHEMIN. C'est pour ça. Cela inclut les commandes que vous exécutez directement, les commandes que d'autres personnes exécutent directement et les commandes que vous ou d'autres personnes exécutez indirectement car elles sont appelées par d'autres commandes. Cela ne se limite pas aux commandes exécutées à partir d'un terminal: les commandes exécutées à partir d'une interface graphique sont également recherchées dans le chemin de recherche de commandes (encore une fois, c'est à cela qu'il sert).
Avoir besoin de taper le chemin complet serait terrible: vous auriez besoin de savoir ce qu'est le chemin complet! Vous devez savoir s'il se trouve dans /usr/bin(qui contient la plupart des programmes fournis avec le système d'exploitation) ou dans /usr/local/bin(qui contient des programmes installés manuellement par l'administrateur, ainsi que des programmes qui ne font pas partie du système d'exploitation principal sur certains variantes Unix), ou dans un autre répertoire spécifique au système, ou quelque part dans le répertoire personnel de l'utilisateur.
Il est difficile de répondre à «l'impact sur les performances ou la maintenabilité» car vous ne dites pas à quoi vous le comparez. Si vous comparez avec le fait de taper le chemin complet partout, c'est un cauchemar pour la maintenabilité: si vous déplacez un programme, ou si vous souhaitez installer une version plus récente que celle fournie avec le système d'exploitation ou qui a été installée par un administrateur système, vous devez remplacer ce chemin complet partout. L'impact sur les performances de la recherche du nom dans quelques répertoires est négligeable.
Si vous comparez avec Windows, c'est encore pire: certains programmes ajoutent non seulement l'exécutable, mais aussi toutes sortes de conneries au PATH, et vous vous retrouvez avec une PATHvariable d'un kilomètre qui n'inclut toujours pas tous les programmes, car de nombreux programmes ne s'ajoutent pas au chemin système lorsque vous les installez.
Cela ressemble à une justification assez rationnelle. Merci pour l'explication! Il est très logique de remplacer un programme. Je n'y avais pas pensé du tout :) La partie qui me frappe à ce sujet est que j'aime avoir des espaces de noms petits et descriptifs quand je pense à la programmation, alors qu'ici tout est en quelque sorte dans le même espace de noms global (et, quand nous le faisons regardez les chemins complets, dans des endroits assez indescriptibles comme * / bin). Je suppose que ce sont des choses assez différentes, cependant.
Dylan McCall
4
La variable PATH contient une liste de chemins de répertoire. Lorsque l'utilisateur tape une commande sans fournir le chemin complet, cette liste est vérifiée si elle contient un chemin menant à la commande. Il n'y a rien de intrinsèquement spécifique au terminal ou à la ligne de commande.
De plus, il n'y a rien de spécifique à Desktop Linux à ce sujet. Le CHEMIN de mon système XP contient % SystemRoot% \ system32;% SystemRoot%;% SystemRoot% \ System32 \ Wbem qui couvre probablement la plupart des binaires de Windows.
Les répertoires de PATH sont recherchés dans l'ordre spécifié et s'arrêtent dès qu'une correspondance est trouvée. Les répertoires système sont généralement au début pour leur donner la priorité la plus élevée. Les utilisateurs doivent ajouter des chemins de recherche personnalisés à la fin.
En ce qui concerne les performances: la plupart des shells modernes mettent en cache le contenu de PATH afin de ne pas avoir à analyser le disque chaque fois que les utilisateurs entrent une commande.
Le PATH Windows couvre la plupart des fichiers binaires fournis avec Windows, mais les applications ordinaires que vous installez ne se trouvent normalement pas dans le PATH. (Eh bien, les applications avec un composant de ligne de commande s'ajouteront à PATH, mais celles qui ne sont que GUI ne le font pas normalement.)
cjm
Cool, j'ai toujours contemplé l'ordre et sa signification. Que diriez-vous d'une règle d'or? J'ai (presque) toutes les combinaisons de usr, local, binet sbin( à l' exception de mon répertoire personnel).
La variable PATH contient une liste de chemins de répertoire. Lorsque l'utilisateur tape une commande sans fournir le chemin complet, cette liste est vérifiée si elle contient un chemin menant à la commande. Il n'y a rien de intrinsèquement spécifique au terminal ou à la ligne de commande.
De plus, il n'y a rien de spécifique à Desktop Linux à ce sujet. Le CHEMIN de mon système XP contient % SystemRoot% \ system32;% SystemRoot%;% SystemRoot% \ System32 \ Wbem qui couvre probablement la plupart des binaires de Windows.
Les répertoires de PATH sont recherchés dans l'ordre spécifié et s'arrêtent dès qu'une correspondance est trouvée. Les répertoires système sont généralement au début pour leur donner la priorité la plus élevée. Les utilisateurs doivent ajouter des chemins de recherche personnalisés à la fin.
En ce qui concerne les performances: la plupart des shells modernes mettent en cache le contenu de PATH afin de ne pas avoir à analyser le disque chaque fois que les utilisateurs entrent une commande.
la source
usr,local,binetsbin( à l' exception de mon répertoire personnel).