Quand on veut passer une commande à partir d’un dossier et que l’on est déjà placé dans ce dossier, qu’est-il préférable de faire, ajouter le ./ ou ne rien ajouter 
$ cd /home/ricardo/dossierX
—:~/dossierX$ ma_commande_directement
ou
—:~/dossierX$ ./ma_commande
avantages/inconvénients
Bonjour,
La recherche d’un exécutable se fait par rapport au contenu de la variable PATH, l’ordre de déclaration des chemins est pris en compte (le premier en premier et le dernier en dernier).
Si le répertoire “.” fait partie de ta variable PATH et qu’il est en tête, tu peux utiliser ma_commande sans spécifier le répertoire courant puisque le contenu de ce répertoire sera analysé en premier.
Si le répertoire “.” fait partie de ta variable PATH mais qu’il est déclaré en fin de variable, tu peux utiliser ma_commande si son nom est unique (à vérifier avec which ma_commande). Tu peux faire un essai avec un script que tu nommes ls.
Si le répertoire “.” ne fait pas partie de la variable PATH, tu n’as pas le choix, il faut spécifier le répertoire.
Par contre, je ne sais pas s’il y a des différences de comportement dans des scripts en particulier quand on utilise des fonctions comme basename.
Quand je rajoute le répertoire courant (".") dans la variable PATH, je le met toujours en premier.
Ricardo,
Des fautes d’orthographe dans ton titre, c’est pas possible ! pas toi … 
Je suis outré !
[quote=“debianhadic”]Je suis outré ![/quote] 
Et pas une petite… 
Bonjour,
Oui c’est une histoire de path, mais il y a quelque chose de plus intéressant:
suppose ta commande un script:
ma_commande.sh =
cd rep1; ls
et un sous répertoire rep1
si tu fais: …/tmp$ ./ma_commande.sh cela fera un ls du contenu de rep1
si tu fais: …/tmp$ . ma_commande.sh cela fera un ls du contenu de rep1 et tu te retrouves sous …/tmp/rep1$, tu restes dans l’effet du cd rep1.
intéressant non le point détaché de la commande ? :smt003
[quote=“D5cro”]:smt006 Ricardo,
Des fautes d’orthographe dans ton titre, c’est pas possible ! pas toi … 
[/quote]
J’ai eu peur en te lisant 
Il ne s’agit, rassure-toi, que d’une faute de frappe. :smt003
Je la laisse, ça fera jaser :smt003
Salut,
Pas une mais deux 
Ma solution : Mes commandes sont placées dans le /home/ricardo/bin ce qui fait que moi Ricardo j’entre $ma_commande quel que soit le dossier où je me trouve. Mais c’est vrai que je suis particulièrement fainéant et comme nos développeurs ont prévu cette solution je l’emploie 
[quote=“ggoodluck47”]Salut,
Pas une mais deux
[/quote]
J’étais décidément, plus que distrait 
merci à tous pour vos réponses, qui m’éclairent.
En fait, en dehors d’une commande sur un script bien particulier, il ne doit pas y avoir d’inconvénient à ajouter systématiquement le ‘./’.
Salut,
Le “./” signifie “dans le répertoire où nous sommes”. Si par malheur tu as un fichier non exécutable du même nom dans ce répertoire il va prétendre que la commande est inconnue ou autre sornette du même genre
Préciser “./” est spécifique et moins flou que pas de précision du tout.
Prendre seulement garde de ne pas remplacer des commandes existantes du même nom.
Unix-haters handbook
ouvrage daté et même obsolète mais toujours intéressant (en anglais naturlisch)
[quote]So far, so good. However, PATH variables such as this are a common
disaster:
PATH=:.:/bin:/usr/bin:/usr/local/bin:
Having “.”—the current directory—as the first element instructs Unix to
search the current directory for commands before searching /bin. Doing so
is an incredible convenience when developing new programs. It is also a
powerful technique for cracking security by leaving traps for other users.
[/quote]
commentaires de 2008, pdf du livre téléchargeable ici :
Salut etxeberrizahar,
Ton “spécifique et moins flou” n’est-il pas en contradiction formelle avec “It is also a powerful technique for cracking security by leaving traps for other users”
Mon anglais n’est pas fameux mais il me semble quand même
C’est le cas particulier de $PATH où il est déconseillé d’y mettre en premier lieu “./” qui va court-circuiter les autres /bin /usr/bin …
Hors de ce cas , la commande “ancrée” en ./ est susceptible de faire moins de dégâts .
Les noms avec jokers à la "? * " sont
cantonnés au $PWD et ça vaut mieux comme ça.
Je nomme mon fichier “.” ou “*” ou “?” et j’essaye de le supprimmer
(INTERDICTION de les lancer sans réfléchir)
$ rm -f .
$ rm -f *
même exercice
je nomme mon fichier “-i” et j’essaye de le supprimer
$ rm -i -i
pleins de cas semblables dans unix-haters