Barrapunto

Primero, como ya te han dicho queda un poco estúpido lo de if(a)algo = true; else algo = false;. Es tan estúpido como los que hacen if(a == true) (cosa que, por cierto, en C es una cagada suprema) en vez de simplemente if(a) (por cierto también haces eso). Si, además, vas a usar tus propias "palabras reservadas" true y false ponlas en mayúsculas, como es norma en los defines. Tu programa funcionará igual (de mal en este caso), pero será bastante más legible.
Segundo. Dentro del switch, en la rama que se supone que ejecuta el programa, haces un if con una comprobación estúpida. Si se ha entrado en el switch es porque ejecutar es cierto, así que comando no es el puntero nulo. De cajón.
Tercero. Declaras la función como que devuelve un entero, lo que parece coherente con una función que ejecuta algo así. Lo que no tiene ningún sentido es que pase lo que pase la función siempre devuelva cero. Para devolver siempre lo mismo... Encima en el programa que la llama comprobarás el código de retorno, como si lo viera.
Cuarto. Espera activa. Tu programa más que una especie de demonio es una putada. Utiliza una señal para notificarle que debe buscar un nuevo comando a ejecutar (aunque no tengas la más remota idea de cómo hacérselo llegar) o crea un canal de comunicaciones (un fifo, un pipe, un socket...) con bloqueo para poder tener un esquema de comunicación síncrona.
Quinto. Variables globales. Sin comentarios. Saca la comprobación de la variable desactivar de esa función y déjala en la que la invoque.
Sexta, y seguramente la más grave. Si no sabes nada de sistemas, para qué coño te pones a hacer programación de sistemas? Si mi memoria no me falla (y me siento perezoso para confirmarlo en google), la llamada getenv devuelve un puntero al entorno. Inmediatamente después destruyes (realmente se destruye o no dependiendo del entorno concreto) la variable, con lo que dejas tu puntero apuntando a una zona que ya tendrá sólo Dios sabe qué. Además, la llamada devuelve (igual no era esta, sino otra de la familia, pero no seré yo quien lo busque ahora) toda la variable de entorno, esto es: "nombre_variable=valor_variable", así que más te vale hacer un sscanf sobre lo que leas del entorno. Cuando un programa se ejecuta, lo hace sobre un entorno, por mucho que tú en una consola, en otra o en el obispado cambies el entorno, el del programa seguirá siendo el que era. Si hay algún modo de cambiarlo dinámicamente, que lo habrá, no es ni trivial (como sí lo es leerlo o cambiar el propio) ni está extendido.
Así que tu programa lo que hace es quedarse con dónde está el entorno, destruirlo, imprimirlo porque no ha dado tiempo a que la memoria se corrompa, intentar volver a buscarlo y (probablemente, habría que ver el resto de programa) quedarse colgado convirtiendo tu pequeño ordenador en un crematorio.
Bienvenido al apasionante mundo de la programación :-)

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.