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
