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 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 "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
