Barrapunto

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.
No es nada legible. Además tiene el problema que señalo por ahí arriba. Te crees que algo que tú consideras un valor lógico lo es realmente y en C no lo es... true puede valer 1, lo comparas con una variable que puede valer -1; las dos son un cierto lógico pero la igualdad no se cumple.

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.
Afecta en que cualquiera que vaya a leer tu código y vea eso le va a costar más entenderlo.
Las macros de preprocesador se suelen poner en mayúsculas para dejar claro que son eso; por ejemplo, porque pueden tener efectos no deseados (el típico ejemplo de #define MAX(a, b) ((a>b)?a:b)).

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?.
Dependiendo del caso no es muy grave. En general, y siempre según mi opinión, sólo se pueden usar para aspectos globales de todo el programa (una configuración que se usa en muchos sitios) o muy aisladas dentro de un módulo en el que por facilidad de programación se usa.
Tú no la usas para parar el programa, sino para que la función haga una cosa o no haga nada. Para eso lo controlas en la llamada: la función tiene sentido en sí misma, sin depender de nada (no está acoplada con nada y mañana la reutilizas); desde el llamante controlas directamente si se ejecuta o no la función, no lo dejas dependiendo de algo que se te escapa. Para salir del programa (aunque en C no las haya) están las excepciones, que son mucho más manejables y estructuradas. Además lo paran desde dentro hacia fuera, no desde fuera hacia dentro (tu función interna se comportaba diferente, no la externa).
Otros usos globales del programa serían para una configuración de un demonio complejo (dejas toda la configuración en un objeto global en el que no se puede escribir) y cada subsistema puede leer de ahí lo que necesite, evitas pasar mil parámetros relativos a la configuración. Listas de recursos accesibles (repositorios CVS en un IDE...), cosas así. Para seguir la lógica del programa, evítalas, porque un problema en una parte A provoca que la parte B no funcione y no ves el error.
El segundo caso no tiene mucho sentido en C. Yo a veces dejaba visibilidad global en las funciones internas de una función (Ada, Pascal... C no permite funciones definidas dentro de funciones). Dentro de que no es una buena práctica, facilita la programación de esa función y su ámbito es reducido, porque no afecta al resto del programa, sólo a subfunciones de una función.
No creo que un entero sea un problema de seguridad, pero sí que es un mal diseño cuando es prescindible. Por ejemplo, el funcionamiento del retorno de códigos de error en las llamadas al sistema (errno, perror y demás) no funciona bien en programación multihilo: una hilo deja un valor global y otro lo modifica antes de que el primero lo procese, por ejemplo.

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:
Yo no lo he visto aquí copiado, se me puede haber escapado, hablaba del primer envío.
La programación que haces me parece farragosa. Cuando programes siempre tienes que reducir las condiciones a su mínima expresión...
comando = getenv(...);
if(comando){ // if(comando != NULL), como quieras
lees el comando (creo que hay que hacer un sscanf) y cuando dupliques comprueba que el resultado no es NULL (que puede serlo si no hay memoria).
haces el exec y demás...
liberas la