9
votes

Fonction Linux Exec: Quel est le paramètre Arg0 utilisé?

Voici le prototype de la fonction exécutée: xxx

la page man "dit que le premier argument de arg (c.-à-d. Arg0)" par convention, " pointez sur le nom de fichier associé au fichier étant exécuté. "

Puis j'ai fait ces expériences: xxx

donc la question est que le paramètre arg0 est-il significatif dans toutes les circonstances? Pourquoi l'interface a été conçue comme celle-ci?


2 commentaires

Cela pourrait aider Stackoverflow.com/a/21559499/612920


Fait intéressant, historiquement dans le monde unix, le paramètre Arg0 était souvent celui montré par des outils tels que PS , afin que les gens exécuteraient leurs jeux ou des clients de conversation à l'aide de FIXLP et modifient arg0 pour être Un programme plus approprié (dans l'environnement où ils ne pouvaient renommer ni copier le jeu directement) ...


5 Réponses :


9
votes

La signature de la fonction principale est xxx

où argv [0] est le nom de l'exécutable (arg0 dans votre cas), la demande s'attend donc à sa ligne de commande de SARV [1].

Dans certains cas, un seul binaire peut avoir plusieurs noms (busybox, par exemple, utilise parfois des liens symboliques avec les différents noms, pointant vers le binaire unique). Dans ces cas argv [0] est utilisé pour déterminer quel lien a été utilisé pour appeler le binaire.


0 commentaires

2
votes

Oui, les paramètres sont tous significatifs.

Le premier argument détermine quel exécutable est appelé, le reste déterminer les arguments qui exécutables recevront, y compris ce qu'il pensait qu'il a été appelé comme.

AC programme reçoit tout sauf le premier argument via argc et argv : xxx

qui est particulièrement utile pour les fichiers binaires multi-appels , comme busybox , qui se comporte différemment en fonction de la façon dont ils ont été appelés.


4 commentaires

Gzip et Gunzip sont deux fichiers binaires différents sur mon système. C'est presque sûrement à cause de la philosophie GNU, voyez ma réponse pour plus de détails.


@ user3588161 - sur Oracle Enterprise Linux, gunzip est juste un script que exec gzip. Clairement, ils utilisent argv [0] pour déterminer le comportement.


Eh bien, sur différents systèmes, un ensemble d'utilitaires différents est vraiment identique à utiliser plusieurs noms ...


Sur un système GNU / Debian, GunZip est un script qui exécute "gzip -d". Il n'exige pas GZIP sous un autre argv [0] comme vous prétendez / impliquer. Donc, votre point sur Gzip se comporte différemment en fonction de son argv [0] est invalide ; argv [1] ("-d") est utilisé pour modifier le comportement de GZIP, comme vous pouvez le faire de la ligne de commande. Ceci est en ligne avec la philosophie de GNU sur argv [0] discuté par moi ci-dessous.



6
votes

Les programmes peuvent utiliser argv [0] code> pour se comporter différemment en fonction de la manière dont ils sont appelés. Par exemple, voir cet extrait d'ARGS.C à partir de XZ-Utils:

        const char *name = strrchr(argv[0], '/');
    if (name == NULL)
        name = argv[0];
    else
        ++name;

    // Look for full command names instead of substrings like
    // "un", "cat", and "lz" to reduce possibility of false
    // positives when the programs have been renamed.
    if (strstr(name, "xzcat") != NULL) {
        opt_mode = MODE_DECOMPRESS;
        opt_stdout = true;
    } else if (strstr(name, "unxz") != NULL) {
        opt_mode = MODE_DECOMPRESS;
    } else if (strstr(name, "lzcat") != NULL) {
        opt_format = FORMAT_LZMA;
        opt_mode = MODE_DECOMPRESS;
        opt_stdout = true;
    } else if (strstr(name, "unlzma") != NULL) {
        opt_format = FORMAT_LZMA;
        opt_mode = MODE_DECOMPRESS;
    } else if (strstr(name, "lzma") != NULL) {
        opt_format = FORMAT_LZMA;
    }


0 commentaires

6
votes

Vous pouvez essayer exécutant ("ls", "no_ls", "--Help", 0) pour voir la différence. ls sera alors trompé dans la pensée, il est nod_ls et imprimer quelque chose comme: xxx


0 commentaires

2
votes

Votre dernier appel

#include "ls.h"
int ls_mode = LS_LONG_FORMAT;


0 commentaires