bonjour,
je suis newbie sous linux, et à l'occasion de l'installation de programmes, il faut entrer le texte suivant "./programme".
Dans la mesure où le fichier "programme existe" sans le "./", je voudrais savoir à quoi sert le ./
merci pour vos contributions.
# Execution?
Posté par halfelin . Évalué à -4.
[^] # Re: Execution?
Posté par Twidi (site web personnel) . Évalué à -1.
# Execution
Posté par krion . Évalué à 6.
ça va permettre d'executer un binaire (qui a les droits d'execution) qui ne se trouve pas dans un des répertoires de la variable $PATH.
La variable $PATH indique les répertoires à "fouiller" pour trouver les programmes.
% echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
Tu pourrais rajouter le répertoire dans lequel se trouve ton programme dans la variable $PATH (probablement ton $HOME), et tu n'aurais plus besoin de faire ./ , ou tu pourrais déplacer ton programme dans /usr/bin.
Je ne sais pas si j'ai été trés clair, mais je me comprends, et j'espère que tu m'auras compris !
[^] # Re: Execution
Posté par olivierho . Évalué à 2.
Un dernier point: je comprends que si le bin est dans $PATH, je peux le lancer directement sans ./
Il est donc normal que sans la bonne localisation, ou sans le ./, l'éxécution plante.
Merci encore
[^] # Re: Execution
Posté par jigso . Évalué à 3.
"." désigne le répertoire courant ('ls -a' donne en plus des fichiers "." et ".." qui sont le rép courant et le rép parent. D'où le "cd .."). Et "/" est le séparateur.
Pour lancer un programme, le shell a besoin de son nom et de son chemin.
Si on tape le nom sans chemin, le shell le cherche dans les répertoires de PATH.
Si on met un chemin, 2 cas :
- chemin absolu. par ex "/usr/bin/toto". Pas de problème, avec le chemin absolu le shell sait où se trouve le binaire.
- chemin relatif : foo/bar/toto. La recherche se fait par rapport au répertoire courant.
Donc si "." n'est pas dans le PATH - le cas le plus frequent -, pour lancer un script du répertoire courant la syntaxe la plus courte est bien "./toto" - ici on est dans le dernier cas, recherche par rapport au répertoire courant, le chemin final étant "/le/rep/courant/" + "./toto", cad "/le/rep/courant/./toto" Le "." ici est sans effet, on boucle en fait dans le même répertoire.
[^] # Re: Execution
Posté par halfelin . Évalué à -1.
[^] # Re: Execution
Posté par SQP . Évalué à 2.
/usr/local/bin est meme fait pour ca pour eviter de mélanger tes programmes et scripts à ceux du système. (et /usr/local/sbin pour les programmes a réserver à l'admin)
# Signification de "./"
Posté par tontonflingueur . Évalué à 4.
Donc "./programme" désigne le fichier programme qui se trouve dans le répertoire courant, de même que "../programme" désigne le fichier programme qui se trouve dans le répertoire parent.
Alors au sujet de savoir pourquoi on ne peut pas faire simplement "programme", il faut savoir que quant tu fais quelque chose comme "ls" depuis le shell, celui-ci va chercher à exécuter ls en utilisant le contenu de la variable d'environnement PATH (pour connaître ton PATH, il faut faire echo $PATH sous bash). Si ton PATH contient, "/bin:/usr/bin" et que tu fais ls, le shell va chercher d'abord à exécuter /bin/ls. S'il n'avait pas trouvé /bin/ls il aurait tenter d'exécuter /usr/bin/ls puis /usr/bin/ls, etc. Incidemment si tu ouvres une fenêtre de console, et que tu tentes de faire unset PATH, puis ls tu vas obtenir une erreur.
Il est possible de mettre le répertoire "." dans son PATH, (dans ce cas, la commande programme marche s'il y a bien un fichier exécutable programme) mais ça peut poser un problème de sécurité. Imagine que dans le répertoire /tmp un petit malin crée un script sl qui efface tout le disque (rm -rf /) et que root arrive dans le répertoire /tmp, qu'il tape sl au lieu de ls (ça m'arrive régulièrement). Je te laisse imaginer ce qui se passe.
Voilà
[^] # Re: Signification de "./"
Posté par olivierho . Évalué à 4.
je comprends pourquoi tu te fais appeler tonton flingueur: c'est pro et c'est rapide.
vos réponses sont très claires tant sur le fonctionnement que sur les raisons de ce fonctionnement.
J'imaginais pas de telles contributions dans un temps aussi record; j'avoue être impressionné par la qualité de ce forum (et de ses membres). Si j'avais un doute sur la grande supériorité de linux et de sa communité, vos réponses sont un beau témoignage que B. Gates a raison de se consacrer à sa fondation plutôt qu'à la chose informatique.
merci encore.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.