Quelle est la différence entre le nom de fichier et ./filename sous Linux

Quelle est la difference entre filenameet ./filename? Dans quelles circonstances l'un est-il préféré à l'autre?

Pour les fichiers de données, cela ne fait aucune différence - les deux instructions feront référence au fichier de données dans votre répertoire actuel. (Par exemple, cat filenameet cat ./filenamesont sémantiquement identiques.)

C'est une autre histoire si le nom de fichier en question se réfère à un exécutable , c'est-à-dire qu'il est la première (ou même la seule) chose que vous tapez sur la ligne de commande. ./filenamerecherchera l'exécutable dans votre répertoire actuel, et nulle part ailleurs. filename, d'autre part, évaluera la variable d'environnement PATHet recherchera filenamedans chaque répertoire qui y est stocké (qui pourrait ou non inclure votre répertoire actuel).

./filename(ou tout autre /path/to/filename) est donc préférable lorsque vous souhaitez exécuter un exécutable spécifique , pas le premier trouvé dans votre PATH.

Si vous exécutez un programme, filenamedit d'exécuter le premier trouvé dans votre $PATHet le second dit d'exécuter celui du répertoire courant.

Si vous utilisez ce nom de fichier comme argument dans un programme comme dans do_something filenameou do_something ./filenamealors ils signifient la même chose.

Vous parlez de l'exécution des commandes, non?

Il existe une variable d'environnement PATHqui contient certains répertoires système, délimités par un point-virgule. Lorsque vous tapez, commandle système recherche dans ces répertoires dans l'ordre où ils sont spécifiés pour rechercher un fichier exécutable nommé <commande> S'il le trouve, il essaie de l'exécuter. Vous pouvez voir votre CHEMIN via echo $PATHen bash. Par exemple:

$ echo $ PATH
/ sbin: / bin: / usr / sbin: / usr / bin: / usr / games: / usr / local / sbin: / usr / local / bin: / home / ivanatora / bin: / usr / local / kde4 / bin: / usr / local / kde4 / bin

Lorsque vous tapez, ./filenamevous spécifiez le chemin exact: le répertoire courant. Vous pouvez voir que le répertoire courant est rarement dans votre $ PATH (pour des raisons de sécurité). Donc, si vous voulez exécuter un fichier à partir du répertoire courant, vous utilisez ./filename.

Pour exécuter un fichier par son chemin (surtout s'il n'est pas dans $ PATH), vous pouvez également taper <path>/file, comme:

/ sbin / ifconfig

La sécurité exécutable est la principale raison de cette différence.

Tu ne veux pas . (présent répertoire de travail ou PWD) sur votre chemin parce que quelqu'un pourrait trojan http://en.wikipedia.org/wiki/Trojan_horse_%28computing%29 un exécutable crucial comme ps ou ls, dans votre PWD et vous tromper en présentant de mauvaises données.

Cela dépend des circonstances dans lesquelles vous l'utilisez.

En tant qu'argument, par exemple "nom de fichier du programme", cela dépend du programme, mais généralement ils sont identiques.

En tant que nom de programme, par exemple "arguments de nom de fichier", alors "arguments de nom de fichier" recherchera PATH pour trouver le binaire, tandis que "./ arguments de nom de fichier" utilisera le programme dans le répertoire courant. C'est évidemment utile si. n'est pas dans le CHEMIN, mais il est également utile d'utiliser celui-ci même si. est dans le chemin, peut-être parce qu'il correspond à une entrée antérieure.