Que signifie la commande ./ de la console ?

Lorsque vous exécutez une commande sans préfixe, les systèmes Unix recherchent la commande à l'intérieur de PATH . Par exemple, si vous tapez ls alors Unix parcourra tous les chemins listés dans PATH pour trouver le ls binaire.

Supposons par exemple que votre PATH est fixé à /bin:/usr/bin:/usr/local/bin puis en tapant simplement ls fera en sorte que votre Shell trouve la commande à l'endroit suivant /bin/ls et l'exécuter.

Les systèmes Unix évaluent les chemins d'accès dans l'ordre où ils sont énumérés dans le fichier PATH . Ainsi, si vous avez plusieurs ls installé, il exécutera celui qui a été trouvé en premier, en ignorant les autres. Ainsi, dans l'exemple ci-dessus, vous pourriez avoir un autre ls installé à /usr/local/bin/ls qui n'est jamais utilisé si vous tapez simplement ls . Si vous souhaitez exécuter /usr/local/bin/ls au lieu de cela, vous pouvez soit modifier PATH ou utiliser le chemin d'accès absolu en tapant /usr/local/bin/ls .

Il s'agit maintenant de votre ./ préfixe. Le préfixe . renvoie simplement au dossier en cours. Ainsi, si vous préfixez une commande par ./ votre Shell recherche la commande dans le dossier courant. En fait, le

./command

est identique à

`pwd`/command

ou (sous BASH)

${PWD}/command

Comme nous l'avons déjà mentionné, sur la ligne de commande de Windows, vous avez peut-être l'habitude d'entrer simplement command si vous voulez exécuter command.exe du dossier en cours. En effet, Windows recherche d'abord implicitement le binaire dans le dossier de travail actuel avant de rechercher le chemin d'accès.

Malheureusement, ce n'est pas très sûr. Imaginons que je veuille voler des informations utilisateur auxquelles je n'ai pas accès en tant qu'utilisateur normal. Je vais simplement placer un script très simple dans mon répertoire personnel appelé 'ls' avec le contenu suivant :

#!/bin/bash
cp /etc/shadow /home/my-user > /dev/null 2>&1
chown my-user /home/my-user/shadow > /dev/null 2>&1
/bin/ls $*

Ensuite, rendez-le exécutable.

Ensuite, j'appelle mon administrateur système et je lui raconte une histoire à propos de noms de fichiers assez étranges dans mon répertoire personnel. Très probablement, l'administrateur se connecte sur le Shell (avec un peu de chance en tant que root), se rend dans mon répertoire et exécute ls . Ce qui se passerait, c'est qu'au lieu de /bin/ls l'administrateur du système exécuterait mon ls script qui place simplement une copie de /etc/shadow dans mon dossier personnel. L'administrateur se demandera probablement pourquoi cette ls n'affichera pas les noms des fichiers. Le script ne fait donc qu'exécuter le "vrai" fichier /bin/ls sur la dernière ligne.

Pour éviter ce genre de problèmes, la plupart des systèmes Unix modernes n'incluent pas le répertoire courant ( . ) dans le chemin de recherche. En fait, si une commande est exécutée sans spécifier le chemin d'accès complet, Shell se contentera d'exécuter les binaires dans le chemin d'accès, ce qui inclut généralement les chemins d'accès de confiance uniquement (non inscriptibles par l'utilisateur). Lorsque vous voyez ./mongo dans une documentation, cela signifie simplement que vous devez vous assurer que mongo du bon dossier est exécutée, et non pas une quelconque mongo binaire quelque part sur le chemin.

Si vous exécutez souvent des binaires à partir du chemin actuel, vous pouvez simplement ajouter "." à la liste PATH manuellement :

export PATH=".:$PATH"

A partir de maintenant, le Shell cherchera toujours les binaires dans le répertoire courant en premier. Comme nous l'avons vu plus haut, cela est très dangereux car vous devrez vérifier la présence de binaires dans le répertoire de travail courant à chaque fois que vous exécuterez une commande - même avant de l'exécuter. Malheureusement, pour vérifier la présence de binaires dans le répertoire courant, vous devez généralement utiliser 'ls', ce qui pourrait déjà exécuter un binaire auquel vous ne vous attendez pas.

Personnellement, j'utilise souvent les éléments suivants dans mes $HOME/.profile :

export PATH="~/bin:$PATH"

Cela me permet de placer quelques scripts dans mes $HOME/bin et les exécuter sans avoir à spécifier le chemin d'accès complet. Mais n'oubliez pas que $HOME/bin est une voie de confiance pour moi aussi.

Autre petite remarque. Chaque répertoire (même les répertoires vides) contient deux liens en dur. Vérifier ls -a de la production :

.
..

のことです。 . se réfère au répertoire actuel, tandis que l'entrée .. est liée au répertoire parent. Cela permet d'activer les chemins relatifs. Bien entendu, cela permet également d'utiliser des définitions récursives telles que ././././././command à exécuter command comme . renvoie toujours au même répertoire. Vous pouvez également exécuter quelque chose comme /bin/../bin/./././../bin/ls ce qui est tout à fait valable.

J'espère que cela clarifie un peu ce qu'est la . et .. concernent.