Usando '__progname' en lugar de argv [0]

Question

En el entorno C / Unix en el que trabajo, veo algunos desarrolladores que usan __progname en lugar de argv [0] para mensajes de uso. ¿Hay alguna ventaja en esto? ¿Cuál es la diferencia entre __progname y argv [0] . ¿Es portátil?

Answer 1

__progname no es estándar y, por lo tanto, no es portátil, prefiera argv [0] . Supongo que __progname podría buscar un recurso de cadena para obtener el nombre que no depende del nombre de archivo con el que lo ejecutó. Pero argv [0] le dará el nombre que en realidad lo ejecutó, lo que sería más útil.

Answer 2

El uso de __progname le permite alterar el contenido de la matriz argv [] mientras mantiene el nombre del programa. Algunas de las herramientas comunes como getopt () modifican argv [] a medida que procesan los argumentos.

Para la portabilidad, puede strcopy argv [0] en su propio búfer progname cuando se inicia su programa.

Answer 3

También hay una extensión GNU para esto, de modo que se puede acceder al nombre de invocación del programa desde fuera de main () sin guardarlo manualmente. Sin embargo, podría ser mejor hacerlo manualmente; haciendo que sea portátil en lugar de depender de la extensión GNU. Sin embargo, aquí proporciono un extracto de la documentación disponible.

De el manual de la biblioteca GNU C en línea (accedido hoy):

" Muchos programas que no leen la entrada del terminal están diseñados para salir si falla alguna llamada del sistema. Por convención, el mensaje de error de dicho programa debe comenzar con el nombre del programa, sin directorios. Puede encontrar ese nombre en la variable program_invocation_short_name ; el nombre completo del archivo se almacena en la variable program_invocation_name .

• Variable: char * nombre_invocación_programa El valor de esta variable es el nombre que se utilizó para invocar el programa que se ejecuta en el proceso actual. Es lo mismo que argv [0] . Tenga en cuenta que este no es necesariamente un nombre de archivo útil; a menudo no contiene nombres de directorio.

• Variable: char * program_invocation_short_name El valor de esta variable es el nombre que se utilizó para invocar el programa que se ejecuta en el proceso actual, con los nombres de directorio eliminados. (Es decir, es lo mismo que program_invocation_name menos todo hasta la última barra inclinada, si corresponde)

El código de inicialización de la biblioteca configura estas dos variables antes de llamar a main.

Nota de portabilidad: estas dos variables son extensiones GNU. Si desea que su programa funcione con bibliotecas que no sean GNU, debe guardar el valor de argv [0] en main y luego quitar los nombres del directorio usted mismo. Agregamos estas extensiones para que sea posible escribir subrutinas de informe de errores autónomas que no requieren una cooperación explícita de main. & Quot;

Answer 4

Veo al menos dos problemas potenciales con argv [0].

Primero, argv [0] o argv en sí mismo puede ser NULL si execve () la persona que llamó fue malvada o lo suficientemente descuidada. Llamar a execve (" foobar " ;, NULL, NULL) suele ser una forma fácil y divertida de demostrarle a un programador con mucha confianza que su código no es a prueba de sig11.

También debe tenerse en cuenta que argv no se definirá fuera de main () mientras que __progname se define generalmente como una variable global que puede usar desde su función de uso () o incluso antes de que se llame a main () (como no estándar Constructores de CCG).

Answer 5

Es un BSDism, y definitivamente no es portátil.

Answer 6

__progname es solo argv [0], y los ejemplos en otras respuestas aquí muestran las debilidades de usarlo. Aunque tampoco es portátil, estoy usando readlink en / proc / self / exe (Linux, Android), y leo el contenido de / proc / self / exefile (QNX).

Answer 7

Si su programa se ejecutó utilizando, por ejemplo, un enlace simbólico, argv [0] contendrá el nombre de ese enlace.

Supongo que __progname contendrá el nombre del archivo de programa real.

En cualquier caso, argv [0] está definido por el estándar C. __progname no lo es.