Discussion :

[levieuxtoby]

Bonjour !
J'essaie actuellement de lancer une application « terminal » (c.-à-d. qu'elle se lance en théorie dans la console) par une autre application « graphique ». Je ne suis pas sûr de la terminologie exacte, j'espère donc que je me fais bien comprendre.
Pour situer le contexte, le but est de l'application est de donner un moyen graphique à un utilisateur de donner à manger au programme en ligne de commande (pour justement lui éviter cette étape de ligne de commande).
J'ai donc, suite à une recherche web, consulté la doc et trouvé la classe qui semble appropriée : NSTask. J'ai donc tenté de mettre en place l'exécution dudit programme « terminal » avec cette classe comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
NSTask *aTask;
	aTask = [[NSTask alloc] init];
	[aTask setLaunchPath:commande];
 
	NSArray *arguments;
	arguments = [NSArray arrayWithObjects: @"<", @"input", nil];
	[aTask setArguments: arguments];
 
	[aTask launch];

Le fichier input que l'on voit en argument est issu du remplissage effectué par l'utilisateur.
Le problème n'est pas syntaxique, par contre, le programme ne semble pas être lancé ; ou tout du moins n'est-il lancé que pendant un temps très court (un des fichier de sortie du programme « terminal » est produit, mais il est vide).
Certains utilisateurs de forums suggéraient peut-être une utilisation de la commande POSIX system(…) mais il semble que cela pose de sérieux problèmes de sécurité. Je me demande donc si :

• NSTask est bien la classe adaptée ;
• si elle l'est, je l'ai sûrement mal utilisée (mais je ne vois pas où) ;
• si elle ne l'est pas, je ne vois pas de stratégie efficace (je n'ai certes pas énormément d'expérience en Objective-C).

J'appelle donc à l'aide quiconque aurait une solution, un conseil, une piste à mon problème (une fois qu'il sera identifé, ce problème, la suite devrait être plus accessible, je pense).
Merci par avance .

(J'espère que c'est assez clair pour un premier post… Je n'ai d'ailleurs pas trouvé de sujet de « présentation », c'est peut-être pas le genre de la maison…)

[Ceylo]

Euh déjà un petit -[NSTask waitUntilExit] ne ferait sûrement pas de mal . Et ensuite j'ai vu que tu peux balancer des choses à l'entrée standard pendant l'exécution à l'aide de -[NSTask setStandardInput:] et NSPipe.

[levieuxtoby]

Merci
J'avais déjà mis un waitUntilExit, mais je ne l'avais posté…
J'envoie donc mon fichier d'entrée via l'entrée standard comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
NSFileHandle *inputFile = [NSFileHandle fileHandleForReadingAtPath:adresse]];
[aTask setStandardInput:inputFile];

Visiblement, ça s'exécute mais ça foire tout de suite après, on voit apparaître ReportCrash très rapidement dans le moniteur d'activité à chaque fois que y'a une exécution de lancée.
Je vais tâcher de voir d'où ça vient c't'histoire…

Edit:Je complète mon propos et voila le log généré par ReportCrash

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
Process:         mod [1903]
Path:            /programme/bin/mod
Identifier:      mod
Version:         ??? (???)
Code Type:       X86 (Native)
Parent Process:  Lanceur [1885]
 
Date/Time:       2009-07-29 12:40:24.817 +0200
OS Version:      Mac OS X 10.5.7 (9J61)
Report Version:  6
Anonymous UUID:  28619854-C6E0-486F-98B7-CC8B3BCD2CB5
 
Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x000000000000000c
Crashed Thread:  0
 
Thread 0 Crashed:
0   libSystem.B.dylib             	0x916b562d feof + 50
1   mod                           	0x00002429 main + 1803
2   mod                           	0x00001c8a start + 54
 
Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0xa02af584  ebx: 0x916b5609  ecx: 0x0000004e  edx: 0x00000000
  edi: 0x00000000  esi: 0x00000000  ebp: 0xbffff268  esp: 0xbffff240
   ss: 0x0000001f  efl: 0x00010246  eip: 0x916b562d   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0x0000000c
 
Binary Images:
    0x1000 -     0x2fff +mod ??? (???) <d29f3c1ad18f508e6e3ca23f83945531> /programme/bin/mod
0x8fe00000 - 0x8fe2db43  dyld 97.1 (???) <100d362e03410f181a34e04e94189ae5> /usr/lib/dyld
0x91652000 - 0x917b9ff3  libSystem.B.dylib ??? (???) <b47c8e6e45aef620730710a732bf1930> /usr/lib/libSystem.B.dylib
0x92bd0000 - 0x92bd4fff  libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib
0x9406d000 - 0x94074fe9  libgcc_s.1.dylib ??? (???) <f53c808e87d1184c0f9df63aef53ce0b> /usr/lib/libgcc_s.1.dylib
0xffff0000 - 0xffff1780  libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib

Après un peu de recherche, il semble que l'erreur KERN_PROTECTION_FAILURE soit due à un problème de gestion de mémoire, seulement je ne sais pas si le problème vient de l'application que j'essaie de lancer ou de l'application qui la lance.

[Ceylo]

Crash sur la fonction feof() dans le main(). Tu devrais récupérer la sortie standard et faire quelques tests.

[JeitEmgie]

Crash sur la fonction feof() dans le main(). Tu devrais récupérer la sortie standard et faire quelques tests.

le simple fait de voir feof() dans un contexte où est manipulé un NSFileHandle* doit attirer l'attention :

feof() est une fonction de stdio qui reçoit un FILE* comme argument…

n'y-a-t-il donc pas tout simplement un mélange dans les arguments… ?

[levieuxtoby]

En fait il y a deux choses distinctes : un programme en Objective-C et un programme en C. Le premier essaie de lancer le second, et c'est, je pense, le second qui marche pas. Il n'y a pas de feof(…) dans le programme en Obj-C.

En revanche fait intéressant, j'ai changé le while(!feof(fichier)) qui me servait de condition d'arrêt par un compteur (pour tester), et l'erreur reportée n'est plus due au feof (puisqu'il n'y en a plus), mais à un appel de la fonction scanf(…), qui vient plus loin dans le code pour lire les données du fichier.
Je commence à penser que c'est mon pointeur sur le fichier (FILE * fichier) qui coince…