Je cherche à récupérer le nom de l'exe courant. Sur le net, j'ai bien
trouvé
la fonction AfxGetAppName(), mais j'ai toujours la meme erreur que voici :
Attention la norme n'assure rien de tel. Une implémentation normale donnera la ligne de commande qui est tapée dans argv qui ne correspond pas forcément à l'executable
Si il voulait récupérer NomDeLExecutable, ca me semble ne pas être une solution convenable ;)
Il n'y a à ma connaissance aucune solution portable pour résoudre ce problème !
Anthony -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Attention la norme n'assure rien de tel. Une implémentation normale donnera
la ligne de commande qui est tapée dans argv qui ne correspond pas
forcément à l'executable
Si il voulait récupérer NomDeLExecutable, ca me semble ne pas être une
solution convenable ;)
Il n'y a à ma connaissance aucune solution portable pour résoudre ce
problème !
Anthony
--
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about as
relevant as the question of whether submarines can swim.
-- Dijkstra
Attention la norme n'assure rien de tel. Une implémentation normale donnera la ligne de commande qui est tapée dans argv qui ne correspond pas forcément à l'executable
Si il voulait récupérer NomDeLExecutable, ca me semble ne pas être une solution convenable ;)
Il n'y a à ma connaissance aucune solution portable pour résoudre ce problème !
Anthony -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Attention la norme n'assure rien de tel. Une implémentation normale donnera la ligne de commande qui est tapée dans argv qui ne correspond pas forcément à l'executable
Si il voulait récupérer NomDeLExecutable, ca me semble ne pas être une solution convenable ;)
Il n'y a à ma connaissance aucune solution portable pour résoudre ce problème !
Si on veut un nom de programme fixe qui ne puisse pas être simplement changé par l'utilisateur, on peut toujours le coder en dur dans le programme, non ? Par exemple :
#include <stdio.h>
const char *nom_programme = "a.out";
int main(void) { printf("%sn", nom_programme); return 0; }
Si on préfère le nom de la commande, tel que l'a tapé l'utilisateur, argv[0] est sans doute meilleur, sauf dans les cas où il vaut NULL ou une chaine vide, auquel cas le nom du programme n'a sans doute pas de sens, d'ailleurs.
Attention la norme n'assure rien de tel. Une implémentation normale donnera
la ligne de commande qui est tapée dans argv qui ne correspond pas
forcément à l'executable
Si il voulait récupérer NomDeLExecutable, ca me semble ne pas être une
solution convenable ;)
Il n'y a à ma connaissance aucune solution portable pour résoudre ce
problème !
Si on veut un nom de programme fixe qui ne puisse pas être simplement
changé par l'utilisateur, on peut toujours le coder en dur dans le
programme, non ?
Par exemple :
#include <stdio.h>
const char *nom_programme = "a.out";
int main(void) {
printf("%sn", nom_programme);
return 0;
}
Si on préfère le nom de la commande, tel que l'a tapé l'utilisateur,
argv[0] est sans doute meilleur, sauf dans les cas où il vaut NULL ou
une chaine vide, auquel cas le nom du programme n'a sans doute pas de
sens, d'ailleurs.
Attention la norme n'assure rien de tel. Une implémentation normale donnera la ligne de commande qui est tapée dans argv qui ne correspond pas forcément à l'executable
Si il voulait récupérer NomDeLExecutable, ca me semble ne pas être une solution convenable ;)
Il n'y a à ma connaissance aucune solution portable pour résoudre ce problème !
Si on veut un nom de programme fixe qui ne puisse pas être simplement changé par l'utilisateur, on peut toujours le coder en dur dans le programme, non ? Par exemple :
#include <stdio.h>
const char *nom_programme = "a.out";
int main(void) { printf("%sn", nom_programme); return 0; }
Si on préfère le nom de la commande, tel que l'a tapé l'utilisateur, argv[0] est sans doute meilleur, sauf dans les cas où il vaut NULL ou une chaine vide, auquel cas le nom du programme n'a sans doute pas de sens, d'ailleurs.
-- Richard
Anthony Fleury
Richard Delorme wrote:
[...]
Il n'y a à ma connaissance aucune solution portable pour résoudre ce problème !
Si on veut un nom de programme fixe qui ne puisse pas être simplement changé par l'utilisateur, on peut toujours le coder en dur dans le programme, non ? Par exemple :
#include <stdio.h>
const char *nom_programme = "a.out";
int main(void) { printf("%sn", nom_programme); return 0; }
Si on préfère le nom de la commande, tel que l'a tapé l'utilisateur, argv[0] est sans doute meilleur, sauf dans les cas où il vaut NULL ou une chaine vide, auquel cas le nom du programme n'a sans doute pas de sens, d'ailleurs.
En fait ca dépend totalement de ce que veut en faire l'OP, mais c'était pour signaler que l'on avait pas toujours le nom de l'executable tel que nommé par le compilateur ou après lancement de l'installation ou autre. L'exemple (assez idiot je l'avoue :-)) montrait que la réponse n'était pas aussi simple que celle de Philippe, mais j'ai peut être pas été assez explicite.
De plus, il me semble qu'une implémentation renvoyant une chaine vide dans argv[0] pour tout appel de tous les programmes serait conforme, mais je n'ai pas la norme sous la main pour chercher.
Anthony -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Richard Delorme wrote:
[...]
Il n'y a à ma connaissance aucune solution portable pour résoudre ce
problème !
Si on veut un nom de programme fixe qui ne puisse pas être simplement
changé par l'utilisateur, on peut toujours le coder en dur dans le
programme, non ?
Par exemple :
#include <stdio.h>
const char *nom_programme = "a.out";
int main(void) {
printf("%sn", nom_programme);
return 0;
}
Si on préfère le nom de la commande, tel que l'a tapé l'utilisateur,
argv[0] est sans doute meilleur, sauf dans les cas où il vaut NULL ou
une chaine vide, auquel cas le nom du programme n'a sans doute pas de
sens, d'ailleurs.
En fait ca dépend totalement de ce que veut en faire l'OP, mais c'était pour
signaler que l'on avait pas toujours le nom de l'executable tel que nommé
par le compilateur ou après lancement de l'installation ou autre. L'exemple
(assez idiot je l'avoue :-)) montrait que la réponse n'était pas aussi
simple que celle de Philippe, mais j'ai peut être pas été assez explicite.
De plus, il me semble qu'une implémentation renvoyant une chaine vide dans
argv[0] pour tout appel de tous les programmes serait conforme, mais je
n'ai pas la norme sous la main pour chercher.
Anthony
--
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about as
relevant as the question of whether submarines can swim.
-- Dijkstra
Il n'y a à ma connaissance aucune solution portable pour résoudre ce problème !
Si on veut un nom de programme fixe qui ne puisse pas être simplement changé par l'utilisateur, on peut toujours le coder en dur dans le programme, non ? Par exemple :
#include <stdio.h>
const char *nom_programme = "a.out";
int main(void) { printf("%sn", nom_programme); return 0; }
Si on préfère le nom de la commande, tel que l'a tapé l'utilisateur, argv[0] est sans doute meilleur, sauf dans les cas où il vaut NULL ou une chaine vide, auquel cas le nom du programme n'a sans doute pas de sens, d'ailleurs.
En fait ca dépend totalement de ce que veut en faire l'OP, mais c'était pour signaler que l'on avait pas toujours le nom de l'executable tel que nommé par le compilateur ou après lancement de l'installation ou autre. L'exemple (assez idiot je l'avoue :-)) montrait que la réponse n'était pas aussi simple que celle de Philippe, mais j'ai peut être pas été assez explicite.
De plus, il me semble qu'une implémentation renvoyant une chaine vide dans argv[0] pour tout appel de tous les programmes serait conforme, mais je n'ai pas la norme sous la main pour chercher.
Anthony -- Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Dijkstra
Richard Delorme
Si on préfère le nom de la commande, tel que l'a tapé l'utilisateur, argv[0] est sans doute meilleur, sauf dans les cas où il vaut NULL ou une chaine vide, auquel cas le nom du programme n'a sans doute pas de sens, d'ailleurs.
[...]
De plus, il me semble qu'une implémentation renvoyant une chaine vide dans argv[0] pour tout appel de tous les programmes serait conforme, mais je n'ai pas la norme sous la main pour chercher.
Oui, de même qu'une implémentation ou argc vaut toujours 0 et argv[0] NULL. Ce que je voulais dire, c'est qu'un compilateur ne va certainement pas produire un code avec ce comportement de manière gratuite.
-- Richard
Si on préfère le nom de la commande, tel que l'a tapé l'utilisateur,
argv[0] est sans doute meilleur, sauf dans les cas où il vaut NULL ou
une chaine vide, auquel cas le nom du programme n'a sans doute pas de
sens, d'ailleurs.
[...]
De plus, il me semble qu'une implémentation renvoyant une chaine vide dans
argv[0] pour tout appel de tous les programmes serait conforme, mais je
n'ai pas la norme sous la main pour chercher.
Oui, de même qu'une implémentation ou argc vaut toujours 0 et argv[0]
NULL. Ce que je voulais dire, c'est qu'un compilateur ne va certainement
pas produire un code avec ce comportement de manière gratuite.
Si on préfère le nom de la commande, tel que l'a tapé l'utilisateur, argv[0] est sans doute meilleur, sauf dans les cas où il vaut NULL ou une chaine vide, auquel cas le nom du programme n'a sans doute pas de sens, d'ailleurs.
[...]
De plus, il me semble qu'une implémentation renvoyant une chaine vide dans argv[0] pour tout appel de tous les programmes serait conforme, mais je n'ai pas la norme sous la main pour chercher.
Oui, de même qu'une implémentation ou argc vaut toujours 0 et argv[0] NULL. Ce que je voulais dire, c'est qu'un compilateur ne va certainement pas produire un code avec ce comportement de manière gratuite.
-- Richard
Antoine Leca
En , Emmanuel Delahaye va escriure:
Philippe wrote on 15/09/04 :
Tu l'as directement dans les arguments du main :
Pas forcément.
Si. Voir ci-dessous pourquoi.
Ce n'est pas garanti par la norme.
Mais cela vaut le coup d'essayer, c'est quand même BEAUCOUP plus facile que d'essayer de marner avec AfxGetAppName, non?
De plus, même si la norme seule ne _garantit_ rien (de fait, la norme ne garantit pas non plus qu'un programme qui ne soit pas strictement conforme additionne 1 quand tu utilise ++ sur un entier), la norme précise que si argc est supérieur à 0, la chaîne pointée par argv[0] vaut soit la chaîne vide (ce qui indique que le nom du programme n'est pas mis à disposition du programme par l'environnement d'exécution), soit le « nom du programme ».
On peut ergoter sur le fait que la norme ne définit pas que ce « nom du programme » soit effectivement le (ou un) nom du fichier exécutable (démonstration par Richard que certaines implémentations de Linux peuvent renvoyer des équivalents symboliques de ce nom; de plus, la notion même de fichier exécutable est hors du cadre de la norme du langage).
Mais comme celui qui a posé la question a précisé l'implémentation, donc on peut lui répondre en se référant aux documents qui accompagne la dite implémentation (et je rappelle ici que la conformité à la norme C IMPOSE la fourniture de ce document, clause 4. paragraphe 8, autrement dit que le comportement d'un compilateur n'est pas seulement défini par la seule norme mais aussi par le dit document; et jusque là, je ne fais que me conformer à la norme.)
Et il se trouve que dans le cas précis le dit document précise (http://msdn.microsoft.com/library/en-us/vclang/html/_CLANG_Arguments_to_mai n.asp) que « the name of the executable file is placed in argv[0]. »
Paraît pas mal ressembler à ce qu'il cherchait, non ?
Il peut être intéressant (comme l'a fait Richard) de préciser qu'un tel programme n'est pas « strictement conforme » et pas portable partout (ici, il me semble limpide qu'il dépend d'une particularité d'implémentation.)
Antoine
En mn.7d117d49564fc846.15512@YOURBRAnoos.fr, Emmanuel Delahaye va escriure:
Philippe wrote on 15/09/04 :
Tu l'as directement dans les arguments du main :
Pas forcément.
Si. Voir ci-dessous pourquoi.
Ce n'est pas garanti par la norme.
Mais cela vaut le coup d'essayer, c'est quand même BEAUCOUP plus facile que
d'essayer de marner avec AfxGetAppName, non?
De plus, même si la norme seule ne _garantit_ rien (de fait, la norme ne
garantit pas non plus qu'un programme qui ne soit pas strictement conforme
additionne 1 quand tu utilise ++ sur un entier), la norme précise que si
argc est supérieur à 0, la chaîne pointée par argv[0] vaut soit la chaîne
vide (ce qui indique que le nom du programme n'est pas mis à disposition du
programme par l'environnement d'exécution), soit le « nom du programme ».
On peut ergoter sur le fait que la norme ne définit pas que ce « nom du
programme » soit effectivement le (ou un) nom du fichier exécutable
(démonstration par Richard que certaines implémentations de Linux peuvent
renvoyer des équivalents symboliques de ce nom; de plus, la notion même de
fichier exécutable est hors du cadre de la norme du langage).
Mais comme celui qui a posé la question a précisé l'implémentation, donc on
peut lui répondre en se référant aux documents qui accompagne la dite
implémentation (et je rappelle ici que la conformité à la norme C IMPOSE la
fourniture de ce document, clause 4. paragraphe 8, autrement dit que le
comportement d'un compilateur n'est pas seulement défini par la seule norme
mais aussi par le dit document; et jusque là, je ne fais que me conformer à
la norme.)
Et il se trouve que dans le cas précis le dit document précise
(http://msdn.microsoft.com/library/en-us/vclang/html/_CLANG_Arguments_to_mai
n.asp) que « the name of the executable file is placed in argv[0]. »
Paraît pas mal ressembler à ce qu'il cherchait, non ?
Il peut être intéressant (comme l'a fait Richard) de préciser qu'un tel
programme n'est pas « strictement conforme » et pas portable partout (ici,
il me semble limpide qu'il dépend d'une particularité d'implémentation.)
Mais cela vaut le coup d'essayer, c'est quand même BEAUCOUP plus facile que d'essayer de marner avec AfxGetAppName, non?
De plus, même si la norme seule ne _garantit_ rien (de fait, la norme ne garantit pas non plus qu'un programme qui ne soit pas strictement conforme additionne 1 quand tu utilise ++ sur un entier), la norme précise que si argc est supérieur à 0, la chaîne pointée par argv[0] vaut soit la chaîne vide (ce qui indique que le nom du programme n'est pas mis à disposition du programme par l'environnement d'exécution), soit le « nom du programme ».
On peut ergoter sur le fait que la norme ne définit pas que ce « nom du programme » soit effectivement le (ou un) nom du fichier exécutable (démonstration par Richard que certaines implémentations de Linux peuvent renvoyer des équivalents symboliques de ce nom; de plus, la notion même de fichier exécutable est hors du cadre de la norme du langage).
Mais comme celui qui a posé la question a précisé l'implémentation, donc on peut lui répondre en se référant aux documents qui accompagne la dite implémentation (et je rappelle ici que la conformité à la norme C IMPOSE la fourniture de ce document, clause 4. paragraphe 8, autrement dit que le comportement d'un compilateur n'est pas seulement défini par la seule norme mais aussi par le dit document; et jusque là, je ne fais que me conformer à la norme.)
Et il se trouve que dans le cas précis le dit document précise (http://msdn.microsoft.com/library/en-us/vclang/html/_CLANG_Arguments_to_mai n.asp) que « the name of the executable file is placed in argv[0]. »
Paraît pas mal ressembler à ce qu'il cherchait, non ?
Il peut être intéressant (comme l'a fait Richard) de préciser qu'un tel programme n'est pas « strictement conforme » et pas portable partout (ici, il me semble limpide qu'il dépend d'une particularité d'implémentation.)
Antoine
Targeur fou
Rigo wrote:
Bonjour,
Bonjour,
Je cherche à récupérer le nom de l'exe courant. Sur le net, j'ai bien trouvé la fonction AfxGetAppName(), mais j'ai toujours la meme erreur que voici :
J'ai bien mis #include "stdafx.h", mais a priori, ce n'est pas la bonne.
<HS>
<afxwin.h>. Note que les fonctions AfxMachinBidule() sont les fonctions globales des MFC. Ce qui est bizarre, c'est qu'utiliser une telle fonction requiert une compilation C++. A partir du moment ou tu utilises ça, tu ne fais plus de C. Il faut aussi disposer des bonnes options de compilation et d'édition des liens pour le support MFC, et ca dépend beaucoup du type de projet Visual que tu as crée au début (bidouiller par la suite à la main les options de compilation d'un projet initalement non-MFC n'est pas évident).
mais ca fait plante en arrivant sur la fonction, une fois compilé.
pzsDest (brrr, notation hongroise, c'est moche) est-il bien alloué?
Mieux : ... char programPath[MAX_PATH];
/* Par précaution */ programPath[0] = ' '; /* ou memset(programPath, 0, MAX_PATH); inclure <string.h>*/
GetModuleFileName(NULL, programPath, MAX_PATH); /* Encore par précaution */ programPath[MAX_PATH-1] = ' '; ...
GetModuleFileName() renvoie le chemin complet de l'exécutable. Tu dois parser la chaine obtenue pour extraire le nom de l'exécutable (par exemple utiliser le caractère séparateur de chemin windows '' et la fonction standard C strrchr() <string.h>).
J'aimerais donc savoir ce qu'il faut ajouter pour que cela fonctionne, ou si il existe d'autre fonction qui permette d'y arriver.
Voir les autres réponses du fil de discussion, AMA la meilleure solution avec argv[0].
Regis
Rigo wrote:
Bonjour,
Bonjour,
Je cherche à récupérer le nom de l'exe courant. Sur le net, j'ai bien
trouvé
la fonction AfxGetAppName(), mais j'ai toujours la meme erreur que voici :
J'ai bien mis #include "stdafx.h", mais a priori, ce n'est pas la bonne.
<HS>
<afxwin.h>. Note que les fonctions AfxMachinBidule() sont les fonctions
globales des MFC. Ce qui est bizarre, c'est qu'utiliser une telle
fonction requiert une compilation C++. A partir du moment ou tu utilises
ça, tu ne fais plus de C. Il faut aussi disposer des bonnes options de
compilation et d'édition des liens pour le support MFC, et ca dépend
beaucoup du type de projet Visual que tu as crée au début (bidouiller
par la suite à la main les options de compilation d'un projet
initalement non-MFC n'est pas évident).
mais ca fait plante en arrivant sur la fonction, une fois compilé.
pzsDest (brrr, notation hongroise, c'est moche) est-il bien alloué?
Mieux :
...
char programPath[MAX_PATH];
/* Par précaution */
programPath[0] = ' ';
/* ou memset(programPath, 0, MAX_PATH); inclure <string.h>*/
GetModuleFileName(NULL, programPath, MAX_PATH);
/* Encore par précaution */
programPath[MAX_PATH-1] = ' ';
...
GetModuleFileName() renvoie le chemin complet de l'exécutable. Tu dois
parser la chaine obtenue pour extraire le nom de l'exécutable (par
exemple utiliser le caractère séparateur de chemin windows '' et la
fonction standard C strrchr() <string.h>).
J'aimerais donc savoir ce qu'il faut ajouter pour que cela fonctionne, ou
si
il existe d'autre fonction qui permette d'y arriver.
Voir les autres réponses du fil de discussion, AMA la meilleure solution
avec argv[0].
Je cherche à récupérer le nom de l'exe courant. Sur le net, j'ai bien trouvé la fonction AfxGetAppName(), mais j'ai toujours la meme erreur que voici :
J'ai bien mis #include "stdafx.h", mais a priori, ce n'est pas la bonne.
<HS>
<afxwin.h>. Note que les fonctions AfxMachinBidule() sont les fonctions globales des MFC. Ce qui est bizarre, c'est qu'utiliser une telle fonction requiert une compilation C++. A partir du moment ou tu utilises ça, tu ne fais plus de C. Il faut aussi disposer des bonnes options de compilation et d'édition des liens pour le support MFC, et ca dépend beaucoup du type de projet Visual que tu as crée au début (bidouiller par la suite à la main les options de compilation d'un projet initalement non-MFC n'est pas évident).
mais ca fait plante en arrivant sur la fonction, une fois compilé.
pzsDest (brrr, notation hongroise, c'est moche) est-il bien alloué?
Mieux : ... char programPath[MAX_PATH];
/* Par précaution */ programPath[0] = ' '; /* ou memset(programPath, 0, MAX_PATH); inclure <string.h>*/
GetModuleFileName(NULL, programPath, MAX_PATH); /* Encore par précaution */ programPath[MAX_PATH-1] = ' '; ...
GetModuleFileName() renvoie le chemin complet de l'exécutable. Tu dois parser la chaine obtenue pour extraire le nom de l'exécutable (par exemple utiliser le caractère séparateur de chemin windows '' et la fonction standard C strrchr() <string.h>).
J'aimerais donc savoir ce qu'il faut ajouter pour que cela fonctionne, ou si il existe d'autre fonction qui permette d'y arriver.
Voir les autres réponses du fil de discussion, AMA la meilleure solution avec argv[0].
Regis
Antoine Leca
En cid6lr$198$, Targeur fou va escriure:
exemple utiliser le caractère séparateur de chemin windows '' et la
''
Antoine
En cid6lr$198$1@news-reader2.wanadoo.fr, Targeur fou va escriure:
exemple utiliser le caractère séparateur de chemin windows '' et la
|> Attention la norme n'assure rien de tel. Une implémentation normale |> donnera la ligne de commande qui est tapée dans argv qui ne |> correspond pas forcément à l'executable
La norme dit que la chaîne argv[0] doit représenter le nom du programme (« program name »). Sans définir ce qu'elle entend par ça. (La norme C++ démande le nom qui a servi à l'invocation du programme. Ce qui est légèrement plus précis, mais laisse toujours ouvert la question de ce qu'on retrouve lorsque le programme n'a pas été invoqué, mais a été lancé depuis un autre programme.)
Mais en l'occurance, la norme est sans importance ici, parce qu'aucune implémentation, au moins sous Unix ou sous Windows, n'est réelement conforme. (Sous Unix, ce n'est même pas possible.)
En fait, sous Unix, et d'après le peu que j'ai vu, aussi sous Windows, argv[0] contient ce que veut le programme qui t'invoque -- ce que tu vois là est ce que donne bash, mais d'autres shell pourrait en donner autres choses. Si ça a un rapport avec le nom du programme, tant mieux, mais c'est vraiment que tu as eu un coup de bol. (Dans certains cas, Unix guarantit même qu'il serait différent du nom du programme. Essai, par exemple, de démarrer ton programme à travers xterm -ls.)
Une autre question : qu'est-ce que ça veut dire, le « nom du programme ». Aussi sous Unix, laisse tomber le -s dans ta commande ls. Quel est alors le nom du programme ?
|> Si il voulait récupérer NomDeLExecutable, ca me semble ne pas être |> une solution convenable ;)
Typiquement, ce qu'on recherche, c'est le chemain complet, afin de trouver des modules dynamiques qui appartient au programme. Et en effet, c'est impossible.
|> Il n'y a à ma connaissance aucune solution portable pour résoudre ce |> problème !
Sous Unix, en tout cas, il n'y a aucune solution, période.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Anthony Fleury <fleury_anthony@_hotmail.com_> writes:
|> Philippe wrote:
|> [Récupération d'un nom d'executable]
|> > Tu l'as directement dans les arguments du main :
|> Attention la norme n'assure rien de tel. Une implémentation normale
|> donnera la ligne de commande qui est tapée dans argv qui ne
|> correspond pas forcément à l'executable
La norme dit que la chaîne argv[0] doit représenter le nom du programme
(« program name »). Sans définir ce qu'elle entend par ça. (La norme C++
démande le nom qui a servi à l'invocation du programme. Ce qui est
légèrement plus précis, mais laisse toujours ouvert la question de ce
qu'on retrouve lorsque le programme n'a pas été invoqué, mais a été
lancé depuis un autre programme.)
Mais en l'occurance, la norme est sans importance ici, parce qu'aucune
implémentation, au moins sous Unix ou sous Windows, n'est réelement
conforme. (Sous Unix, ce n'est même pas possible.)
En fait, sous Unix, et d'après le peu que j'ai vu, aussi sous Windows,
argv[0] contient ce que veut le programme qui t'invoque -- ce que tu
vois là est ce que donne bash, mais d'autres shell pourrait en donner
autres choses. Si ça a un rapport avec le nom du programme, tant mieux,
mais c'est vraiment que tu as eu un coup de bol. (Dans certains cas,
Unix guarantit même qu'il serait différent du nom du programme. Essai,
par exemple, de démarrer ton programme à travers xterm -ls.)
Une autre question : qu'est-ce que ça veut dire, le « nom du
programme ». Aussi sous Unix, laisse tomber le -s dans ta commande ls.
Quel est alors le nom du programme ?
|> Si il voulait récupérer NomDeLExecutable, ca me semble ne pas être
|> une solution convenable ;)
Typiquement, ce qu'on recherche, c'est le chemain complet, afin de
trouver des modules dynamiques qui appartient au programme. Et en effet,
c'est impossible.
|> Il n'y a à ma connaissance aucune solution portable pour résoudre ce
|> problème !
Sous Unix, en tout cas, il n'y a aucune solution, période.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> Attention la norme n'assure rien de tel. Une implémentation normale |> donnera la ligne de commande qui est tapée dans argv qui ne |> correspond pas forcément à l'executable
La norme dit que la chaîne argv[0] doit représenter le nom du programme (« program name »). Sans définir ce qu'elle entend par ça. (La norme C++ démande le nom qui a servi à l'invocation du programme. Ce qui est légèrement plus précis, mais laisse toujours ouvert la question de ce qu'on retrouve lorsque le programme n'a pas été invoqué, mais a été lancé depuis un autre programme.)
Mais en l'occurance, la norme est sans importance ici, parce qu'aucune implémentation, au moins sous Unix ou sous Windows, n'est réelement conforme. (Sous Unix, ce n'est même pas possible.)
En fait, sous Unix, et d'après le peu que j'ai vu, aussi sous Windows, argv[0] contient ce que veut le programme qui t'invoque -- ce que tu vois là est ce que donne bash, mais d'autres shell pourrait en donner autres choses. Si ça a un rapport avec le nom du programme, tant mieux, mais c'est vraiment que tu as eu un coup de bol. (Dans certains cas, Unix guarantit même qu'il serait différent du nom du programme. Essai, par exemple, de démarrer ton programme à travers xterm -ls.)
Une autre question : qu'est-ce que ça veut dire, le « nom du programme ». Aussi sous Unix, laisse tomber le -s dans ta commande ls. Quel est alors le nom du programme ?
|> Si il voulait récupérer NomDeLExecutable, ca me semble ne pas être |> une solution convenable ;)
Typiquement, ce qu'on recherche, c'est le chemain complet, afin de trouver des modules dynamiques qui appartient au programme. Et en effet, c'est impossible.
|> Il n'y a à ma connaissance aucune solution portable pour résoudre ce |> problème !
Sous Unix, en tout cas, il n'y a aucune solution, période.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
