avec Solaris l'executable se lance simplement en tapant son nom tant que
je suis dans le repertoire courant.
Avec Ubuntu j'ai le message d'erreur suivant : "bash:a.out:commande not
found". Je comprends que l'executable n'est pas recherché dans le
repertoire courant mais dans la liste des commandes de bash. Si c'est ça
pourquoi et comment y remedier autrement qu'en tapant './a.out' pour que
la recherche soit faite dans le repertoire courant?
Merci de votre aide.
--
Je suggère dinc de mettre aux voix le forum vers lequel doit être redirigé ce fil.
Sachant que la réponse a déjà été donné cinq fois, et que l'OP a déjà remercier deux fois pour les bonnes réponses...
Antoine
screetch
Hamiral wrote:
OUF ! J'ai cru que tout le monde allait lui dire de mettre . dans le PATH sans penser à la raison pour laquelle il n'y est pas ! certains systèmes le mettent, si mes souvenirs sont exacts le PATH
contient . dans la mandrake pour tous les utilisateurs sauf root
La conclusion est donc : ne JAMAIS mettre . dans le path, et toujours lancer les programme avec ./, tout simplement ...
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la machine, je ne vois pas l'interet de placer une sécurité pour un trojan qu'on aurait soi même placé. tout le monde n'a pas un serveur ouvert au réseau susceptible de recevoir des connexions telnet/ssh de la part d'utilisateurs inconnus (comme par exemple une machine de l'université).
de plus rien n'empeche de modifier le PATH d'un utilisateur (genre moi) ce qui réduit les risques de malveillance (tout le monde n'est pas root).
enfin, le mode "paranoïaque" ne doit pas empêcher les gens d'utiliser leur machine comme ils le souhaitent....
Hamiral wrote:
OUF !
J'ai cru que tout le monde allait lui dire de mettre . dans le PATH sans
penser à la raison pour laquelle il n'y est pas !
certains systèmes le mettent, si mes souvenirs sont exacts le PATH
contient . dans la mandrake pour tous les utilisateurs sauf root
La conclusion est donc : ne JAMAIS mettre . dans le path, et toujours
lancer les programme avec ./, tout simplement ...
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la
machine, je ne vois pas l'interet de placer une sécurité pour un trojan
qu'on aurait soi même placé. tout le monde n'a pas un serveur ouvert au
réseau susceptible de recevoir des connexions telnet/ssh de la part
d'utilisateurs inconnus (comme par exemple une machine de l'université).
de plus rien n'empeche de modifier le PATH d'un utilisateur (genre moi)
ce qui réduit les risques de malveillance (tout le monde n'est pas root).
enfin, le mode "paranoïaque" ne doit pas empêcher les gens d'utiliser
leur machine comme ils le souhaitent....
OUF ! J'ai cru que tout le monde allait lui dire de mettre . dans le PATH sans penser à la raison pour laquelle il n'y est pas ! certains systèmes le mettent, si mes souvenirs sont exacts le PATH
contient . dans la mandrake pour tous les utilisateurs sauf root
La conclusion est donc : ne JAMAIS mettre . dans le path, et toujours lancer les programme avec ./, tout simplement ...
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la machine, je ne vois pas l'interet de placer une sécurité pour un trojan qu'on aurait soi même placé. tout le monde n'a pas un serveur ouvert au réseau susceptible de recevoir des connexions telnet/ssh de la part d'utilisateurs inconnus (comme par exemple une machine de l'université).
de plus rien n'empeche de modifier le PATH d'un utilisateur (genre moi) ce qui réduit les risques de malveillance (tout le monde n'est pas root).
enfin, le mode "paranoïaque" ne doit pas empêcher les gens d'utiliser leur machine comme ils le souhaitent....
Stephane Chazelas
[this thread is not off-topic on fcou. [OT] l'est sur fr.* ;)]
On Wed, 25 Jan 2006 12:09:46 +0100, screetch wrote:
Hamiral wrote:
OUF ! J'ai cru que tout le monde allait lui dire de mettre . dans le PATH sans penser à la raison pour laquelle il n'y est pas !
certains systèmes le mettent, si mes souvenirs sont exacts le PATH contient . dans la mandrake pour tous les utilisateurs sauf root
La conclusion est donc : ne JAMAIS mettre . dans le path, et toujours lancer les programme avec ./, tout simplement ...
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la machine, je ne vois pas l'interet de placer une sécurité pour un trojan qu'on aurait soi même placé. tout le monde n'a pas un serveur ouvert au réseau susceptible de recevoir des connexions telnet/ssh de la part d'utilisateurs inconnus (comme par exemple une machine de l'université). [...]
Oui, mais c'est abherent de le mettre. Quand on lance "la-commande", on veut que la commande standard "la-commande" soit lancée et que ca soit toujours la meme. Si on veut lancer la-commande qui se trouve dans tel ou tel repertoire, alors on specified le chemin et c'est valable pareil pour le repertoire courant. Pourquoi ne pas rajouter ".." aussi dans $PATH, tant qu'on y est ?
[...]
enfin, le mode "paranoïaque" ne doit pas empêcher les gens d'utiliser leur machine comme ils le souhaitent....
Pour, moi, ce n'est pas une question de paranoïa, mais de bon sens.
-- Stephane
[this thread is not off-topic on fcou. [OT] l'est sur fr.* ;)]
On Wed, 25 Jan 2006 12:09:46 +0100, screetch wrote:
Hamiral wrote:
OUF !
J'ai cru que tout le monde allait lui dire de mettre . dans le PATH sans
penser à la raison pour laquelle il n'y est pas !
certains systèmes le mettent, si mes souvenirs sont exacts le PATH
contient . dans la mandrake pour tous les utilisateurs sauf root
La conclusion est donc : ne JAMAIS mettre . dans le path, et toujours
lancer les programme avec ./, tout simplement ...
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la
machine, je ne vois pas l'interet de placer une sécurité pour un trojan
qu'on aurait soi même placé. tout le monde n'a pas un serveur ouvert au
réseau susceptible de recevoir des connexions telnet/ssh de la part
d'utilisateurs inconnus (comme par exemple une machine de l'université).
[...]
Oui, mais c'est abherent de le mettre. Quand on lance
"la-commande", on veut que la commande standard "la-commande"
soit lancée et que ca soit toujours la meme. Si on veut lancer
la-commande qui se trouve dans tel ou tel repertoire, alors on
specified le chemin et c'est valable pareil pour le repertoire
courant. Pourquoi ne pas rajouter ".." aussi dans $PATH, tant
qu'on y est ?
[...]
enfin, le mode "paranoïaque" ne doit pas empêcher les gens d'utiliser
leur machine comme ils le souhaitent....
Pour, moi, ce n'est pas une question de paranoïa, mais de bon
sens.
[this thread is not off-topic on fcou. [OT] l'est sur fr.* ;)]
On Wed, 25 Jan 2006 12:09:46 +0100, screetch wrote:
Hamiral wrote:
OUF ! J'ai cru que tout le monde allait lui dire de mettre . dans le PATH sans penser à la raison pour laquelle il n'y est pas !
certains systèmes le mettent, si mes souvenirs sont exacts le PATH contient . dans la mandrake pour tous les utilisateurs sauf root
La conclusion est donc : ne JAMAIS mettre . dans le path, et toujours lancer les programme avec ./, tout simplement ...
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la machine, je ne vois pas l'interet de placer une sécurité pour un trojan qu'on aurait soi même placé. tout le monde n'a pas un serveur ouvert au réseau susceptible de recevoir des connexions telnet/ssh de la part d'utilisateurs inconnus (comme par exemple une machine de l'université). [...]
Oui, mais c'est abherent de le mettre. Quand on lance "la-commande", on veut que la commande standard "la-commande" soit lancée et que ca soit toujours la meme. Si on veut lancer la-commande qui se trouve dans tel ou tel repertoire, alors on specified le chemin et c'est valable pareil pour le repertoire courant. Pourquoi ne pas rajouter ".." aussi dans $PATH, tant qu'on y est ?
[...]
enfin, le mode "paranoïaque" ne doit pas empêcher les gens d'utiliser leur machine comme ils le souhaitent....
Pour, moi, ce n'est pas une question de paranoïa, mais de bon sens.
-- Stephane
screetch
Stephane Chazelas wrote:
[this thread is not off-topic on fcou. [OT] l'est sur fr.* ;)] désolé j'ai oublié de retirer fcou de peur de me faire bâcher par des
gens calés. ca m'apprendra...
Oui, mais c'est abherent de le mettre. Quand on lance "la-commande", on veut que la commande standard "la-commande" soit lancée et que ca soit toujours la meme. Si on veut lancer la-commande qui se trouve dans tel ou tel repertoire, alors on specified le chemin et c'est valable pareil pour le repertoire courant. Pourquoi ne pas rajouter ".." aussi dans $PATH, tant qu'on y est ? je ne nie pas ca, je parlais d'un point de vue sécurité, d'ailleurs je
ne l'ai pas mis sur ma machine (qui n'est ouverte qu'a moi et non reliée au réseau) bien que ce soit une machine de dev ou le ./projet est assez fréquent. je NIE par contre l'aspect sécurité du machin parce que bidule va mettre l'exe chose dans tmp sur une machine utilisée par...juste moi...
Pour, moi, ce n'est pas une question de paranoïa, mais de bon sens.
non couvert par mon post original :)
Stephane Chazelas wrote:
[this thread is not off-topic on fcou. [OT] l'est sur fr.* ;)]
désolé j'ai oublié de retirer fcou de peur de me faire bâcher par des
gens calés. ca m'apprendra...
Oui, mais c'est abherent de le mettre. Quand on lance
"la-commande", on veut que la commande standard "la-commande"
soit lancée et que ca soit toujours la meme. Si on veut lancer
la-commande qui se trouve dans tel ou tel repertoire, alors on
specified le chemin et c'est valable pareil pour le repertoire
courant. Pourquoi ne pas rajouter ".." aussi dans $PATH, tant
qu'on y est ?
je ne nie pas ca, je parlais d'un point de vue sécurité, d'ailleurs je
ne l'ai pas mis sur ma machine (qui n'est ouverte qu'a moi et non reliée
au réseau) bien que ce soit une machine de dev ou le ./projet est assez
fréquent. je NIE par contre l'aspect sécurité du machin parce que bidule
va mettre l'exe chose dans tmp sur une machine utilisée par...juste moi...
Pour, moi, ce n'est pas une question de paranoïa, mais de bon
sens.
[this thread is not off-topic on fcou. [OT] l'est sur fr.* ;)] désolé j'ai oublié de retirer fcou de peur de me faire bâcher par des
gens calés. ca m'apprendra...
Oui, mais c'est abherent de le mettre. Quand on lance "la-commande", on veut que la commande standard "la-commande" soit lancée et que ca soit toujours la meme. Si on veut lancer la-commande qui se trouve dans tel ou tel repertoire, alors on specified le chemin et c'est valable pareil pour le repertoire courant. Pourquoi ne pas rajouter ".." aussi dans $PATH, tant qu'on y est ? je ne nie pas ca, je parlais d'un point de vue sécurité, d'ailleurs je
ne l'ai pas mis sur ma machine (qui n'est ouverte qu'a moi et non reliée au réseau) bien que ce soit une machine de dev ou le ./projet est assez fréquent. je NIE par contre l'aspect sécurité du machin parce que bidule va mettre l'exe chose dans tmp sur une machine utilisée par...juste moi...
Pour, moi, ce n'est pas une question de paranoïa, mais de bon sens.
non couvert par mon post original :)
Christophe Gaubert
certains systèmes le mettent, si mes souvenirs sont exacts le PATH contient . dans la mandrake pour tous les utilisateurs sauf root
Je proteste, je suis sous Mandriva (et auparavant sous Mandrake), et je n'ai pas . dans mon PATH.
-- Christophe Gaubert Mail posté depuis un système libre GNU/Linux
certains systèmes le mettent, si mes souvenirs sont exacts le PATH
contient . dans la mandrake pour tous les utilisateurs sauf root
Je proteste, je suis sous Mandriva (et auparavant sous Mandrake), et je
n'ai pas . dans mon PATH.
--
Christophe Gaubert
Mail posté depuis un système libre GNU/Linux
Je proteste, je suis sous Mandriva (et auparavant sous Mandrake), et je n'ai pas . dans mon PATH.
ah j'ai bien dit mandrake, pas mandriva (j'ai pas testé). Je crois
bien me souvenir que c'etait vrai sous mandrake 9
Ah si on parle des vieilleries :p Je suis arrivé avec la 10.0.
de mémoire RedHat l'utilisait aussi, mais la je suis moins sûr
Je ne me souviens plus.
-- Christophe Gaubert Mail posté depuis un système libre GNU/Linux
deub
Il est dangereux de lister dans cette variable PATH le répertoire courant, car si un utilisateur malveillant peut placer des programmes de même nom que les commandes standards (ls, vi, ps, etc) dans des répertoires où tu tapes ces commandes, tu risque d'exécuter pour ton compte ces programmes malveillants au lieu des commandes normales.
Donc, si tu veux vivre dangereusement, tu peux ajouter le répertoire courant au PATH en insérant la commande:
export PATH="${PATH}:."
Je ne vois pas trop en quoi c'est dangereux. Le '.' étant placé à la fin, si je tape ls, c'est bien le bon ls qui sera exécuté et pas un éventuel ls présent dans mon répertoire courant. Ce qui me semble dangereux, c'est : export PATH=".:${PATH}"
Il est dangereux de lister dans cette variable PATH le répertoire
courant, car si un utilisateur malveillant peut placer des programmes
de même nom que les commandes standards (ls, vi, ps, etc) dans des
répertoires où tu tapes ces commandes, tu risque d'exécuter pour ton
compte ces programmes malveillants au lieu des commandes normales.
Donc, si tu veux vivre dangereusement, tu peux ajouter le répertoire
courant au PATH en insérant la commande:
export PATH="${PATH}:."
Je ne vois pas trop en quoi c'est dangereux.
Le '.' étant placé à la fin, si je tape ls, c'est bien le bon ls qui sera
exécuté et pas un éventuel ls présent dans mon répertoire courant.
Ce qui me semble dangereux, c'est : export PATH=".:${PATH}"
Il est dangereux de lister dans cette variable PATH le répertoire courant, car si un utilisateur malveillant peut placer des programmes de même nom que les commandes standards (ls, vi, ps, etc) dans des répertoires où tu tapes ces commandes, tu risque d'exécuter pour ton compte ces programmes malveillants au lieu des commandes normales.
Donc, si tu veux vivre dangereusement, tu peux ajouter le répertoire courant au PATH en insérant la commande:
export PATH="${PATH}:."
Je ne vois pas trop en quoi c'est dangereux. Le '.' étant placé à la fin, si je tape ls, c'est bien le bon ls qui sera exécuté et pas un éventuel ls présent dans mon répertoire courant. Ce qui me semble dangereux, c'est : export PATH=".:${PATH}"
Paul Gaborit
À (at) Wed, 25 Jan 2006 18:16:47 +0100, "deub" écrivait (wrote):
Donc, si tu veux vivre dangereusement, tu peux ajouter le répertoire courant au PATH en insérant la commande:
export PATH="${PATH}:."
Je ne vois pas trop en quoi c'est dangereux. Le '.' étant placé à la fin, si je tape ls, c'est bien le bon ls qui sera exécuté et pas un éventuel ls présent dans mon répertoire courant.
Et les fautes de frappes (ex: 'mroe' à la place de 'more') ? C'est moins courant mais ça arrive à tout le monde !
L'une des fautes de frappe les plus courantes est l'inversion de deux lettres entre main gauche et main droite. C'est pour cela que de nombreux éditeurs de texte proposent un raccourci pour inverser deux lettres (ctrl-t dans (x)emacs).
Ce qui me semble dangereux, c'est : export PATH=".:${PATH}"
Là, c'est mortel ! ;-)
À l'inverse, si '.' n'est pas dans le PATH, on voit souvent les débutants en programmation ne plus rien comprendre :
% cc -o test test.c % test %
« Pourquoi il ne m'affiche pas "Hello World !" ? »
;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 25 Jan 2006 18:16:47 +0100,
"deub" <deub@hotmail.com> écrivait (wrote):
Donc, si tu veux vivre dangereusement, tu peux ajouter le répertoire
courant au PATH en insérant la commande:
export PATH="${PATH}:."
Je ne vois pas trop en quoi c'est dangereux.
Le '.' étant placé à la fin, si je tape ls, c'est bien le bon ls qui sera
exécuté et pas un éventuel ls présent dans mon répertoire courant.
Et les fautes de frappes (ex: 'mroe' à la place de 'more') ? C'est
moins courant mais ça arrive à tout le monde !
L'une des fautes de frappe les plus courantes est l'inversion de deux
lettres entre main gauche et main droite. C'est pour cela que de
nombreux éditeurs de texte proposent un raccourci pour inverser deux
lettres (ctrl-t dans (x)emacs).
Ce qui me semble dangereux, c'est : export PATH=".:${PATH}"
Là, c'est mortel ! ;-)
À l'inverse, si '.' n'est pas dans le PATH, on voit souvent les
débutants en programmation ne plus rien comprendre :
% cc -o test test.c
% test
%
« Pourquoi il ne m'affiche pas "Hello World !" ? »
;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 25 Jan 2006 18:16:47 +0100, "deub" écrivait (wrote):
Donc, si tu veux vivre dangereusement, tu peux ajouter le répertoire courant au PATH en insérant la commande:
export PATH="${PATH}:."
Je ne vois pas trop en quoi c'est dangereux. Le '.' étant placé à la fin, si je tape ls, c'est bien le bon ls qui sera exécuté et pas un éventuel ls présent dans mon répertoire courant.
Et les fautes de frappes (ex: 'mroe' à la place de 'more') ? C'est moins courant mais ça arrive à tout le monde !
L'une des fautes de frappe les plus courantes est l'inversion de deux lettres entre main gauche et main droite. C'est pour cela que de nombreux éditeurs de texte proposent un raccourci pour inverser deux lettres (ctrl-t dans (x)emacs).
Ce qui me semble dangereux, c'est : export PATH=".:${PATH}"
Là, c'est mortel ! ;-)
À l'inverse, si '.' n'est pas dans le PATH, on voit souvent les débutants en programmation ne plus rien comprendre :
% cc -o test test.c % test %
« Pourquoi il ne m'affiche pas "Hello World !" ? »
;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Harpo
screetch wrote:
Hamiral wrote:
OUF ! J'ai cru que tout le monde allait lui dire de mettre . dans le PATH sans penser à la raison pour laquelle il n'y est pas !
certains systèmes le mettent, si mes souvenirs sont exacts le PATH contient . dans la mandrake pour tous les utilisateurs sauf root
Même si l'utilisateur est un 'sudoer' ? L'utilisateur peut aussi faire 'su', cela arrive souvent sur une machine perso, voire les options -m et -p permettant de garder le même environnement, il n'est pas certain que tous les *nix resettent la variable PATH.
De plus, il y a un problème de cohérence, une même commande où un même script pourrait ne pas faire quelque chose des similaire suivant la directory dans laquelle il est exécuté, cela arriverait souvent dans les directories dans lequel on a des programmes en développement.
Le plus simple et le plus fiable est d'utilise './command'.
La conclusion est donc : ne JAMAIS mettre . dans le path, et toujours lancer les programme avec ./, tout simplement ...
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la machine, je ne vois pas l'interet de placer une sécurité pour un trojan qu'on aurait soi même placé.
/tmp est 'world writable' avec le sticky bit on, ça ne doit pas être très difficile pour un cracker débutant avec des problèmes d'acnée juvénile d'y mettre ce qu'il veut.
tout le monde n'a pas un serveur ouvert au réseau susceptible de recevoir des connexions telnet/ssh de la part d'utilisateurs inconnus (comme par exemple une machine de l'université).
Il est quand même préférable de voir quels ports sont ouverts.
de plus rien n'empeche de modifier le PATH d'un utilisateur (genre moi) ce qui réduit les risques de malveillance (tout le monde n'est pas root).
enfin, le mode "paranoïaque" ne doit pas empêcher les gens d'utiliser leur machine comme ils le souhaitent....
Chacun fait ce qu'il veut.
FU2
-- http://harpo.free.fr/
screetch wrote:
Hamiral wrote:
OUF !
J'ai cru que tout le monde allait lui dire de mettre . dans le PATH
sans penser à la raison pour laquelle il n'y est pas !
certains systèmes le mettent, si mes souvenirs sont exacts le PATH
contient . dans la mandrake pour tous les utilisateurs sauf root
Même si l'utilisateur est un 'sudoer' ?
L'utilisateur peut aussi faire 'su', cela arrive souvent sur une machine
perso, voire les options -m et -p permettant de garder le même
environnement, il n'est pas certain que tous les *nix resettent la
variable PATH.
De plus, il y a un problème de cohérence, une même commande où un même
script pourrait ne pas faire quelque chose des similaire suivant la
directory dans laquelle il est exécuté, cela arriverait souvent dans
les directories dans lequel on a des programmes en développement.
Le plus simple et le plus fiable est d'utilise './command'.
La conclusion est donc : ne JAMAIS mettre . dans le path, et toujours
lancer les programme avec ./, tout simplement ...
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la
machine, je ne vois pas l'interet de placer une sécurité pour un
trojan qu'on aurait soi même placé.
/tmp est 'world writable' avec le sticky bit on, ça ne doit pas être
très difficile pour un cracker débutant avec des problèmes d'acnée
juvénile d'y mettre ce qu'il veut.
tout le monde n'a pas un serveur
ouvert au réseau susceptible de recevoir des connexions telnet/ssh de
la part d'utilisateurs inconnus (comme par exemple une machine de
l'université).
Il est quand même préférable de voir quels ports sont ouverts.
de plus rien n'empeche de modifier le PATH d'un utilisateur (genre
moi) ce qui réduit les risques de malveillance (tout le monde n'est
pas root).
enfin, le mode "paranoïaque" ne doit pas empêcher les gens d'utiliser
leur machine comme ils le souhaitent....
OUF ! J'ai cru que tout le monde allait lui dire de mettre . dans le PATH sans penser à la raison pour laquelle il n'y est pas !
certains systèmes le mettent, si mes souvenirs sont exacts le PATH contient . dans la mandrake pour tous les utilisateurs sauf root
Même si l'utilisateur est un 'sudoer' ? L'utilisateur peut aussi faire 'su', cela arrive souvent sur une machine perso, voire les options -m et -p permettant de garder le même environnement, il n'est pas certain que tous les *nix resettent la variable PATH.
De plus, il y a un problème de cohérence, une même commande où un même script pourrait ne pas faire quelque chose des similaire suivant la directory dans laquelle il est exécuté, cela arriverait souvent dans les directories dans lequel on a des programmes en développement.
Le plus simple et le plus fiable est d'utilise './command'.
La conclusion est donc : ne JAMAIS mettre . dans le path, et toujours lancer les programme avec ./, tout simplement ...
hmmm, un tit bémol général, si il n'y a qu'un utilisateur sur la machine, je ne vois pas l'interet de placer une sécurité pour un trojan qu'on aurait soi même placé.
/tmp est 'world writable' avec le sticky bit on, ça ne doit pas être très difficile pour un cracker débutant avec des problèmes d'acnée juvénile d'y mettre ce qu'il veut.
tout le monde n'a pas un serveur ouvert au réseau susceptible de recevoir des connexions telnet/ssh de la part d'utilisateurs inconnus (comme par exemple une machine de l'université).
Il est quand même préférable de voir quels ports sont ouverts.
de plus rien n'empeche de modifier le PATH d'un utilisateur (genre moi) ce qui réduit les risques de malveillance (tout le monde n'est pas root).
enfin, le mode "paranoïaque" ne doit pas empêcher les gens d'utiliser leur machine comme ils le souhaitent....
Chacun fait ce qu'il veut.
FU2
-- http://harpo.free.fr/
Stephane Chazelas
On Wed, 25 Jan 2006 18:16:47 +0100, deub wrote: [...]
export PATH="${PATH}:."
Je ne vois pas trop en quoi c'est dangereux. Le '.' étant placé à la fin, si je tape ls, c'est bien le bon ls qui sera exécuté et pas un éventuel ls présent dans mon répertoire courant.
Sauf qu'un "sl" dans /tmp finira par attrapper quelqu'un qui est un peu dyslexique ou a les doigts potelés.
Ce qui me semble dangereux, c'est : export PATH=".:${PATH}"
C'est encore plus dangereux, c'est sur et ca fait encore moins de sens.
A noter aussi que dans
PATH=:/bin
ou
PATH=/bin:
ou
PATH Le repertoire courant est aussi recherché.
Si la variable PATH n'est pas positionnee (ce qui est different de vide), en general, c'est un PATH par defaut qui est utilisé, mais ca va dependre du shell, ou de la libc (pour les exec*p) ou de l'application...
Chez Solaris (au moins 7), ce PATH par defaut dans la libc contient le repertoire courant!
On Wed, 25 Jan 2006 18:16:47 +0100, deub wrote:
[...]
export PATH="${PATH}:."
Je ne vois pas trop en quoi c'est dangereux.
Le '.' étant placé à la fin, si je tape ls, c'est bien le bon ls qui sera
exécuté et pas un éventuel ls présent dans mon répertoire courant.
Sauf qu'un "sl" dans /tmp finira par attrapper quelqu'un qui est
un peu dyslexique ou a les doigts potelés.
Ce qui me semble dangereux, c'est : export PATH=".:${PATH}"
C'est encore plus dangereux, c'est sur et ca fait encore moins
de sens.
A noter aussi que dans
PATH=:/bin
ou
PATH=/bin:
ou
PATH
Le repertoire courant est aussi recherché.
Si la variable PATH n'est pas positionnee (ce qui est different
de vide), en general, c'est un PATH par defaut qui est utilisé,
mais ca va dependre du shell, ou de la libc (pour les exec*p) ou de
l'application...
Chez Solaris (au moins 7), ce PATH par defaut dans la libc
contient le repertoire courant!
On Wed, 25 Jan 2006 18:16:47 +0100, deub wrote: [...]
export PATH="${PATH}:."
Je ne vois pas trop en quoi c'est dangereux. Le '.' étant placé à la fin, si je tape ls, c'est bien le bon ls qui sera exécuté et pas un éventuel ls présent dans mon répertoire courant.
Sauf qu'un "sl" dans /tmp finira par attrapper quelqu'un qui est un peu dyslexique ou a les doigts potelés.
Ce qui me semble dangereux, c'est : export PATH=".:${PATH}"
C'est encore plus dangereux, c'est sur et ca fait encore moins de sens.
A noter aussi que dans
PATH=:/bin
ou
PATH=/bin:
ou
PATH Le repertoire courant est aussi recherché.
Si la variable PATH n'est pas positionnee (ce qui est different de vide), en general, c'est un PATH par defaut qui est utilisé, mais ca va dependre du shell, ou de la libc (pour les exec*p) ou de l'application...
Chez Solaris (au moins 7), ce PATH par defaut dans la libc contient le repertoire courant!
