Pourquoi dois-je taper `./` avant d'exécuter un programme dans le répertoire courant ?

La raison en est simple.

Supposons que vous ayez une commande portant le même nom qu'une application dans le répertoire courant. L'exécution de la commande dans le Shell invoquerait votre application. au lieu de de la commande intégrée. Il s'agirait d'un problème de sécurité, à défaut d'autre chose.

En exigeant ./ à utiliser devant, le Shell sait que vous voulez exécuter l'application avec le nom donné et non une commande intégrée avec ce nom.

./ exécute les fichiers qui ne sont pas dans votre $PATH il exécute plutôt le fichier dans le répertoire courant (ou dans un autre répertoire via la fonction ./home/stefano/script.sh ). Maintenant, PATH est une variable d'environnement qui contient tous les endroits où bash peut chercher des programmes exécutables, sans avoir le chemin complet (absolu) vers ceux-ci.

Cette séparation est nécessaire pour éviter d'exécuter le mauvais fichier. Par exemple, si vous avez un fichier appelé ls dans votre répertoire personnel, le fait qu'il ne soit pas dans votre PATH empêchera bash de le confondre avec le véritable programme ls . La variable PATH définit également l'ordre de recherche :

• Lorsque vous exécutez une commande, ou qu'un programme tente de faire une exec syscall (une méthode spéciale du noyau, qui permet de lancer des programmes), le système recherche le fichier en parcourant chacun des répertoires de votre PATH. Une fois le programme trouvé, même s'il se trouve dans plusieurs répertoires, la recherche est interrompue et le premier programme trouvé est exécuté.

Pour exécuter un fichier, vous devez définir le bit exécutable dans les autorisations :

• Puisque vous êtes déjà en ligne de commande, vous pouvez simplement taper chmod +x finename .

• Ou vous pouvez définir les autorisations en cliquant avec le bouton droit de la souris sur le fichier et en sélectionnant Propriétés :

Vous pouvez maintenant copier le fichier dans n'importe quel répertoire de PATH, pour voir lesquels s'y trouvent - et ils sont définis sur une base par utilisateur - tapez echo $PATH .

stefano@3000-G530:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Si vous créez un fichier exécutable, cat et le déplacer vers /usr/local/sbin il est exécuté à la place de l'option cat qui réside dans /bin . Vous pouvez savoir où se trouvent vos fichiers en utilisant la fonction type cat y whereis cat .

Pourquoi avez-vous besoin de taper ./ avant d'exécuter un programme ?

Dans le terminal, chaque fois que vous tapez le nom d'une application, disons gedit le terminal va chercher dans certains répertoires (prédéfinis) qui contiennent des applications (les binaires des applications). Les noms de ces répertoires sont contenus dans une variable appelée PATH . Vous pouvez voir ce qu'il y a dans cette variable en exécutant echo $PATH . Voir ces répertoires séparés par : ? Ce sont les répertoires dans lesquels le terminal va chercher, si vous tapez simplement gedit , nautilus ou a.out . Comme vous pouvez le constater, le chemin de votre a.out n'est pas là. Lorsque vous faites ./a.out vous dites au terminal "regarde dans le répertoire courant, et exécute a.out et ne va pas regarder dans PATH .

Solution 1

Si vous ne voulez pas taper ./ à chaque fois, vous devrez ajouter a.out dans le répertoire de $PATH . Dans les instructions suivantes, je supposerai que le chemin d'accès à l'application a.out es /path/to/programs/ mais vous devriez le changer pour votre chemin réel.

1. Il suffit d'ajouter la ligne suivante à la fin du fichier ~/.pam_environment :

   PATH DEFAULT=${PATH}:/path/to/programs

   _{<strong>Fuente: <a href="https://help.ubuntu.com/community/EnvironmentVariables#Persistent_environment_variables" rel="nofollow noreferrer">Variables d'environnement persistantes</a></strong>}

2. Déconnectez-vous et reconnectez-vous. Vous pouvez maintenant exécuter a.out sans ./ à partir de n'importe quel répertoire.

Si vous avez d'autres programmes dans d'autres répertoires, vous pouvez simplement les ajouter à la ligne ci-dessus. Cependant, je vous conseille d'avoir un répertoire appelé "mesProgrammes" par exemple, et d'y placer tous vos programmes.

Solution 2

Note : changement userName à votre nom d'utilisateur Ubuntu actuel.

Et si vous avez d'autres programmes que vous voulez exécuter ? Et qu'ils se trouvent tous dans des dossiers différents ? Eh bien, une solution "plus organisée" serait de créer un dossier appelé bin sous votre répertoire d'accueil, et ajoutez des liens symboliques (raccourcis) sous ce dossier. Voici comment procéder :

1. mkdir /home/userName/bin

   • Cela créera le dossier bin sous votre répertoire d'accueil.

2. ln -s /path/to/programs/a.out /home/userName/bin

   • Cela créera un "lien symbolique" (en gros, un raccourci) de votre fichier a.out dans le cadre du programme bin .
3. Déconnectez-vous et reconnectez-vous. Vous pouvez maintenant exécuter a.out sans ./ à partir de n'importe quel répertoire.

Maintenant, chaque fois que vous avez un autre programme ailleurs, disons que le programme b.in sur votre bureau, tout ce que vous avez à faire est de : ln -s /home/userName/Desktop/b.in /home/userName/bin et vous pourrez alors l'exécuter sans ./ également.

Note : grâce à Commentaire de @Joe Lorsque vous effectuez des sauvegardes, les liens symboliques doivent être traités de manière particulière. Par défaut, rsync ne les traite pas du tout, donc quand vous restaurez, ils ne sont pas là.

Comme George l'a souligné dans sa réponse, cela vous aide à noter que votre exécution de un fichier dans le répertoire de travail actuel ( pwd ).

Je me souviens avoir posé cette question à mon aîné il y a longtemps, il m'a dit que je devais rajouter . à mon chemin, de sorte que lorsque je fais a.out il cherche dans le répertoire courant et l'exécute. Dans ce cas, je n'ai pas besoin de faire ./a.out .

Mais, personnellement, je vous le déconseille. Cela ne m'est jamais arrivé, mais si vous êtes sur un répertoire réseau extraterrestre ou autre, et qu'un fichier exécutable malveillant appelé ls existe là, alors ayant . sur votre chemin est une très mauvaise idée. Ce n'est pas que vous rencontriez ce problème très souvent, mais c'est juste pour dire.