Barrapunto

Supongo que estás en UNIX/Linux. Esto se debe a que cada vez que ejecutas el programa el sistema está lanzando una shell para esa ejecución. Al crear esa shell "hija", hereda el entorno y dispone de la variable. Por eso la primera vez puedes ver el valor. Después tu mismo des-asignas la variable.

Cuando vuelves a asignar la variable en la shell, lo estás haciendo en una distinta de la shell (del entorno) donde se está ejecutando el programa.

No funcionará como tú quieres.
No sólo por lo que han comentado de ser una subshell; Tu programa obtiene el "environment" de un tercer parámetro de la funcion main() que casi nadie usa (char **envp).
Es decir, las variables de entorno no son algo dinámico, sino estático desde el inicio de tu programita.
Utiliza sockets, un fichero FIFO, memoria compartida, signal() ... (busca info sobre ipc -inter program communication-) porque no creo que consigas hacerlo funcionar leyendo el environment.

Suerte.

Yo no me meto en si funcionara o no, pero porque haces esto: if (comando != NULL) { ejecutar = true; } else { ejecutar = false; } if (ejecutar == true) { codigo } en vez de hacer esto otro?? if (comando != NULL) { codigo }

Bueno... tampoco hay que ponerse asi, que la gente no nace aprendida. Unos comentarios:

1. A veces pongo if(TRUE==a) por legibilidad; dependiendo del tipo de 'a' puede serle util al mantenedor de la aplicacion.
2. Ahi tienes razon... a veces. En un desarrollo hecho por el mismo equipo me gusta aplicar la norma de "Lo ya comprobado en una capa superior no se comprueba en una capa inferior" pero en una libreria, o si el codigo de un equipo lo usa otro equipo diferente prefiero comprobarlo todo. Al menos con sentencias ASSERT.
3. Y bueno... lo de poner return puede tener su sentido para no ver el tipico "warning: main does not return nasti de plasti" y no tener que biscar el #pragma warning de turno.
4. Y si... la espera activa es de lo peor que se puede hacer; si no se quiere meter en berenjenales con un Sleep() bien colocado alivia la carga, aunque sigue siendo un tanto chapucero :/
5. Aqui te doy toda la razon... las variables globales -e incluso las variables de clase si se usan como variables globales- son la puerta al infierno.
6. Bueno... la gente tiene que cometer errores para aprender.

Respecto a lo primero lo he comentado en el comentario apropiado, si pongo if(a==true) es para que se pueda leer mejor, pero si me pasas una guia de estilo prometo leerla e intentar aplicarla a partir de ahora.

Tienes razon la comprobación es estupida, pero otra vez ha sido culpa de la evolución de la version 0.0000000000000001 a la 0.0000000000000002

Respecto a lo de las palabras reservadas es para que exista el tipo bool(que en c no existe) y ,corrigeme si me equivoco, no afecta en nada que sea en minusculas.

tercero, el programa en principio pensaba devolver mas cosas, (aparte de 0) pero esperaba primero a ver si funcionaba lo de getenv, sino(como es el caso) debia de replantear la ejecución de los comandos y segun mi opinion no tenia sentido ponerse a devolver cosas que no fueran 0 si aun no funcionaba lo basico.

Cuarto, Respecto a la espera activa te doy toda la razon pero otra vez te remito al paso tercero, primero queria comprobar que funcionase el getenv ,y luego pensaba pasar a optimizar el codigo.

Respecto a la variable desactivar(y quinto), toda la razon, solo una duda: Es tan grave una variable global? que repercusiones tiene?, y una variable global que simplemente sirve para apagar el programa?, permite inyección de codigo un entero?.

Sexta: Respecto a lo de getenv, la version justo siguiente a enviarlo(y que conste que pensaba que lo habia copiado ya aqui) ponia lo siguiente:
char *comando=NULL; //FUERA DEL BUCLE while
//EN EL BUCLE WHILE
  if(getenv("COMANDO")!=NULL)
            {
            if(comando!=NULL)
                free(comando);
            comando =strdup(getenv ("COMANDO"));
            }
        else
            {
            if(comando!=NULL)
                free(comando);
            comando=NULL;
            }

De esa manera la variable comando es una copia de la variable de entorno.

El programa no se cuelga, aunque tienes razon en que tampoco funciona, pero me hacia ilusion ver si se podia cambiar la variable de entorno con un simple export COMANDO="ls" por ejemplo.

Ya por ultimo indicar que la intencion era hacer algo rapido(as is) para satisfacer una pequeña(y estupida) necesidad de programar en sistemas. tambien indicarte que algo de sistemas ya habia programado antes, y que no es mi primera vez, pero si la primera vez que me metia con berengenales de getenv, porque pensaba que lo que hacia era llamar a la variable de entorno en "el momento". Obviamente el resto de codigo era mas bien un envolvente para que no se colgara(o eso intentaba(y conseguia)).

Por otro lado gracias por las indicaciones, he aprendido bastante, aunque como he dicho si me pasas una guia de estilo de c/c++ estaré encantado de leerla, porque eso nadie me lo ha enseñado.

no te habia contestado hasta ahora porque no entendia para que el gdb, puedes explicarte?.

si te refieres a entrar en gdb y modificar el dato dinamicamente, uhm, yo creo que no es lo suyo, el objetivo era algo asi como yo pongo un comando y el pseudodemonio lo cachea.

Otra opcion es (y esto igual es otra aberración) escribir el comando en un fichero y que el programa cada cierto tiempo lo lea y ejecute su contenido.

Que opinais de lo del fichero?