¿Es “argv [0] = nombre-del-ejecutable” un estándar aceptado o simplemente una convención común?

Al pasar un argumento a main()en una aplicación C o C ++, ¿ argv[0]siempre será el nombre del ejecutable? ¿O es solo una convención común y no se garantiza que sea cierta el 100% del tiempo?

Las conjeturas (incluso las conjeturas) son divertidas, pero para estar seguro es necesario consultar los documentos de estándares. Por ejemplo, ISO C11 establece (mi énfasis):

Si el valor de argces mayor que cero, la cadena apuntada por argv[0] representa el nombre del programa; argv[0][0]será el carácter nulo si el nombre del programa no está disponible en el entorno del host.

Entonces no, es solo el nombre del programa si ese nombre está disponible. Y "representa" el nombre del programa, no necesariamente es el nombre del programa. La sección anterior dice:

Si el valor de argces mayor que cero, los miembros de la matriz argv[0]hasta argv[argc-1]inclusive contendrán punteros a cadenas, a las que el entorno host da valores definidos por la implementación antes del inicio del programa.

Esto no ha cambiado con respecto a C99, el estándar anterior, y significa que incluso los valores no están dictados por el estándar, depende completamente de la implementación.

Esto significa que el nombre del programa puede estar vacío si el entorno del host no lo proporciona, y cualquier otra cosa si el entorno del host lo proporciona, siempre que "cualquier otra cosa" represente de alguna manera el nombre del programa. En mis momentos más sádicos, consideraría traducirlo al swahili, ejecutarlo a través de un cifrado de sustitución y luego almacenarlo en orden inverso de bytes :-).

Sin embargo, definido por la implementación hace tener un significado específico en las normas ISO - el documento de ejecución obligada cómo funciona. Así que incluso UNIX, que puede poner todo lo que quiera argv[0]con la execfamilia de llamadas, tiene que documentarlo (y lo hace).

En *nixsistemas de tipo con exec*()llamadas, argv[0]será lo que la persona que llama ponga en el argv0lugar de la exec*()llamada.

El shell usa la convención de que este es el nombre del programa, y ​​la mayoría de los otros programas siguen la misma convención, por lo que argv[0]normalmente el nombre del programa.

Pero un programa Unix deshonesto puede llamar exec()y hacer argv[0]lo que quiera, así que no importa lo que diga el estándar C, no puede contar con esto el 100% del tiempo.

Según el estándar C ++, sección 3.6.1:

argv [0] será el puntero al carácter inicial de una NTMBS que representa el nombre utilizado para invocar el programa o ""

Entonces no, no está garantizado, al menos por el Estándar.

ISO-IEC 9899 establece:

5.1.2.2.1 Inicio del programa

Si el valor de argces mayor que cero, la cadena apuntada por argv[0]representa el nombre del programa; argv[0][0]será el carácter nulo si el nombre del programa no está disponible en el entorno del host. Si el valor de argces mayor que uno, las cadenas apuntado por argv[1]medio argv[argc-1]representar los parámetros del programa .

También he usado:

#if defined(_WIN32)
  static size_t getExecutablePathName(char* pathName, size_t pathNameCapacity)
  {
    return GetModuleFileNameA(NULL, pathName, (DWORD)pathNameCapacity);
  }
#elif defined(__linux__) /* elif of: #if defined(_WIN32) */
  #include <unistd.h>
  static size_t getExecutablePathName(char* pathName, size_t pathNameCapacity)
  {
    size_t pathNameSize = readlink("/proc/self/exe", pathName, pathNameCapacity - 1);
    pathName[pathNameSize] = '\0';
    return pathNameSize;
  }
#elif defined(__APPLE__) /* elif of: #elif defined(__linux__) */
  #include <mach-o/dyld.h>
  static size_t getExecutablePathName(char* pathName, size_t pathNameCapacity)
  {
    uint32_t pathNameSize = 0;

    _NSGetExecutablePath(NULL, &pathNameSize);

    if (pathNameSize > pathNameCapacity)
      pathNameSize = pathNameCapacity;

    if (!_NSGetExecutablePath(pathName, &pathNameSize))
    {
      char real[PATH_MAX];

      if (realpath(pathName, real) != NULL)
      {
        pathNameSize = strlen(real);
        strncpy(pathName, real, pathNameSize);
      }

      return pathNameSize;
    }

    return 0;
  }
#else /* else of: #elif defined(__APPLE__) */
  #error provide your own implementation
#endif /* end of: #if defined(_WIN32) */

Y luego solo tiene que analizar la cadena para extraer el nombre del ejecutable de la ruta.

Esta página dice:

El elemento argv [0] normalmente contiene el nombre del programa, pero no se debe confiar en él; de todos modos, ¡es inusual que un programa no sepa su propio nombre!

Sin embargo, otras páginas parecen respaldar el hecho de que siempre es el nombre del ejecutable. Este dice:

Notará que argv [0] es la ruta y el nombre del programa en sí. Esto permite que el programa descubra información sobre sí mismo. También agrega uno más a la matriz de argumentos del programa, por lo que un error común al obtener argumentos de la línea de comandos es tomar argv [0] cuando desee argv [1].

Aplicaciones de tener argv[0] !=nombre ejecutable

• muchos shells determinan si son un shell de inicio de sesión comprobando argv[0][0] == '-'. Los shells de inicio de sesión tienen propiedades diferentes, en particular, que obtienen algunos archivos predeterminados como /etc/profile.

  Por lo general, es el propio init o el gettyque agrega el encabezado -, consulte también: /unix/299408/how-to-login-automatically-without-typing-the-root-username-or-password -in-build / 300152 # 300152

• binarios de múltiples llamadas, quizás más notablemente Busybox . Estos enlaces simbólicos de varios nombres, por ejemplo, /bin/shya /bin/lsun único ejecutable /bin/busybox, que reconoce desde qué herramienta utilizar argv[0].

  Esto hace posible tener un solo ejecutable pequeño vinculado estáticamente que representa múltiples herramientas y funcionará básicamente en cualquier entorno Linux.

Consulte también: /unix/315812/why-does-argv-include-the-program-name/315817

Ejemplo de POSIX ejecutable execvedonde argv[0] !=el nombre del ejecutable

Otros mencionaron exec, pero aquí hay un ejemplo ejecutable.

C.A

#define _XOPEN_SOURCE 700
#include <unistd.h>

int main(void) {
    char *argv[] = {"yada yada", NULL};
    char *envp[] = {NULL};
    execve("b.out", argv, envp);
}

antes de Cristo

#include <stdio.h>

int main(int argc, char **argv) {
    puts(argv[0]);
}

Luego:

gcc a.c -o a.out
gcc b.c -o b.out
./a.out

Da:

yada yada

Sí, argv[0]también podría ser:

• NULL: ¿ Cuándo puede argv [0] tener un valor nulo?
• vacío: ¿Puede argv [0] contener una cadena vacía?

Probado en Ubuntu 16.10.

No estoy seguro de si se trata de una convención casi universal o de un estándar, pero de cualquier forma debería respetarlo. Sin embargo, nunca lo he visto explotado fuera de Unix y sistemas similares a Unix. En entornos Unix, y tal vez particularmente en los viejos tiempos, los programas pueden tener comportamientos significativamente diferentes según el nombre con el que se invocan.

EDITADO: Veo en otras publicaciones al mismo tiempo que la mía que alguien lo ha identificado como proveniente de un estándar en particular, pero estoy seguro de que la convención es anterior al estándar.

Si inicia un programa Amiga con Workbench, argv [0] no se configurará, solo mediante CLI.