2009-09-10 3 views
2

J'essaie d'extraire le paramètre avec lequel une application a été appelée en utilisant les données dans cmdline.analyse proc/pid/cmdline pour obtenir les paramètres de la fonction

Si je commence une instance d'application comme ceci:

monapp 1 2

puis chat le cmdline de monapp je verrai quelque chose comme myapp12.

je devais extraire ces valeurs et moi ce morceau de code pour le faire


pid_t proc_id = getpid(); 

sprintf(buf,"/proc/%i/cmdline",proc_id); 

FILE * pFile; 
pFile = fopen (buf,"r"); 
if (pFile!=NULL) 
{ 
    fread(buf,100,100,pFile); 
    cout << "PID " << proc_id << endl; 
    string str = buf; 
    cout << buf << endl; 
    size_t found=str.find_last_of("/\\"); 
    cout << " file: " << str.substr(found+1) << endl; 

    fclose (pFile); 
} 

Mais ce que je veux est que le nom de l'application et aucun paramètre ...


Mise à jour coppied de réponse:

bien, ma question semble maintenant comment puis-je lire le fichier cmdline sans l'arrêter au premier caractère NULL ...

fopen(cmdline, "rb") 

ne fait rien d'autre si ...

+0

Après avoir combattu cela aujourd'hui, je voulais noter que je devais utiliser: 'fread (buf, 1,100, pFile);' (size = 1, count = longueur du tampon). – opello

Répondre

7

Tous les paramètres de ligne de commande (ce qui apparaîtrait sous la forme du tableau argv[]) sont en fait des chaînes séparées par des valeurs nulles dans /proc/XXX/cmdline.

[email protected]:~> hexdump -C /proc/28460/cmdline 
00000000 70 65 72 6c 00 2d 65 00 31 20 77 68 69 6c 65 20 |perl.-e.1 while | 
00000010 74 72 75 65 00         |true.| 

Cela explique pourquoi, lorsque vous cat « ed cmdline ils étaient tous « coincés » ensemble (cat ignoré les caractères NULL invalides) et pourquoi votre cout arrêté après le premier argument de la ligne de commande (le nom du processus) car il pensait que le nom du processus était une chaîne terminée par un caractère nul et a cessé de chercher plus de caractères à ce moment-là.

Arguments traitement des commandes ligne

Pour traiter les arguments de ligne de commande, vous avez deux options. Si vous voulez juste que la ligne de commande entière comme une chaîne géante, boucle de 0 à (numRead - 2) (où numRead est le nombre de caractères lus) et remplacez tous les octets NULL (curByte == 0) avec des espaces. Ensuite, assurez-vous simplement de définir le dernier caractère à être un octet NULL aussi (au cas où les choses seraient tronquées en raison du tampon de taille fixe).

Si vous souhaitez plutôt un tableau avec tous les arguments, vous devez être plus créatif. Une option serait de boucler de 0 à (numRead - 1) et pourrait tous les octets NULL que vous trouvez. Puis allouer un tableau de char* de cette longueur. Puis bouclez en arrière à travers la ligne de commande, en définissant le début de chaque chaîne (c'est-à-dire le premier octet dans le tableau, plus chaque octet suivant un octet NULL) à des éléments consécutifs du tableau de char*. Sachez que puisque vous lisez dans un tampon de taille fixe, tout ce qui est au-delà de ce tampon sera tronqué.Alors rappelez-vous que quoi que vous fassiez, vous devrez probablement vous assurer manuellement que la fin de la dernière chaîne finit par NULL, sinon la plupart des fonctions de gestion de chaînes ne sauront pas où la chaîne se termine et continueront indéfiniment.

+0

Je l'ai déjà vu;) Le problème avec read ou fread est qu'ils s'arrêtent à la première valeur NULL et n'obtiennent pas le reste des paramètres ... Comment puis-je contourner ce problème? Acclamations –

+1

'read' et' fread' ne s'arrêtent pas, c'est le 'cout' (ou peut-être la construction' chaîne' du tampon, pas sûr) qui s'arrête. Vérifiez la valeur de retour de votre «Fread» et vous verrez ce que je veux dire. –

+0

Adam, je vous remercie de votre aide. Je recevais le syndrome des programmeurs et je voulais détruire la clé d'échappement;). Votre suggestion était sur place. Encore une fois, merci;) –

9

/usr/bin/strings /proc/1337/cmdline habituellement faire le travail pour moi.

Questions connexes