[Confirme] path kde3
Salut, voici mes chemins d'accès aux programmes. [klaus@localhost klaus]$ echo $PATH /opt/kde3/bin:/opt/kde3/bin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin [root@localhost klaus]# echo $PATH /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin Questions: Comment enlever le doublon "/opt/kde3/bin:" ? Comment ajouter "/opt/kde3/bin:" au path de root ? merci Klaus Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? Rendez-vous sur "http://www.mandrakestore.com";
Re: RE : [Confirme] PATH
Pendant qu'on en est dans ces histoires de PATH voulais juste préciser que certes dans le cas d'un cat ou d'un vi il n'est nullement obligatoire de passer le ./ mais que dans d'autre(s) cas ce paramètre se révèle obligatoire ex : [le_sage@jah pppd]$ l auth.c chap.oipv6cp.h Makefile options.c sys-sunos4.c auth.o demand.c ipxcp.c Makefile.linux options.o tdb.c cbcp.c demand.o ipxcp.h Makefile.sol2patchlevel.h tdb.h cbcp.h eui64.c ipxcp.o Makefile.sunos4 pathnames.htdb.o ccp.c eui64.h lcp.c md4.cpluginstty.c ccp.h fsm.c lcp.h md4.hpppd tty.o ccp.o fsm.h lcp.o md4.opppd.8 upap.c chap.c fsm.o magic.c md5.cpppd.h upap.h chap.h ipcp.cmagic.h md5.hppp.pamupap.o chap_ms.c ipcp.hmagic.o md5.osys-linux.cutils.c chap_ms.h ipcp.omain.cmultilink.c sys-linux.outils.o chap_ms.o ipv6cp.c main.omultilink.o sys-solaris.c [le_sage@jah pppd]$ man pppd.8 Il n'y a pas de page de manuel pour pppd.8 [le_sage@jah pppd]$ man ./pppd.8 PPPD(8) PPPD(8) NAME pppd - Point to Point Protocol daemon SYNOPSIS pppd [ tty_name ] [ speed ] [ options ] ... ou bien dexecuter un fichier qui se trouve bien dans le repertoire ou l'on est mais qui n'est pas dans $PATH la aussi le ./ (PAS LE SITE WEB :)) ) est obligatoire voilou -- "Nous sommes tous dans le caniveau, mais certains d'entre nous regardent les etoiles." [ Oscar Wilde ] Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? Rendez-vous sur "http://www.mandrakestore.com";
Re: [Confirme] path
Les cours c'est un peu mon boulot, mais très humblement, je suis content si ça t'as servi à qq chose. à+ Rosaire Merci, Rosaire, tu m'as fait un vrai cours magistral :-) Je connaissais une bonne partie de ce que tu m'as écrit, mais pas tout. J'ai reinitialisé mes chemins en tant qu'utilisateur et tant que root en dur, et ça marche, donc je n'ai plus de problème, grâce à toi. Je vais étudier tes 'TP' quand j'aurai un peu plus de temps, ça n'est pas urgent. Quand j'apprends qc de nouveau comme ça, je le consigne dans un fichier pour le retrouver si besoin est, et après, je peux aussi aider d'autres pingouins perdus ou novices. Donc tu, rien n'est perdu. Je te souhaite un excellent week-end et @+ sur ces ondes Klaus
Re: [Confirme] path
Merci, Rosaire, tu m'as fait un vrai cours magistral :-) Je connaissais une bonne partie de ce que tu m'as écrit, mais pas tout. J'ai reinitialisé mes chemins en tant qu'utilisateur et tant que root en dur, et ça marche, donc je n'ai plus de problème, grâce à toi. Je vais étudier tes 'TP' quand j'aurai un peu plus de temps, ça n'est pas urgent. Quand j'apprends qc de nouveau comme ça, je le consigne dans un fichier pour le retrouver si besoin est, et après, je peux aussi aider d'autres pingouins perdus ou novices. Donc tu, rien n'est perdu. Je te souhaite un excellent week-end et @+ sur ces ondes Klaus Le Samedi 5 Mai 2001 14:42, vous avez écrit : > 1/ Es-tu sur que /etc/rc.sysinit (qui est d'ailleurs un lien vers > /etc/rc.d/rc.sysinit) ne soit pas pris en compte ? Jamais vu ça. A mon > avis, d'ailleurs ce n'est pas le cas. Il DOIT l'être. Tu peux vérifier en y > plaçant l'initialisation d'une variable bidon et vérifier qu'elle a bien > été initialisée. Simple, tu met par exemple qq chose du genre : "export > bidon= taratata" dans ton /etc/rc.sysinit. Au reboot, tu vérifie par "env| > grep bidon" que ta variable a bien été initialisée. A mon avis, elle le > sera. Donc ton rc.sysinit est bien lu. > 2/ En "dur" signifie que tu ignores les initialisations successives > (cumulatives) par les différents scripts d'initialisation et qu'au moment > de ta connexion, tu initialises ton PATH comme ceci : PATH=rép1:rép2:etc... > au lieu de PATH=$PATH:rép_supplémentaire:etc... Dans ce deuxième cas tu > reprends la valeur de la variable PATH et tu lui ajoutes (par > concaténation) la valeur ":rép_supplémentaire:etc..." > 3/Pour mieux piger ce que fait export : > Saches que les process sous Unix sont "reliés" les uns aux autres. Il > existe une notion de "filiation" entre process. On pourrait les représenter > un peu comme un système de fichiers, avec une racine. C'est à dire qu'un > process est toujours lancé par un autre process (sauf init -la "racine", > qui est le premier de tous ces process et qui a comme PID=1, et qui de > plus, est l'ancètre de tous les process du système, puisqu'il lance des > process au démarrage, dont certains lancent d'autres process, etc...). Un > process est identifié par son PID (process ID), ainsi que par son PPID (PID > du père - pour init, PPID=0). Ces process ont également une autre > caractéristique, c'est la possiblité de se transmettre des informations par > l'intermédiare de variables auxquelles ils ont accès dans leur > "environnement"). Un process "sait" qui est son père, par le PPID. Et tu > peux faire le petit TP suivant (suite de commandes ...) : > x=bonjour #tu initialises une variable nommée "x" : > set | more#tu dois voir apparaitre ta variable x > env | more # tu peux chercher : y'a pas de variable x > ps -l # tu vois le PID de ton shell courant > bash# tu lances un sous shell (fils du premier) > ps -l # tu vois le PID de ton shell courant. Son > PPID est le PID de ton premier shell ># (ton shell de connexion) > set |more # pas plus de variable x que de beurre en broche > env |more # idem > ^d #tu quittes ton "sous" shell et reviens au > premier (ton shell de connexion) > set puis env# tu te retouves dans le même état qu'au début > export x > env |more # ta variable x est passée dans l'environnement > bash # tu relances un sous shell > ps -l #on vérifie > env| more #Oh! x est bien là! > x=beuleubeuleu #on change la valeur de x > env|more # le changement est bien répercuté dans > l'environnement ^d# On quitte le shell fils et on > revient au père (ps -l) > env |more#de plus en plus audacieux : on retrouve x au niveau > du père, inchangé. > > Ce dernier point n'est pas anodin : sous Unix, un process ne PEUX PAS > modifier l'environnement du process qui l'a lancé (son process père : ici, > on a modifié l'environnement du fils). Conséquence? lorsque dans un script > on veux changer l'environnement courant du script on ne peut pas le faire à > partir d'un autre script, car par défaut, l'exécution d'un script se fait > toujours en faisant interpréter ce script par un sous shell (fils). Donc si > dans ce script on modifie la valeur de variables d'environnement, elles ne > le seront que pendant la durée d'exécution de ce script et lorsqu'il sera > terminé, on sera revenu au père et on est dans les choux. C'est pour cette > raison que si on veut modifier l'environnement courant au moyen > d'initialisations placées dans un script, il faut lancer ce script > d'initialisations en le lançant par . Nom_script (Nom_script précédé de > point et espace). C'est ce qu'on appelle "sourcer" un script. > Je sais pas si c'est plus clair, mais j'ai fait de m
Re: [Confirme] path
1/ Es-tu sur que /etc/rc.sysinit (qui est d'ailleurs un lien vers /etc/rc.d/rc.sysinit) ne soit pas pris en compte ? Jamais vu ça. A mon avis, d'ailleurs ce n'est pas le cas. Il DOIT l'être. Tu peux vérifier en y plaçant l'initialisation d'une variable bidon et vérifier qu'elle a bien été initialisée. Simple, tu met par exemple qq chose du genre : "export bidon= taratata" dans ton /etc/rc.sysinit. Au reboot, tu vérifie par "env| grep bidon" que ta variable a bien été initialisée. A mon avis, elle le sera. Donc ton rc.sysinit est bien lu. 2/ En "dur" signifie que tu ignores les initialisations successives (cumulatives) par les différents scripts d'initialisation et qu'au moment de ta connexion, tu initialises ton PATH comme ceci : PATH=rép1:rép2:etc... au lieu de PATH=$PATH:rép_supplémentaire:etc... Dans ce deuxième cas tu reprends la valeur de la variable PATH et tu lui ajoutes (par concaténation) la valeur ":rép_supplémentaire:etc..." 3/Pour mieux piger ce que fait export : Saches que les process sous Unix sont "reliés" les uns aux autres. Il existe une notion de "filiation" entre process. On pourrait les représenter un peu comme un système de fichiers, avec une racine. C'est à dire qu'un process est toujours lancé par un autre process (sauf init -la "racine", qui est le premier de tous ces process et qui a comme PID=1, et qui de plus, est l'ancètre de tous les process du système, puisqu'il lance des process au démarrage, dont certains lancent d'autres process, etc...). Un process est identifié par son PID (process ID), ainsi que par son PPID (PID du père - pour init, PPID=0). Ces process ont également une autre caractéristique, c'est la possiblité de se transmettre des informations par l'intermédiare de variables auxquelles ils ont accès dans leur "environnement"). Un process "sait" qui est son père, par le PPID. Et tu peux faire le petit TP suivant (suite de commandes ...) : x=bonjour #tu initialises une variable nommée "x" : set | more#tu dois voir apparaitre ta variable x env | more # tu peux chercher : y'a pas de variable x ps -l # tu vois le PID de ton shell courant bash# tu lances un sous shell (fils du premier) ps -l # tu vois le PID de ton shell courant. Son PPID est le PID de ton premier shell # (ton shell de connexion) set |more # pas plus de variable x que de beurre en broche env |more # idem ^d #tu quittes ton "sous" shell et reviens au premier (ton shell de connexion) set puis env# tu te retouves dans le même état qu'au début export x env |more # ta variable x est passée dans l'environnement bash # tu relances un sous shell ps -l #on vérifie env| more #Oh! x est bien là! x=beuleubeuleu #on change la valeur de x env|more # le changement est bien répercuté dans l'environnement ^d# On quitte le shell fils et on revient au père (ps -l) env |more#de plus en plus audacieux : on retrouve x au niveau du père, inchangé. Ce dernier point n'est pas anodin : sous Unix, un process ne PEUX PAS modifier l'environnement du process qui l'a lancé (son process père : ici, on a modifié l'environnement du fils). Conséquence? lorsque dans un script on veux changer l'environnement courant du script on ne peut pas le faire à partir d'un autre script, car par défaut, l'exécution d'un script se fait toujours en faisant interpréter ce script par un sous shell (fils). Donc si dans ce script on modifie la valeur de variables d'environnement, elles ne le seront que pendant la durée d'exécution de ce script et lorsqu'il sera terminé, on sera revenu au père et on est dans les choux. C'est pour cette raison que si on veut modifier l'environnement courant au moyen d'initialisations placées dans un script, il faut lancer ce script d'initialisations en le lançant par . Nom_script (Nom_script précédé de point et espace). C'est ce qu'on appelle "sourcer" un script. Je sais pas si c'est plus clair, mais j'ai fait de mon mieux. Si avec ça t'as pas pigé "export" dis le moi, j'essaierais de faire plus clair. à+ Rosaire AMORE Klaus a écrit : > merci de tous vos emails à ce sujet. J'ai pas tout pigé, mais finalement, je > n'ai qu'un problème prtaique certainement très simple à résoudre. > > J'ai renommé provisoirement /etc/profile et je trouve: > [klaus@localhost klaus]$ echo $PATH > /bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin > [root@localhost klaus]# echo $PATH > /bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin > > Au fond, le seul problème est que pour root, /sbin et /usr/sbin manquent. > /etc/rc.sysinit contient: > # Set the path > PATH=/bin:/sbin:/usr/bin:/usr/sbin > export PATH > > Pourquoi est-ce que ces lignes ne sont pas pris en compte ? > > Tu peux aussi réinitialiser complètement ton PATH (en "d
[Confirme] path
merci de tous vos emails à ce sujet. J'ai pas tout pigé, mais finalement, je n'ai qu'un problème prtaique certainement très simple à résoudre. J'ai renommé provisoirement /etc/profile et je trouve: [klaus@localhost klaus]$ echo $PATH /bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin [root@localhost klaus]# echo $PATH /bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin Au fond, le seul problème est que pour root, /sbin et /usr/sbin manquent. /etc/rc.sysinit contient: # Set the path PATH=/bin:/sbin:/usr/bin:/usr/sbin export PATH Pourquoi est-ce que ces lignes ne sont pas pris en compte ? Tu peux aussi réinitialiser complètement ton PATH (en "dur") dans ton .bash_profile : export PATH=rép1:rép2:etc que veut dire 'en dur' ? Après export PATH=$PATH:/sbin/:/usr/sbin, /sbin et /usr/sbin sont pris en compte, mais uniquement pour la session bash courante merci Klaus
Réf. : Re: [Confirme] path
export PATH=$(echo $PATH | sed 's+CHEMIN++g' | sed 's/::/:/g' ) devrait
faire l'affaire
pour éliminer "CHEMIN" du PATH.
remarques : 1- sous bash et Korn-shell la notation $(...) remplace la paire
d'accents graves
je la trouve beaucoup plus lisible
-2- le "g" dans la commande sed est là au cas où le
chemin à virer serait présent plus d'une fois
Il faudrait peut-être améliorer le schmilblick pour gérer les cas où CHEMIN
ferait partie d'une autre
composante du PATH
Stephane
<[EMAIL PROTECTED]Pour :
[EMAIL PROTECTED]
paris5.fr> cc :[EMAIL PROTECTED],
[EMAIL PROTECTED]
Envoyé par : Objet : Re: [Confirme]
path
[EMAIL PROTECTED]
02/05/01 14:05
Veuillez répondre à
confirme
> Export n'est pas pour ajouter quoi que ce soit, mais pour que la variable
> définie soit connue ailleurs que dans l'environnement où elle est
déclarée (deux shells distincts par exemple).
>
> Il n'existe pas, à ma connaissance, de moyen de retirer une entrée d'une
variable d'environnement. La seule façon: la modifier (par exemple par des
copier-coller ou dans le fichier où elle est définie) et refaire un export
pour qu'elle soit partout prise en compte.
Si c'est pour modifier ton path, le seul moyen que j'ai trouve est de le
redefinir explicitement, du style : set path=(/usr/bin /usr/local/bin .)
Lea synthaxe peut varier mais le principe est le meme : redefinir la
variable. Sinon, tu peux essayer unset mais je n'y crois pas trop dans
ce cas.
stef
Re: [Confirme] path
> Export n'est pas pour ajouter quoi que ce soit, mais pour que la variable > définie soit connue ailleurs que dans l'environnement où elle est déclarée (deux >shells distincts par exemple). > > Il n'existe pas, à ma connaissance, de moyen de retirer une entrée d'une variable >d'environnement. La seule façon: la modifier (par exemple par des copier-coller ou >dans le fichier où elle est définie) et refaire un export pour qu'elle soit partout >prise en compte. Si c'est pour modifier ton path, le seul moyen que j'ai trouve est de le redefinir explicitement, du style : set path=(/usr/bin /usr/local/bin .) Lea synthaxe peut varier mais le principe est le meme : redefinir la variable. Sinon, tu peux essayer unset mais je n'y crois pas trop dans ce cas. stef
Re: [Confirme] path
1/ Quel valeur de PATH veux-tu virer? 2/ Pour rechercher une chaîne (ex : "PATH") dans un fichier quelconque d'un répertoire (ici, p.ex /home/klaus) tu peux simplement faire un : grep -n 'PATH' /home/klaus/* le -n est pour afficher le n° de ligne dans le fichier où il trouve 3/ Tu peux aussi réinitialiser complètement ton PATH (en "dur") dans ton .bash_profile : export PATH=rép1:rép2:etc à+ R. Klaus a écrit : > Salut Rosaire, > > merci de tes explications. Je vais étudier tout ça plus tard, pour l'instant, > ça me prend la tête et je cherche juste à résoudre mon problème pratique. > J'ai par erreur remplacé /etc/bash.rc de la mdk 8 par le même fichier > sauvegardé de mdk 7.2 et depuis, ça merde. Pourtant j'ai reconstitué le > fichier avec celui de etc/skel (ce répertoire est vide depuis, est-ce que je > me trompe de répertoire ?). > > voici ce que j'ai sur ma linuxette: > [root@localhost /]# echo $PATH > /bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin > [klaus@localhost /]$ echo $PATH > /bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin > > J'ai beau faire par ex: > [root@localhost klaus]# export PATH=$PATH:/usr/sbin, > ça marche, mais seulement lors d'une seule session de bash. > > Pourtant dans /etc/rc.d/rc.sysinit, je trouve: > # Set the path > PATH=/bin:/sbin:/usr/bin:/usr/sbin > export PATH, > > et dans /etc/profile: > # Mandrake-Security : if you remove this comment, remove the next line too. > PATH=$PATH:/usr/X11R6/bin:/usr/games. > > Je cherche en vain dans /root ou /home/klaus un fichier avec PATH. > /root/.bash_profile est presque vide, et je n'ai pas de > /home/klaus/.bash_profile. > Par moment, j'avais des doublons dans mes PATH que je voulais enlever, mais > apparemment, c'était temporaire. J'espère t'avoir donné assez d'éléments pour > m'aider, sinon tu me dis ce qu'il te faut encore comme renseignement. > > merci de ton aide > Klaus
Re: [Confirme] path
Salut
export fait d'une variable (ici PATH), une variable d'environnement. Ce
qui
signifie :
1/ Que l'on peut déclarer et utiliser une variable sans qu'elle ne soit
placée dans l'environnement. On pourrait la considérer comme une
variable
"locale" au shell (ou au process) courant, qui l'a initialisée.
2/ Le fait que cette variable soit transformée en variable
d'environnement
(exportée), fait que tout process fils (ou shell - ex un script est
interprété par un "sous" shell, "fils" du shell courant) aura accès à
cette
variable, telle qu'elle a été définie dans le process "père" (i.e. le
shell
que tu utilises au moment où tu lances ton script ou process).
3/ Le shell ou process fils peut à son tour modifier cette variable
d'environnement, et la transmettre ainsi (modifiée ou non) à ses propres
fils. Le fils ne peut en aucun cas modifier l'environnement du père. Si
tu
veux modifier l'environnement de ton shell courant par des affectations
de
variables placées dans un script, tu dois lancer ton script en le
"sourçant", c'est à dire en le lançant précédé de point-
espace-nom_du_script (". nom_du_script") sous sh (ou bash, ou ksh, etc)
ou
par la commande "source nom_du_script" en csh). Ce qui a pour effet, de
faire interpréter ton script par le shell courant plutôt que par un sous
shell.
4/ Le processus de démarrage (et de connexion d'un utilisateur), est,
entre
autre, une longue suite d'initialisations de variables effectuées par
des
scripts successifs. Ainsi ta variable PATH est initialisée et enrichie
par
plusieurs scripts, et la seule solution pour te débarasser d'une entrée
dans cette variable est de trouver dans quel script de
connexion/démarrage
cette entrée est rajoutée, et ainsi la virer.
5/ Les principaux scripts à consulter : /etc/rc.d/rc.sysinit,
/etc/profile,
Ton_Répertoire_De_Connexion/.bash_profile (si tu utilises bash). Tu
vires
les valeurs attribuées à PATH qui te gênent. Vas y mollo avec les deux
premiers, puisqu'ils concernent tous les utilisateurs du système.
6/ Si tu veux en savoir plus, dis le. Si j'ai été trop long, excuses.
Voili
à+
Rosaire AMORE
Klaus a écrit :
> comment enlever une entrée du path ? On trouve partout 'export...' pour
> ajouter une entrée, mais pas l'inverse.
>
> bye
> Klaus
Re: [Confirme] path
Bonjour, Klaus a écrit : > > comment enlever une entrée du path ? On trouve partout 'export...' pour > ajouter une entrée, mais pas l'inverse. > > bye > Klaus Export n'est pas pour ajouter quoi que ce soit, mais pour que la variable définie soit connue ailleurs que dans l'environnement où elle est déclarée (deux shells distincts par exemple). Il n'existe pas, à ma connaissance, de moyen de retirer une entrée d'une variable d'environnement. La seule façon: la modifier (par exemple par des copier-coller ou dans le fichier où elle est définie) et refaire un export pour qu'elle soit partout prise en compte. Philippe
[Confirme] path
comment enlever une entrée du path ? On trouve partout 'export...' pour ajouter une entrée, mais pas l'inverse. bye Klaus
