Bonjour,
 
J'ai l'erreur suivante :  
 
Program received signal SIGSEGV, Segmentation fault.
0x00000038dff6f640 in strcmp () from /lib64/tls/libc.so.6
(gdb)
 
En debug via ddd c'est sur la ligne suivante que cela plante :
        if ( strcmp(getenv("HOSTTYPE" ),"SunOS" ) == 0 )
 
Alors qu'en fait la variable d'environnement est bien fixée si je fais un echo $HOSTTYPE.
En y regardant de plus près, je remarque que getenv("HOSTTYPE" ) renvoit un pointeur null ...  
 
POURQUOI ???    
JE sens qu'il y a un truc qui m'échappe sur les variables d'environnement ...    
 

Tiré de la manpage de getenv() :
 

 
C'est explicite.
Tu dois en premier lieu vérifier que getenv() ne te retourne pas un pointeur nul, AVANT d'utiliser strcmp().
Sinon évidemment, cette dernière fonction tentera de comparer en lisant les chars à partir de NULL, ça va pas très bien marcher... => segfault.
 
 
Ensuite, pour ta variable d'environnement, elle doit être exportée pour que cela fonctionne. C'est-à-dire qu'elle sera propagée aux sous-shells. Autrement, elle n'existera que dans le shell courant.

 
Merci,
 
Pour ce qui est de la partie C, pas de prob, j'avais compris le PB.  
Par contre tu m'interesses avec ton explication sur l'export de la variable d'environnement ... Mais je comprend pas pourquoi ... Y a-t-il différents types de variables d'environnement ?    
 
Je suis sur le terminal, positionné dans le répertoire où se situe le programme qui plante :
1) Je fais "echo $HOSTTYPE" : j'obtiens une valeur
2) je lance le programme "./toto", et paf le segmentation fault ...
 
Que faut il donc faire entre 1 et 2 ?

Je ne sais pas sur quel shell tu es, je pars du principe que tu es sur ksh :
 

 
(pour faciliter l'identification shell<=>sous shell, j'ai mis un prompt fictif)

 
Cela ne fonctionne pas dans mon cas. J'ai toujours la même erreur ...
 
En fait comme précisé plus haut, "toto" est l'executable dans le répertoire courant : je l'execute dans le même shell et non pas dans un sous shell.
Je ne comprend toujours pas ce qui se passe ...  
Y a-t-il des variables d'environnement auxquelles un programme executable ne peut pas accéder. Si oui dans quel contexte ?  
 
 
 
 
 
 

Apparemment sans rien faire de particulier les variables sont maintenant lues ...
Miss Terre et Boule de Gum
 
Merci pour l'aide en tout cas !  

 
Elmoricq a fait un lapsus en parlant de "sous-shell". Le vrai terme est "processus fils".
En fait, quand tu es dans un shell, tu peux créer des variables qui seront connues dans ton shell
Exemple
couleur=rouge
echo $couleur
 
Mais cette variable "couleur" ne sera pas connue par les processus lancés à partir de ce shell (processus fils). C'est à dire que si, dans "toto.c" tu fais un getenv("couleur" ) et que tu lances "toto", tu obtiendras NULL car la variable "couleur" n'est pas connue du processus fils qui exécute "toto" (quand on exécutes un programme, le shell courant crée un shell fils et c'est le fils qui exécute le pgm pendant que le père attend la fin du pgm => ce mécanisme permet le lancement d'un pgm en background et les pipe en cascade)
 
Pour qu'une variable soit connue dans les fils, il faut l'exporter
export couleur
 
Ce doit être la raison pour laquelle tu peux faire "echo $HOSTTYPE" mais que cette variable n'est pas connue dans "toto".

C'était plutôt un abus de langage lorsque je qualifie le binaire de "sous-shell" dans mon premier post.
(je le laisse tel quel pour la postérité )

Merci les gars.
 
Je crois que j'ai bien compris l'histoire de l'export. C'est d'ailleurs ce que j'ai fait. Cependant je n'ai eu besoin de le faire qu'une seule fois à chaque session. Vu l'explication ci-dessus, je pensais qu'il fallait le faire à chaque fois avant de lancer le programme ???
 
Pouvez-vous me conseiller un bon bouquin pour comprendre le fonctionnement interne et profond du système Linux ainsi que la programmation système ?
 
 

Exporter une variable est valable dans le shell courant, et ce tant que celui-ci n'a pas été quitté.
Tu n'as donc pas à exporter ta variable pour tous les fils que tu lances.
 
Un vrai bon bouquin pour apprendre, déjà, comment fonctionne le korn-shell, c'est de taper :

dans la console.
 
C'est valable pour toutes les commandes, même "man" lui-même.
 
Quant aux bouquins, je n'en connais pas de vraiment bien à te conseiller.

Vi, je me suis mal exprimé. J'aurais dû dire que l'export place la variable dans une zone mémoire qui est automatiquement transmise à tous les fils qui seront générés (et les fils des fils, etc)
 

Les O'REILLY et les RUBY