make, ping y nc: códigos de salida que, sin avisar, no comprueban lo que se suele suponer

Qué es

Tres herramientas que un agente invoca con frecuencia desde la shell tienen, cada una, un código de salida cuyo significado es fácil de malinterpretar.

make: "GNU make exits with a status of zero if all makefiles were successfully parsed and no targets that were built failed. A status of one will be returned if the -q flag was used and make determines that a target needs to be rebuilt. A status of two will be returned if any errors were encountered." Fuera de -q, el código 1 no aparece en compilaciones normales: una receta que falla produce el código 2, y el Error 1 del mensaje de make es el código de la receta, no el de make.

ping: "If ping does not receive any reply packets at all it will exit with code 1 ... On other error it exits with code 2. Otherwise it exits with code 0." El código 1 indica que ping funciona correctamente y informa de que no hubo respuesta: un host caído, un descarte por firewall o una dirección incorrecta que aun así se resuelve. El código 2 se reserva para cuando falla el propio ping (argumentos incorrectos, nombre no resoluble, problemas de permisos).

nc/ncat: las implementaciones varían y muchas (incluido el netcat de OpenBSD) no documentan una tabla formal de códigos de salida. Ncat, de Nmap, sí lo hace: "The exit code reflects whether a connection was made and completed successfully. 0 means there was no error. 1 means there was a network error of some kind ... 2 is reserved for all other errors, like an invalid option or a nonexistent file." Los códigos de cualquier otra variante de nc deben considerarse no verificados mientras no se compruebe su propia documentación.

openssl s_client: su opción -verify documenta una trampa real: "Unless the -verify_return_error option is given, the verify operation continues after errors ... As a side effect the connection will never fail due to a server certificate verify failure." Sin esa opción, una sesión TLS completada termina con código 0 incluso con un certificado inválido, caducado o autofirmado.

Por qué importa

Cada caso convierte la comprobación ingenua «0 es correcto, cualquier otro valor es error» en una conclusión equivocada: el modo -q de make invierte el sentido habitual del 1, el código 1 de ping es una observación legítima de la red y no una invocación rota, y el código 0 por defecto de openssl s_client puede significar «conectado a un atacante con un certificado inválido», no «conexión verificada».

Cómo aplicarlo

• Con make -q, trate el código 1 como la señal esperada de «hay que reconstruir» y reserve el tratamiento real de errores para el código 2.
• Use la distinción entre 1 y 2 de ping para separar «host inalcanzable» (1, conviene alertar sobre el destino) de «ha fallado ping» (2, conviene revisar los propios argumentos).
• Prefiera nc -z junto con los códigos documentados de su implementación concreta, o compruebe el texto de la salida; no dé por sentado que la semántica sea la misma en nc de OpenBSD, GNU netcat y Ncat.
• Añada siempre -verify_return_error y -verify_hostname <name> a las llamadas a openssl s_client usadas para comprobar certificados de forma automática: sin la primera, el código 0 no demuestra nada sobre el certificado, y sin la segunda un certificado válido emitido para otro nombre también termina con código 0.

Trampas

• Escribir en un script make -q; [ $? -eq 0 ] || echo "build broken": un código 1 con -q significa lo contrario de «roto».
• Fiarse de un simple openssl s_client ... ; echo $? como comprobación de validez del certificado.