Pourquoi votre répertoire actuel n'est pas dans $ PATH (et si vous devriez le réparer)

Sommaire

Toggle

Résumé

• Linux exécute la plupart des commandes à partir des répertoires bin stockés dans votre variable de chemin.

• L'ajout du répertoire actuel à votre chemin peut être risqué en raison de détournement potentiel ou de fautes de frappe.

• Vous pouvez ajouter le répertoire actuel à votre chemin dans un fichier de démarrage comme .Bashrc.

Il se passe beaucoup de choses dans les coulisses lorsque vous exécutez un programme Linux. La variable de chemin peut le rendre plus pratique, mais vous devez l'utiliser attentivement.

Que se passe-t-il lorsque j'exécute une commande?

Lorsque vous exécutez une commande dans votre terminal, Linux effectue quelques vérifications pour décider comment agir. Il peut détecter que vous exécutez un alias, auquel cas il remplacera ce que vous avez tapé par une autre commande. Il peut reconnaître le nom d'une fonction shell, qu'il procède ensuite à l'exécution. Ou votre commande peut être intégrée dans le shell lui-même.

Dans la plupart des cas, cependant, la commande que vous tapez est le nom d'un fichier, soit un exécutable binaire, soit un script dans une langue interprétée. Ces fichiers sont généralement dans un répertoire bac, souvent l'un des:

• / poubelle

• / sbin

• / usr / bin

• / usr / local / bac

Vous pouvez taper le chemin d'un programme, relatif ou absolu, et votre shell l'exécutera. Par exemple:

        /bin/ls -l *.md
/usr/bin/date

    

Cependant, ce n'est pas très pratique, donc Linux utilise un raccourci appelé la variable d'environnement de chemin. Il s'agit d'un ensemble de répertoires que Linux recherchera pour localiser les fichiers lorsqu'il essaie d'exécuter une commande. Sur mon système, mon chemin ressemble à ceci:

Cela signifie que si j'essaie d'exécuter une commande appelée «programme», Linux recherchera un fichier sur / usr / local / sbin / programme à exécuter. Si ce fichier n'existe pas, il recherchera un fichier A / USR / local / bin / programme, etc.

Sur le chemin, les répertoires sont séparés par le caractère du colon (:) et vous pouvez les énumérer sous une forme plus lisible en utilisant TR:

Ainsi, étant donné qu'il existe un fichier exécutable nommé «LS» dans le répertoire / bac, qui est dans la variable de chemin, en tapant LS provoquera le shell à exécuter le programme à / bin / ls.

Vous pourriez vous attendre à pouvoir exécuter des programmes dans votre répertoire actuel, surtout si vous êtes venu à Linux à partir de MS-DOS. Mais votre chemin n'inclut probablement pas votre répertoire actuel par défaut, vous ne pourrez donc pas le faire simplement en tapant le nom de la commande.

C'est un peu contre-intuitif car vous êtes habitué à d'autres commandes fonctionnant sur des fichiers de votre répertoire de travail en utilisant uniquement leur nom. Par exemple, une commande comme ls readme.md Listera le fichier readme.md dans votre répertoire actuel, s'il y en a un.

Il s'agit d'un cas totalement différent de l'exécution d'un programme dans votre répertoire actuel. Le passage du LS commande le nom d'un fichier rejette la responsabilité de ce programme. Le programme LS inspecte ensuite l'argument de ligne de commande, le reconnaît comme le nom d'un fichier dans le répertoire actuel et le répertorie.

Alors pourquoi pas. sur mon chemin?

Ne serait-ce pas génial si vous pouviez exécuter des programmes dans votre répertoire actuel sans avoir à taper leur chemin de chemin à chaque fois? Ce n'est pas trop de frais généraux, mais si vous écrivez vos propres programmes ou scripts, vous pourriez finir par les exécuter à maintes reprises, donc toute économie d'efficacité semble être une bonne chose.

Bien que cela puisse sembler magique, l'ajout du symbole de répertoire actuel à votre chemin vous permettra de faire exactement cela:

Cela semble mieux que de ne pas pouvoir exécuter des commandes dans votre répertoire de travail, alors pourquoi n'est-ce pas la valeur par défaut? J'ai travaillé avec des systèmes avant où c'était la valeur par défaut, mais ce n'est pas universel – pour une bonne raison.

Pour commencer, l'ajout de votre répertoire de travail au début de votre chemin peut entraîner d'autres programmes de détournement de commandes standard. Prenez cet exemple:

Dans ce cas, vous vous attendez à ce que le programme de recherche standard – qui se trouve dans / usr / bin sur mon système – pour exécuter et répertorier tous les fichiers C sous / tmp. Mais / TMP est un répertoire partagé; Et si un autre utilisateur crée un fichier exécutable dans ce répertoire et le nomme «trouver»?

Dans ce cas, vous dirigez involontairement le programme de quelqu'un d'autre sous votre propre compte d'utilisateur – une recette potentielle de catastrophe!

Il y a toujours un risque lorsque vous exécutez une commande en utilisant uniquement son nom, car vous ne pouvez pas être sûr de ce que votre shell va faire. Mais l'ajout du répertoire actuel à votre chemin augmente ce risque. Vous avez transformé un ensemble d'emplacements bien connus et vraisemblablement sûrs en un seul emplacement variable qui pourrait, potentiellement, être dangereux.

Vous pouvez aider à réduire ce risque en ajoutant le répertoire actuel à la fin de votre chemin:

Maintenant, même avec un programme de recherche dans votre répertoire de travail, votre shell ramassera l'exécutable dans / usr / bin et l'exécutera à la place. C'est un peu plus sûr, mais cela retourne le problème: si vous travaillez sur un programme nommé Find dans votre répertoire local, vous devrez l'exécuter en tapant ./trouver à chaque fois. Vous avez acquis un peu de commodité, mais c'est imprévisible.

L'autre raison de garder. Hors de votre chemin est similaire: il est facile de causer des problèmes avec les fautes de frappe. Imaginez que vous essayez d'exécuter la commande LS mais tapez accidentellement KS à la place et il y a un programme KS dans votre répertoire actuel. L'exécution d'un programme doit être prévisible. Grâce aux emplacements relativement bien contrôlés qui sont généralement sur votre chemin, vous devez rarement exécuter tout ce que vous n'avez pas l'intention de faire.

Comment ajouter mon répertoire actuel à mon chemin?

Avec une compréhension complète des risques et des avantages, vous pouvez décider que vous souhaitez toujours votre répertoire de travail sur votre chemin. C'est bien, tant que vous faites attention et vous savez dans quoi vous vous engagez.

Vous voudrez définir votre chemin en permanence dans un fichier de démarrage comme .Bashrc, .profile ou .zshrc. Le fichier exact dépendra de votre environnement, mais ~ / .bashrc est probablement l'emplacement le plus courant.

Modifiez le fichier approprié et ajoutez une ligne comme ceci:

        export PATH=$PATH:.

    

Cela ajoute votre répertoire actuel à la fin de votre chemin, donc les programmes dans / bin et d'autres emplacements communs seront toujours en premier. Si vous souhaitez que votre répertoire actuel soit prioritaire, ajoutez-le au début:

        export PATH=.:$PATH

    

Et comment exécuter des programmes dans mon répertoire actuel?

Si vous choisissez de ne pas ajouter votre répertoire actuel sur le chemin, ne vous inquiétez pas; Vous pouvez toujours exécuter n'importe quel programme sur votre système de fichiers, tant que vous avez la permission.

Dites que vous avez un programme quelque part dans votre dossier à domicile, comme:

        /Users/bobby/repos/cloc/cloc

    

Parce que ce n'est pas dans un répertoire de chemin, vous ne pourrez pas l'exécuter simplement en tapant son nom:

Au lieu de cela, fournissez simplement un chemin – en absolu ou relatif – à ce fichier exécutable:

L'utilisation du chemin vers une commande au lieu de son nom contournera n'importe quelle recherche de chemin. Assurez-vous de toujours vérifier que vous exécutez le programme que vous pensez être.

Cette deuxième version utilise le caractère de période («.») Pour représenter le répertoire actuel. Une fois que le shell l'a élargi, cette commande sera l'équivalent de la version Full Path. Mais le «.» sera toujours relatif à votre répertoire de travail actuel.