Pourquoi devons-nous passer le nom de fichier deux fois dans les fonctions exec?

J'ai lu la programmation avancée dans l'environnement UNIX par Stevens, 8 ^e chapitre. J'ai lu et compris les six fonctions exécutives.

Une chose que je remarque est, dans toutes les fonctions exécutables:

• le premier argument est le nom de fichier / nom de chemin (dépend de la fonction exec).
• le deuxième argument est argv [0] dans lequel nous entrons main(), qui est le nom du fichier lui-même.

Nous devons donc ici passer deux fois le nom du fichier dans la fonction.

Y a-t-il une raison à cela (comme si nous ne pouvons pas obtenir le nom de fichier à partir du nom de chemin du premier argument)?

Nous devons donc ici passer deux fois le nom du fichier dans la fonction.

Ce n'est pas tout à fait la même chose que vous remarquez en observant que l' un d'eux est utilisé comme argv[0]valeur. Cela ne doit pas nécessairement être le même que le nom de base de l'exécutable; beaucoup / la plupart des choses l'ignorent et vous pouvez y mettre tout ce que vous voulez.

Le premier est le chemin réel vers l'exécutable, pour lequel il existe une nécessité évidente. Le second est passé au processus ostensiblement comme le nom utilisé pour l'invoquer, mais, par exemple:

execl("/bin/ls", "banana", "-l", NULL);

Fonctionnera bien, en supposant que /bin/lsc'est le bon chemin.

Cependant, certaines applications utilisent argv[0]. Habituellement, ceux-ci contiennent un ou plusieurs liens symboliques $PATH; ceci est courant avec les utilitaires de compression (ils utilisent parfois des wrappers shell à la place). Si vous avez xzinstallé, stat $(which xzcat)montre que c'est un lien vers xz, et man xzcatest le même que celui man xzqui explique "xzcat est équivalent à xz --decompress --stdout". La façon dont xz peut dire comment il a été invoqué est en vérifiant argv[0], ce qui rend ces équivalents:

execl("/bin/xz", "xzcat", "somefile.xz", NULL);
execl("/bin/xz", "xz", "--decompress", "--stdout", "somefile.xz", NULL);

Vous n'avez pas à transmettre le nom de fichier deux fois.

Le premier est le fichier qui est réellement exécuté.

Le deuxième argument est ce que devrait être le argv[0]processus, c'est-à-dire ce que le processus devrait voir comme son nom. Par exemple, si vous exécutez à lspartir du shell, le premier argument est /bin/ls, le second est juste ls.

Vous pouvez exécuter un certain fichier et l'appeler autrement via le deuxième argument; le programme peut vérifier son nom et se comporter différemment selon le nom. Cela peut également être fait via des liens durs (ou des liens symboliques), mais cela donne plus de flexibilité.

Le point à argv[0]retenir est qu'il peut être réglé sur n'importe quoi (y compris NULL). Par convention , argv[0]sera défini sur le chemin à partir duquel l'exécutable a été démarré (par le processus shell quand il le fait execve()).

Si ./fooet dir/barsont deux liens différents (physiques ou symboliques) vers le même exécutable, le démarrage du programme à partir du shell en utilisant les deux chemins sera défini argv[0]sur ./fooet dir/bar, respectivement.

Le fait que ce argv[0]soit possible NULLest souvent ignoré. Le code suivant peut se bloquer pour un NULL argv[0]par exemple (bien que la glibc imprime quelque chose comme <null> à la place pour argv[0]):

if (argc != 3) {
    fprintf(stderr, "%s: expected 2 arguments\n", argv[0]);
    exit(EXIT_FAILURE);
}

Une alternative sur Linux est d'utiliser /proc/self/exepour de tels cas.