Pourquoi utilisons-nous “ ./” (barre oblique point) pour exécuter un fichier sous Linux / UNIX?

Sous Linux, UNIX et les systèmes dexploitation associés, . désigne le répertoire actuel. Puisque vous souhaitez exécuter un fichier dans votre répertoire actuel et dans ce répertoire nest pas dans votre $PATH, vous avez besoin du bit ./ pour indiquer au shell où lexécutable est. Donc, ./foo signifie exécuter lexécutable appelé foo qui se trouve dans ce répertoire.

Vous pouvez utiliser type ou which pour obtenir le chemin complet de toutes les commandes trouvées dans votre $PATH.

Commentaires

• Il est très courant dexécuter des programmes dans le répertoire courant. Pourquoi le shell n ‘ recherche-t-il pas là-dedans également? Il recherche dabord dans., Puis dans $ PATH.
• il y a aussi des alias es qui peuvent gêner, pas seulement $PATH.
• @Michael security and sanity: Sil cherchait dabord dans ., alors ce serait un problème de sécurité, vous ou quelquun dautre pourriez le remplacer ls par exemple (un simple virus / trojen: créez un fichier zip avec un exécutable nommé ls, car quelquun effectue une recherche, ils exécutent cet exécutable, ça…). Sil a cherché dans . en dernier, vous pouvez passer un long moment à devenir fou de ne pas savoir pourquoi votre programme ne fonctionne pas (par exemple, vous créez un programme appelé test, au lieu dexécuter votre programme le programme de test des systèmes. Qui ne produit aucune sortie).
• @jcubic que ‘ est une mauvaise idée. Voir le commentaire ci-dessus. Dans le passé, DOS cherchait dans le répertoire actuel et ce comportement était appliqué à Windows cmd, ce qui introduisait de nombreux problèmes de sécurité. MS a corrigé cela dans PowerShell et vous devez maintenant utiliser. \ Pour exécuter le programme dans le répertoire actuel
• @ ctrl-alt-delor: Quand jétais à luniversité à la fin des années 80 ‘ s, cétait une tactique courante (interdite). Ecrire un programme  » ls  » et le laisser dans votre dossier personnel au cas où quelquun dautre viendrait fouiner. Le programme sappelait un  » get shell  » IIRC. Il essaierait dobtenir les informations didentification de lutilisateur exécutant la commande – puis peut-être imprimer une fausse liste de répertoires pour les laisser inconscients.

La réponse littérale est celle que dautres ont donnée: parce que le répertoire courant nest pas dans votre $PATH.

Mais pourquoi? En bref, cest pour la sécurité. Si vous « cherchez dans le répertoire personnel de quelquun dautre » (ou / tmp) et tapez simplement gcc ou ls, vous voulez sachez que vous « utilisez le vrai, pas une version malveillante écrite par votre ami farceur qui efface tous vos fichiers. Un autre exemple serait test ou [, qui peut remplacer ces commandes dans les scripts shell, si votre shell ne les a pas comme intégrés.

Avoir . comme la dernière entrée de votre chemin est un peu plus sûre, mais il existe dautres attaques qui lutilisent. Une méthode simple consiste à exploiter les fautes de frappe courantes, comme sl ou ls-l. Ou recherchez une commande courante qui n’est pas installée sur ce système – vim, par exemple, car les administrateurs système ont une probabilité supérieure à la moyenne de saisir cela.

Cela vous semble-t-il trop théorique? Cest en grande partie , mais cela peut certainement arriver dans la réalité, en particulier sur les systèmes multi-utilisateurs. En fait, voici un exemple de ce site où un administrateur est passé au répertoire de base dun utilisateur et a trouvé ps à masquer par un exécutable de ce nom.

Commentaires

• Avoir juste des chemins absolus dans le PATH variable denvironnement.

Si vous voulez dire, pourquoi avez-vous besoin./ au début – cest parce que (contrairement à Windows), le répertoire courant ne fait pas partie de votre chemin par défaut. Si vous exécutez:

$ ls 

votre shell recherche ls dans les répertoires de votre variable denvironnement PATH (echo $PATH pour le voir), et exécute le premier exécutable appelé ls quil trouve. Si vous tapez:

$ a.out 

le shell fera de même – mais il ne trouvera probablement pas un exécutable appelé a.out. Vous devez indiquer au shell où a.out est – il est dans le répertoire courant (.) alors le chemin est ./a.out.

Si vous « demandez pourquoi il » est appelé « a.out », cest « juste le nom de fichier de sortie par défaut pour gcc. Vous pouvez le changer avec la ligne de commande -o arg. Par exemple:

$ gcc test.c -o test $ ./test 

Commentaires

• Merci.Mon doute est de savoir pourquoi avez-vous besoin ./ au début …. Jai eu recours à « . » (pour placer le répertoire courant) mais pourquoi  » /  » après cela?
• / est le séparateur de chemin sous Linux, vous lutilisez donc pour séparer le répertoire (.) du nom de fichier (a.out). Sans lui, vous avez .a.out qui est un nom de fichier à part entière. (Essayez touch .a.out; ls -lA pour voir ceci.)
• cest ainsi que vous spécifiez le chemin sous Unix, <dir>/<file> donc vous dites essentiellement exécuter un fichier dans le répertoire courant, qui est indiqué par ./test
• Red Hat Linux 9? Il est temps de mettre à niveau!
• Sous Windows 10, PowerShell est maintenant le shell par défaut, et il faut également ./ pour exécuter un exécutable dans le chemin actuel

Vous pouvez essayer dajouter :. à votre variable $ PATH.

Essayez ALT + F2 et tapez: gksudo gedit /etc/environment si vous utilisez Linux / GTK (cest ce que vous avez si vous utilisez Ubuntu).

CEPENDANT, Je vous déconseille fortement de faire cela. Cest mauvais, mauvais et mauvais.

Vous savez, ce genre de choses fonctionne comme ça depuis 1970. Il y a une raison pour laquelle le répertoire actuel nest pas inclus dans le $ PATH.

. est le répertoire courant

.something serait un fichier caché (Tapez « ALT + » pour faire ils apparaissent dans Nautilus, ou essayez « ls -la« .

./someProgram.sh est ce que vous tapez pour exécuter un exécutable someProgram .sh dans le répertoire courant.

.somethingElse signifierait que vous avez un exécutable caché dans le répertoire courant, ce qui est une mauvaise idée.

La règle la plus complète est en fait: si une barre oblique / est dans le chemin, ne cherchez pas PATH

Avant dentrer dans la raison dêtre, vous devez dabord connaître ce fait: exécuter lun des éléments suivants:

bin/someprog 

ou:

ou:

cd bin ./myexec 

exécute bin/someprog sans rechercher le PATH variable pour exactement la même raison: tous les bin/someprog, /bin/someprog et ./someprog contiennent une barre oblique /.

someprog à elle seule na pas de barre oblique /, et par conséquent recherche uniquement dans PATH.

POSIX 7 spécifie cette règle à: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01

CHEMIN

[…] Si le chemin recherché contient un <slash>, la recherche à travers les préfixes de chemin ne sera pas effectuée .

Raison dêtre de la règle / POSIX PATH

Supposons que vous exécutiez:

someprog 

rechercherait:

• par rapport à CWD dabord
• par rapport à PATH après

Ensuite, si vous vouliez exécuter /bin/someprog de votre distribution, et vous lavez fait:

someprog 

cela fonctionnait parfois, mais dautres échouaient, car vous pourriez être dans un répertoire qui contient un autre programme someprog indépendant.

Par conséquent, vous apprendriez bientôt que ce nest pas fiable, et vous finiriez par toujours utiliser chemins absolus lorsque vous voulez utiliser PATH, ce qui va à lencontre de lobjectif de PATH.

Cest aussi pourquoi avoir des chemins relatifs dans votre PATH est une très mauvaise idée. Je « m vous regarde, node_modules/bin .

Inversement, supposons que lexécution:

./someprog 

rechercherait:

• par rapport à PATH dabord
• par rapport à CWD après

Ensuite, si vous venez de télécharger un script someprog à partir dun dépôt git et que vous vouliez lexécuter à partir de CWD, vous ne seriez jamais sûr quil sagit du programme qui sexécuterait, car peut-être que votre distribution a un:

/bin/someprog 

qui est dans votre PATH de un paquet que vous avez installé après avoir trop bu après Noël lannée dernière.

Par conséquent, encore une fois, vous seriez obligé de toujours exécuter des scripts locaux relatifs à CWD avec des chemins complets pour savoir ce que vous exécutez:

"$(pwd)/someprog" 

ce qui serait également extrêmement ennuyeux.

Une autre règle que vous pourriez être tenté de trouver serait:

les chemins relatifs utilisent uniquement PATH, les chemins absolus uniquement CWD

mais encore une fois cela oblige les utilisateurs à utilisez toujours abso chemins de luth pour les scripts non-PATH avec "$(pwd)/someprog".

La règle de recherche de chemin / offre une solution simple à retenir au problème à propos:

• barre oblique: nutilisez pas PATH
• pas de barre oblique: utilisez uniquement PATH

ce qui rend super facile de toujours savoir ce que vous exécutez, en sappuyant sur le fait que les fichiers dans le répertoire courant peuvent être exprimés soit comme ./somefile ou somefile, et cela donne donc une signification particulière à lun deux.

Parfois, il est légèrement ennuyeux de ne pas pouvoir rechercher pour some/prog par rapport à PATH, mais je ne vois pas de solution plus saine à ce problème.