¿Existe un POSIX, GNU u otra directriz oficial sobre dónde deben imprimirse los informes de progreso y la información de registro (cosas como "Haciendo foo; foo done")? Personalmente, tiendo a escribirlos en stderr para poder redirigir stdout y obtener solo la salida real del programa. Recientemente me dijeron que esta no es una buena práctica ya que los informes de progreso no son en realidad errores y solo los mensajes de error deben imprimirse en stderr.
Ambas posiciones tienen sentido y, por supuesto, puede elegir una u otra dependiendo de los detalles de lo que esté haciendo, pero me gustaría saber si existe un estándar comúnmente aceptado para esto. No he podido encontrar ninguna regla específica en POSIX, los estándares de codificación GNU o cualquier otra lista de mejores prácticas ampliamente aceptada.
Tenemos algunas preguntas similares, pero no abordan este problema exacto:
-
Cuándo usar la redirección a stderr en scripts de shell:la respuesta aceptada sugiere lo que tiendo a hacer, mantener la salida final del programa en stdout y cualquier otra cosa en stderr. Sin embargo, esto solo se presenta como la opinión de un usuario, aunque respaldada por argumentos.
-
¿Debe el mensaje de uso ir a stderr o stdout?:Esto es específico para los mensajes de ayuda, pero cita el estándar de codificación GNU. Este es el tipo de cosas que estoy buscando, solo que no se limitan a los mensajes de ayuda únicamente.
Entonces, ¿existen reglas oficiales sobre dónde deben imprimirse los informes de progreso y otros mensajes informativos (que no forman parte del resultado real del programa)?
Respuesta aceptada:
Posix define los flujos estándar así:
Al inicio del programa, se deben predefinir tres flujos y no es necesario abrirlos explícitamente:entrada estándar (para lectura de entrada convencional), salida estándar (para escribir salida convencional) y error estándar (para escribir la salida de diagnóstico). Cuando se abre, el flujo de error estándar no se almacena completamente en el búfer; los flujos de entrada y salida estándar están completamente almacenados en búfer si y solo si se puede determinar que el flujo no hace referencia a un dispositivo interactivo.
La biblioteca GNU C describe los flujos estándar de manera similar:
Variable:ARCHIVO * salida estándar
El flujo de salida estándar, que se utiliza para la salida normal del programa.
Variable:ARCHIVO * stderr
El flujo de error estándar, que se utiliza para mensajes de error y diagnósticos emitidos por el programa.
Por lo tanto, las definiciones estándar tienen poca orientación para el uso de secuencias más allá de "salida convencional/normal" y "salida de diagnóstico/error". En la práctica, es común redirigir uno o ambos de estos flujos a archivos y canalizaciones, donde los indicadores de progreso serán un problema. Algunos sistemas incluso supervisan stderr para la salida y considéralo un signo de problemas. Por lo tanto, la información de progreso puramente auxiliar es problemática en cualquier flujo.
En lugar de enviar indicadores de progreso incondicionalmente a cualquiera transmisión estándar, es importante reconocer que la salida de progreso solo es apropiada para interactivo arroyos Con eso en mente, recomiendo escribir contadores de progreso solo después de verificar si la transmisión es interactiva (por ejemplo, con isatty() ) o cuando está explícitamente habilitado por una opción de línea de comandos. Esto es especialmente importante para los medidores de progreso que se basan en el comportamiento de actualización del terminal para tener sentido, como las barras de % completado.
Para ciertos mensajes de progreso muy simples ("Comenzando X"... "Terminado con X") es más razonable incluir la salida incluso para flujos no interactivos. En ese caso, considere cómo los usuarios podrían interactuar con las transmisiones, como buscar con grep o paginación con less o monitorear con tail -f . Si tiene sentido ver los mensajes de progreso en esos contextos, serán mucho más fáciles de consumir desde stdout .