Question Pourquoi avez-vous besoin de ./ (barre oblique) avant d'exécuter un exécutable ou un nom de script pour l'exécuter en bash?


Lorsque je lance des scripts en bash, je dois écrire ./ au début:

$ ./manage.py syncdb

Si je ne le fais pas, je reçois un message d'erreur:

$ manage.py syncdb
-bash: manage.py: command not found

Quelle est la raison pour ça? j'ai pensé . est un alias pour le dossier actuel, et donc ces deux appels devraient être équivalents.

Je ne comprends pas non plus pourquoi je n'ai pas besoin ./ lors de l'exécution d'applications, telles que:

user:/home/user$ cd /usr/bin
user:/usr/bin$ git

(qui fonctionne sans ./)


223
2018-06-13 13:28


origine


Réponses:


Parce que sur Unix, généralement, le répertoire en cours n'est pas dans $PATH.

Lorsque vous tapez une commande, le shell recherche une liste de répertoires, comme spécifié par le PATH variable. Le répertoire en cours ne figure pas dans cette liste.

La raison de ne pas avoir le répertoire actuel sur cette liste est la sécurité.

Disons que vous êtes root et allez dans le répertoire d'un autre utilisateur et tapez sl au lieu de ls. Si le répertoire actuel est dans PATH, le shell va essayer d'exécuter le sl programme dans ce répertoire (puisqu'il n'y a pas d'autre sl programme). Cette sl programme peut être malveillant.

Cela fonctionne avec ./ car POSIX spécifie qu'un nom de commande qui contient un / sera utilisé comme nom de fichier directement, en supprimant une recherche dans $PATH. Vous pourriez avoir utilisé le chemin complet pour le même effet, mais ./ est plus court et plus facile à écrire.

MODIFIER

Cette sl la partie était juste un exemple. Les répertoires dans PATH sont recherchés séquentiellement et quand une correspondance est établie, ce programme est exécuté. Donc, en fonction de comment PATH Look, taper une commande normale peut ou peut ne pas être suffisant pour exécuter le programme dans le répertoire en cours.


230
2018-06-13 13:29



Lorsque bash interprète la ligne de commande, il recherche les commandes dans les emplacements décrits dans la variable d'environnement $PATH. Pour le voir taper:

echo $PATH

Vous aurez des chemins séparés par des deux-points. Comme vous verrez le chemin actuel . n'est généralement pas en $PATH. Donc Bash ne trouve pas votre commande si elle est dans le répertoire courant. Vous pouvez le changer en ayant:

PATH=$PATH:.

Cette ligne ajoute le répertoire actuel dans $PATH vous pouvez donc faire:

manage.py syncdb

C'est ne pas recommandé car il a un problème de sécurité, plus vous pouvez avoir des comportements étranges, comme . varie selon le répertoire dans lequel vous vous trouvez :)

Éviter:

PATH=.:$PATH

Comme vous pouvez "masquer" une commande standard et ouvrir la porte à une brèche de sécurité :)

Juste mes deux cents.


43
2018-06-13 13:36



Votre script, lorsqu'il se trouve dans votre répertoire personnel, ne sera pas trouvé lorsque le shell regarde le $PATH variable d'environnement pour trouver votre script.

le ./ dit 'regardez dans le répertoire en cours pour mon script plutôt que de regarder tous les répertoires spécifiés dans $PATH'.


30
2018-06-13 13:29



Lorsque vous incluez le '.' vous donnez essentiellement le "chemin complet" au script bash exécutable, votre shell n'a donc pas besoin de vérifier votre variable PATH. Sans le '.' votre shell va regarder dans votre variable PATH (que vous pouvez voir en cours d'exécution echo $PATH pour voir si la commande que vous avez tapée réside dans l'un des dossiers de votre PATH. Si ce n'est pas le cas (comme c'est le cas avec manage.py), il est impossible de trouver le fichier. Il est considéré comme une mauvaise pratique d’inclure le répertoire actuel dans votre PATH, ce qui s’explique assez bien ici: http://www.faqs.org/faqs/unix-faq/faq/part2/section-13.html


4
2018-06-13 13:32



Sur * nix, contrairement à Windows, le répertoire courant n'est généralement pas dans votre $PATH variable. Ainsi, le répertoire en cours n'est pas recherché lors de l'exécution des commandes. Vous n'avez pas besoin ./ pour exécuter des applications parce que ces applications sont dans votre $ PATH; très probablement ils sont en /bin ou /usr/bin.


1
2018-06-13 13:32



Cette question a déjà quelques réponses géniales, mais je voulais ajouter cela, si votre exécutable est sur le PATH, et que vous obtenez des sorties très différentes lorsque vous exécutez

./executable

à ceux que vous obtenez si vous courez

executable

(Disons que vous rencontrez des messages d'erreur avec l'un et non avec l'autre), alors le problème pourrait être que vous avez deux versions différentes de l'exécutable sur votre ordinateur: l'une sur le chemin d'accès et l'autre non.

Vérifiez cela en cours d'exécution

quel exécutable

et

whereis executable

Il a corrigé mes problèmes ... J'avais trois versions de l'exécutable, dont une seule a été compilée correctement pour l'environnement.


1
2017-10-20 14:18



Lorsque le script n'est pas dans le chemin, il est nécessaire de le faire. Pour plus d'informations lire http://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_01.html


0
2018-06-13 13:31



Il y a une différence entre Current Directory et Working Directory vous pourriez le trouver sur google facilement. C'est la raison pour laquelle vous manage.py syncdb ne pas exécuter comme prévu.

Répertoire actuel : Il s'agit du répertoire à partir duquel votre shell ou processus parent est en cours d'exécution.

you are right "."  is for current directory.

Dans un système basé sur UNIX si vous avez votre fichier à /data/myfile.out alors vous traversez votre fichier à travers les noms de composants qui sont séparés par forward slash "/" donc si "." est votre répertoire actuel puis si vous voulez accéder (exécuter dans votre cas) le fichier qui se trouve dans votre répertoire actuel, vous devrez dire ./myexecutableFile.o. Si vous aviez votre fichier exécutable dans un autre dossier de votre répertoire actuel, vous feriez quelque chose comme ça ./myFiles/myexecutableFile.o. J'espère que vous avez ce que j'essaie d'expliquer.


-5
2018-02-16 10:01