J'ai souvent le même problème lorque j'essaye
d'installer des programmes à partir des sources :
lorsque les sources sont réparties dans une arborescence
qui contient des sous-répertoires dans lesquels sont
définis des Makefile spécifiques, make n'arrive pas à
trouver ces sous répertoires.
Un exemple, parceque je sens que je ne suis pas très clair:
le Makefile principal contient la ligne:
SUBDIRS = doc maths (*)
La compilation s'arrête avec:
/bin/sh: line 1: cd: doc: No such file or directory
J'arrive à corriger le problème en changeant doc par ./doc
dans (*), mais c'est pas très pratique quand il y a beaucoup
de sous-répertoires.
Un exemple, parceque je sens que je ne suis pas très clair: le Makefile principal contient la ligne:
SUBDIRS = doc maths (*)
La compilation s'arrête avec:
/bin/sh: line 1: cd: doc: No such file or directory
J'arrive à corriger le problème en changeant doc par ./doc dans (*), mais c'est pas très pratique quand il y a beaucoup de sous-répertoires.
Tu devrais commencer par updater make... C'est sans doute lui qui est buggé...
Lsom
Est-ce que ca n'est pas un pb de PATH.
Dans ta variable PATH, as-tu le directory courant ? A savoir : .
Genre : PATH=/bin:/usr/bin:.
Attention de bien mettre le . en fin de path, histoire que qqun qui se se rait introduit sur ton compte et aurait redéfini un commande courante genre "ls" ne soit pas exécuté (car trouvé avant dans le PATH standard).
Ton erreur m'a fait pensé à ca. C'est peut etre à coté mais bon.. .
Est-ce que ca n'est pas un pb de PATH.
Dans ta variable PATH, as-tu le directory courant ? A savoir : .
Genre : PATH=/bin:/usr/bin:.
Attention de bien mettre le . en fin de path, histoire que qqun qui se se rait
introduit sur ton compte et aurait redéfini un commande courante genre "ls" ne
soit pas exécuté (car trouvé avant dans le PATH standard).
Ton erreur m'a fait pensé à ca. C'est peut etre à coté mais bon.. .
Dans ta variable PATH, as-tu le directory courant ? A savoir : .
Genre : PATH=/bin:/usr/bin:.
Attention de bien mettre le . en fin de path, histoire que qqun qui se se rait introduit sur ton compte et aurait redéfini un commande courante genre "ls" ne soit pas exécuté (car trouvé avant dans le PATH standard).
Ton erreur m'a fait pensé à ca. C'est peut etre à coté mais bon.. .
Yves Kuhry
J. Mayer wrote:
On Thu, 18 Dec 2003 00:09:40 +0000, Tux wrote:
Un exemple, parceque je sens que je ne suis pas très clair: le Makefile principal contient la ligne:
SUBDIRS = doc maths (*)
La compilation s'arrête avec:
/bin/sh: line 1: cd: doc: No such file or directory
J'arrive à corriger le problème en changeant doc par ./doc dans (*), mais c'est pas très pratique quand il y a beaucoup de sous-répertoires.
Tu devrais commencer par updater make... C'est sans doute lui qui est buggé...
ok, je pensais que c'était un problème de configuration, d'où le choix de ce newsgroup.
merci
J. Mayer wrote:
On Thu, 18 Dec 2003 00:09:40 +0000, Tux wrote:
Un exemple, parceque je sens que je ne suis pas très clair:
le Makefile principal contient la ligne:
SUBDIRS = doc maths (*)
La compilation s'arrête avec:
/bin/sh: line 1: cd: doc: No such file or directory
J'arrive à corriger le problème en changeant doc par ./doc
dans (*), mais c'est pas très pratique quand il y a beaucoup
de sous-répertoires.
Tu devrais commencer par updater make...
C'est sans doute lui qui est buggé...
ok, je pensais que c'était un problème de configuration,
d'où le choix de ce newsgroup.
Un exemple, parceque je sens que je ne suis pas très clair: le Makefile principal contient la ligne:
SUBDIRS = doc maths (*)
La compilation s'arrête avec:
/bin/sh: line 1: cd: doc: No such file or directory
J'arrive à corriger le problème en changeant doc par ./doc dans (*), mais c'est pas très pratique quand il y a beaucoup de sous-répertoires.
Tu devrais commencer par updater make... C'est sans doute lui qui est buggé...
ok, je pensais que c'était un problème de configuration, d'où le choix de ce newsgroup.
merci
J. Mayer
On Thu, 18 Dec 2003 12:59:35 +0100, Lsom wrote:
Est-ce que ca n'est pas un pb de PATH.
Dans ta variable PATH, as-tu le directory courant ? A savoir : .
Genre : PATH=/bin:/usr/bin:.
Attention de bien mettre le . en fin de path, histoire que qqun qui se serait introduit sur ton compte et aurait redéfini un commande courante genre "ls" ne soit pas exécuté (car trouvé avant dans le PATH standard).
Ton erreur m'a fait pensé à ca. C'est peut etre à coté mais bon...
make ne se sert pas du PATH pour trouver les répertoires dans lesquels il peut récurser. PATH sert uniquement pour les appels de la famille des exec... Et mettre '.' dans le PATH est un énorme trou de sécurité, un grand classique, en fait... make a peut-être une variable de config propre pour rechercher les répertoires (dans le même style que VPATH), mais il est certain que ce n'est pas PATH.
On Thu, 18 Dec 2003 12:59:35 +0100, Lsom wrote:
Est-ce que ca n'est pas un pb de PATH.
Dans ta variable PATH, as-tu le directory courant ? A savoir : .
Genre : PATH=/bin:/usr/bin:.
Attention de bien mettre le . en fin de path, histoire que qqun qui se serait
introduit sur ton compte et aurait redéfini un commande courante genre "ls" ne
soit pas exécuté (car trouvé avant dans le PATH standard).
Ton erreur m'a fait pensé à ca. C'est peut etre à coté mais bon...
make ne se sert pas du PATH pour trouver les répertoires dans
lesquels il peut récurser. PATH sert uniquement pour les appels
de la famille des exec... Et mettre '.' dans le PATH est un énorme
trou de sécurité, un grand classique, en fait...
make a peut-être une variable de config propre pour rechercher les
répertoires (dans le même style que VPATH), mais il est certain que
ce n'est pas PATH.
Dans ta variable PATH, as-tu le directory courant ? A savoir : .
Genre : PATH=/bin:/usr/bin:.
Attention de bien mettre le . en fin de path, histoire que qqun qui se serait introduit sur ton compte et aurait redéfini un commande courante genre "ls" ne soit pas exécuté (car trouvé avant dans le PATH standard).
Ton erreur m'a fait pensé à ca. C'est peut etre à coté mais bon...
make ne se sert pas du PATH pour trouver les répertoires dans lesquels il peut récurser. PATH sert uniquement pour les appels de la famille des exec... Et mettre '.' dans le PATH est un énorme trou de sécurité, un grand classique, en fait... make a peut-être une variable de config propre pour rechercher les répertoires (dans le même style que VPATH), mais il est certain que ce n'est pas PATH.
g.patel
On Thu, 18 Dec 2003 12:59:35 +0100, Lsom wrote:
Est-ce que ca n'est pas un pb de PATH.
Dans ta variable PATH, as-tu le directory courant ? A savoir : .
Genre : PATH=/bin:/usr/bin:.
non, make ne suppose pas que le répertoire courant soit dans le PATH. Ce n'est pas la raison du problème. Merci de respecter les regles usuelles pour répondre sur Usenet. (citer au début du message un texte suffisant pour donner le contexte)
Gérard Patel
On Thu, 18 Dec 2003 12:59:35 +0100, Lsom <lsom@free.fr> wrote:
Est-ce que ca n'est pas un pb de PATH.
Dans ta variable PATH, as-tu le directory courant ? A savoir : .
Genre : PATH=/bin:/usr/bin:.
non, make ne suppose pas que le répertoire courant soit dans
le PATH. Ce n'est pas la raison du problème.
Merci de respecter les regles usuelles pour répondre sur Usenet.
(citer au début du message un texte suffisant pour donner le
contexte)
Dans ta variable PATH, as-tu le directory courant ? A savoir : .
Genre : PATH=/bin:/usr/bin:.
non, make ne suppose pas que le répertoire courant soit dans le PATH. Ce n'est pas la raison du problème. Merci de respecter les regles usuelles pour répondre sur Usenet. (citer au début du message un texte suffisant pour donner le contexte)
Gérard Patel
Motodashi
de la famille des exec... Et mettre '.' dans le PATH est un énorme trou de sécurité, un grand classique, en fait...
Pourquoi c'est un trou de securite ?
-- <Mooby> dites comment on fait pour lancer un prg sous NT? on double clique dessus, c'est bien ca ?
- #linuxfr
de la famille des exec... Et mettre '.' dans le PATH est un énorme
trou de sécurité, un grand classique, en fait...
Pourquoi c'est un trou de securite ?
--
<Mooby> dites comment on fait pour lancer un prg sous NT? on double
clique dessus, c'est bien ca ?
de la famille des exec... Et mettre '.' dans le PATH est un énorme trou de sécurité, un grand classique, en fait...
Pourquoi c'est un trou de securite ?
-- <Mooby> dites comment on fait pour lancer un prg sous NT? on double clique dessus, c'est bien ca ?
- #linuxfr
Richard Delorme
de la famille des exec... Et mettre '.' dans le PATH est un énorme trou de sécurité, un grand classique, en fait...
Pourquoi c'est un trou de securite ?
Exemple de scénario : un malin écrit un script exécutable qu'il appelle ls, qu'il place dans /tmp et qui contient la ligne « rm -r / ». Maintenant l'utilisateur root, qui a mis . dans sont path veux nettoyer /tmp. Il fait : # cd /tmp # ls et surprise !
-- Richard
de la famille des exec... Et mettre '.' dans le PATH est un énorme
trou de sécurité, un grand classique, en fait...
Pourquoi c'est un trou de securite ?
Exemple de scénario : un malin écrit un script exécutable qu'il appelle ls,
qu'il place dans /tmp et qui contient la ligne « rm -r / ». Maintenant
l'utilisateur root, qui a mis . dans sont path veux nettoyer /tmp. Il
fait :
# cd /tmp
# ls
et surprise !
de la famille des exec... Et mettre '.' dans le PATH est un énorme trou de sécurité, un grand classique, en fait...
Pourquoi c'est un trou de securite ?
Exemple de scénario : un malin écrit un script exécutable qu'il appelle ls, qu'il place dans /tmp et qui contient la ligne « rm -r / ». Maintenant l'utilisateur root, qui a mis . dans sont path veux nettoyer /tmp. Il fait : # cd /tmp # ls et surprise !
-- Richard
Lsom
Richard Delorme wrote:
# ls et surprise !
Sauf si, comme je le disais, le "." est en fin de PATH. les commandes user seront considérées en dernier.
Je concois que ca limite seulement la casse. C'est pour ca que je l'ai si gnalé.
Richard Delorme wrote:
# ls
et surprise !
Sauf si, comme je le disais, le "." est en fin de PATH.
les commandes user seront considérées en dernier.
Je concois que ca limite seulement la casse. C'est pour ca que je l'ai si gnalé.
Sauf si, comme je le disais, le "." est en fin de PATH. les commandes user seront considérées en dernier.
Je concois que ca limite seulement la casse. C'est pour ca que je l'ai si gnalé.
Motodashi
Le Thu, 18 Dec 2003 15:04:51 +0100, Richard Delorme a écrit:
de la famille des exec... Et mettre '.' dans le PATH est un énorme trou de sécurité, un grand classique, en fait...
Pourquoi c'est un trou de securite ?
Exemple de scénario : un malin écrit un script exécutable qu'il appelle ls, qu'il place dans /tmp et qui contient la ligne « rm -r / ». Maintenant l'utilisateur root, qui a mis . dans sont path veux nettoyer /tmp. Il fait : # cd /tmp # ls et surprise !
Ok merci
-- <Mooby> dites comment on fait pour lancer un prg sous NT? on double clique dessus, c'est bien ca ?
- #linuxfr
Le Thu, 18 Dec 2003 15:04:51 +0100, Richard Delorme <abulmo@nospam.fr> a
écrit:
de la famille des exec... Et mettre '.' dans le PATH est un énorme
trou de sécurité, un grand classique, en fait...
Pourquoi c'est un trou de securite ?
Exemple de scénario : un malin écrit un script exécutable qu'il appelle
ls,
qu'il place dans /tmp et qui contient la ligne « rm -r / ». Maintenant
l'utilisateur root, qui a mis . dans sont path veux nettoyer /tmp. Il
fait :
# cd /tmp
# ls
et surprise !
Ok merci
--
<Mooby> dites comment on fait pour lancer un prg sous NT? on double
clique dessus, c'est bien ca ?
Le Thu, 18 Dec 2003 15:04:51 +0100, Richard Delorme a écrit:
de la famille des exec... Et mettre '.' dans le PATH est un énorme trou de sécurité, un grand classique, en fait...
Pourquoi c'est un trou de securite ?
Exemple de scénario : un malin écrit un script exécutable qu'il appelle ls, qu'il place dans /tmp et qui contient la ligne « rm -r / ». Maintenant l'utilisateur root, qui a mis . dans sont path veux nettoyer /tmp. Il fait : # cd /tmp # ls et surprise !
Ok merci
-- <Mooby> dites comment on fait pour lancer un prg sous NT? on double clique dessus, c'est bien ca ?
- #linuxfr
g.patel
On Thu, 18 Dec 2003 15:04:51 +0100, Richard Delorme wrote:
Exemple de scénario : un malin écrit un script exécutable qu'il appelle ls, qu'il place dans /tmp et qui contient la ligne « rm -r / ». Maintenant l'utilisateur root, qui a mis . dans sont path veux nettoyer /tmp. Il fait : # cd /tmp # ls et surprise !
ça n'est vrai que si on a fait export PATH=.:$PATH si on a mis . à la fin, comme avec export PATH=$PATH:. /bin/ls sera exécuté plutot que le cadeau surprise.
Gerard Patel
On Thu, 18 Dec 2003 15:04:51 +0100, Richard Delorme <abulmo@nospam.fr>
wrote:
Exemple de scénario : un malin écrit un script exécutable qu'il appelle ls,
qu'il place dans /tmp et qui contient la ligne « rm -r / ». Maintenant
l'utilisateur root, qui a mis . dans sont path veux nettoyer /tmp. Il
fait :
# cd /tmp
# ls
et surprise !
ça n'est vrai que si on a fait
export PATH=.:$PATH
si on a mis . à la fin, comme avec
export PATH=$PATH:.
/bin/ls sera exécuté plutot que le cadeau surprise.
On Thu, 18 Dec 2003 15:04:51 +0100, Richard Delorme wrote:
Exemple de scénario : un malin écrit un script exécutable qu'il appelle ls, qu'il place dans /tmp et qui contient la ligne « rm -r / ». Maintenant l'utilisateur root, qui a mis . dans sont path veux nettoyer /tmp. Il fait : # cd /tmp # ls et surprise !
ça n'est vrai que si on a fait export PATH=.:$PATH si on a mis . à la fin, comme avec export PATH=$PATH:. /bin/ls sera exécuté plutot que le cadeau surprise.
