¿Debo mostrar el nombre del programa cuando se produce una advertencia o error?

13

Si estoy escribiendo un script o un programa, ¿debo enviar a stderr su nombre junto con un mensaje de advertencia o error? Por ejemplo:

./script.sh: Warning! Variable "var" lowered down to 10.

o:

./prog.py: Error! No such file: "file.cfg".

Entiendo que, en general, es solo cuestión de gustos (especialmente si escribes tus propias cosas para ti), pero me pregunto si hay algo convencional en eso. Creo que la mayoría de las utilidades de UNIX / Linux escriben sus nombres cuando sucede algo, por lo que parece ser algo bueno, pero ¿existen pautas o reglas tácitas sobre cómo hacerlo y cómo no hacerlo?

Por ejemplo, no es aconsejable instalar binarios debajo /usr/bin/, sino debajo /usr/local/bin/u otra cosa. ¿Existen reglas similares sobre la salida a stderr? ¿Debo escribir el nombre seguido de dos puntos? O simplemente "¡Advertencia!" y "¡Error!" ¿palabras? No pude encontrar nada, pero tal vez alguien podría indicarme dónde leer al respecto.

Esta pregunta es un poco acerca de las prácticas de programación, pero pensé que es más apropiado aquí que en el stackoverflow , ya que se trata de las tradiciones UNIX / Linux y no de la programación en general.

gsarret
fuente
55
El nombre del programa puede ayudar a depurar al azar no such filede quién sabe qué programa en una foo | bar | baztubería.
thrig
@thrig Gracias, buen punto. El mío no se supone que se canalice, pero quién sabe. Supongo que es mejor seguir el comportamiento estándar.
gsarret

Respuestas:

16

Es una práctica común guardar el argumento 0 pasado a un programa en C mainy usarlo como parámetro para perror- para programas simples:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    char *foo = malloc(9999999999L);
    if (foo == 0)
        perror(argv[0]);
    return 0;
}

llame a ese programa "foo", y ejecutarlo ilustra el punto:

> ./foo
./foo: Cannot allocate memory

Los programas complicados pueden agregarse al texto (o usar solo el nombre del archivo sin la ruta), pero mantener el nombre del programa le permite encontrar de dónde proviene un programa que se comporta mal.

No existe un esquema universalmente aceptado para los mensajes de error, pero algunos programas ampliamente utilizados (como gcc) agregan una categoría de mensaje como "Error" o "Advertencia". Aquí hay un ejemplo de uno de mis registros de compilación:

compiling fld_def (obj_s)
../form/fld_def.c: In function '_nc_Copy_Argument':
../form/fld_def.c:164:14: warning: cast discards 'const' qualifier from pointer target type [-Wcast-qual]
        res = (TypeArgument *)argp;
              ^

En este ejemplo, gcc separa los campos con dos puntos y agrega una categoría de "advertencia" después del nombre de archivo, número de línea, número de columna y antes del mensaje real. Pero existen varias variaciones, lo que dificulta que los programas (como vi-like-emacs ) analicen la información.

Para los compiladores, el uso de una categoría en el mensaje simplifica la detección de errores fatales (que pueden no ser fatales de inmediato ) y advertencias. Si su programa sale por un error, no agrega mucho para decir que algunos son realmente advertencias y otros son errores. Pero cuando se comporta de manera diferente (o continúa funcionando más o menos) la categoría ayuda a diagnosticar el problema encontrado.

Thomas Dickey
fuente
Gracias por un ejemplo, entiendo el punto. ¿Qué pasa con "Error" y "Advertencia", ¿saturan la salida?
gsarret
Tu última edición, ¡exactamente en lo que estaba pensando! ¿De qué sirve si sale justo después del mensaje de error? Gracias de nuevo.
gsarret
8

Si se invoca un programa como parte de un script en el que se invocan muchos otros programas, y si no imprime su nombre, a los usuarios les resultará difícil (er) averiguar de dónde proviene el error.

(Si el error es una condición interna inesperada que puede requerir depuración, desea aún más información: no solo el nombre del programa, sino también un archivo de origen y un número de línea y posiblemente una traza inversa).

Kaz
fuente
Gracias. Por lo general, escribo programas para mí (simulación numérica), por lo que solo hay un usuario, sin embargo, podría compartirlos algún día. Tampoco son tan complejos (bueno, al menos todavía), por lo que no hay problema para encontrar la fuente del error, pero gracias por la pista, podría ser útil en el futuro.
gsarret