CAPTURE DU TEXTE D'UN PROGRAMME DOS PAR UN PIPE ...
cs_Jack
Messages postés
14006
Date d'inscription
samedi 29 décembre 2001
Statut
Modérateur
Dernière intervention
28 août 2015
-
8 mars 2003 à 02:17
cliquetde8 Messages postés 51 Date d'inscription mercredi 23 février 2011 Statut Membre Dernière intervention 29 avril 2015 - 15 juil. 2013 à 03:49
cliquetde8 Messages postés 51 Date d'inscription mercredi 23 février 2011 Statut Membre Dernière intervention 29 avril 2015 - 15 juil. 2013 à 03:49
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/6395-capture-du-texte-d-un-programme-dos-par-un-pipe
https://codes-sources.commentcamarche.net/source/6395-capture-du-texte-d-un-programme-dos-par-un-pipe
15 juil. 2013 à 03:49
28 oct. 2010 à 11:19
J'ai fait un autre programme qui a les memes symptomes pour que des personnes puissent tester ;)
Prog en C (compilé abvec DMC)
#include <stdlib.h>
#include <stdio.h>
#include <conio.h>
int main(int argc, char* argv[])
{
char c = 0;
while (c != 's')
{
c = _getch();
if (c == 's')
printf("Fin du programme.\n");
else
printf("Asc(c)=%d\n",c, (int)c);
}
return 0;
}
Fait Freezer MyDos.exe (killer le process dans le gestionnair des taches permet de sortir du freez)
Alors qu'un bête hello-world (avec un printf) s'affiche parfaitement dans MyDos.exe (même avec un while(1)printf("Try to catch me !!!");
cela valide la thèse du problème bloquant sur le stdInput mais je ne parviens pas a comprendre comment le corriger ...
28 oct. 2010 à 10:28
C:\Tralala.exe <Commandes.txt
où Commandes.txt contient toutes les lignes envoyées au programme, par exemple, une ligne vide pour un Enter.
Seul bémol : ces commandes doivent être connues d'avances.
28 oct. 2010 à 09:37
je crée un fichier batch "lancement.bat"
il contient:
PAUSE
PAUSE
PAUSE
EXIT
je lance MyDos.exe
je fait lancer un exe -> lancement.bat
le résultat est :
d:\Documents and Settings\ab84785\Bureau\from VBFRANCE>pause
Appuyez sur une touche pour continuer...
d:\Documents and Settings\ab84785\Bureau\from VBFRANCE>pause
Appuyez sur une touche pour continuer...
d:\Documents and Settings\ab84785\Bureau\from VBFRANCE>pause
Appuyez sur une touche pour continuer...
d:\Documents and Settings\ab84785\Bureau\from VBFRANCE>exit
ceci confirme donc le fait que le stdInput reçoit des choses que je ne maitrise pas ...
(et il se trouve que mon exe que à l'origine je souhaite catcher est assez sensible aux entrées)
j'ai tenté de corriger ce problème avec la création d'un nouveau pipe createpipe(hPL, hPE)
avant le createprocess je met le start.stdInput = hPL
apres le createprocess je fait closehandle hPL
et le résultat :
positif = c'est que en effet le premier pause reste bloqué
négatif = ma form est bloquée également ;)
Aurriez vous une idée a ce propos ?
28 oct. 2010 à 08:50
J'ai l'impression qu'il y a un problème du côté du StdInput donné lors du createThread
Etant donné qu'on de spécifie pas le StdInput de la structure, faut-il considérer qu'on définit une StdInput=0 ?
Alors qu'est ce qui passe par ce canal ?
Je me demande si mon programme ne se mange pas des commandes qui le font planter.
Peut-on rediriger spécifiquement ce canal également ?
ps: il est fort probable que je n'ai pas compris l'intérêt du stdIntput...
27 oct. 2010 à 19:40
pour info, je me prends pas mal la tête parsque le dit programme dont je souhaite rediriger les entrées ecrit (printf) des labels (cheksums) de rapport de tests automatiques.
Ces label sont bien sur en hexa (voir en octal) avec une signification renseignées dans un fichier dictionnaire. Mon but est de faire en temps réel une traduction + coloration syntaxique
(ce qui marche fort bien avec comme entrée le texte du presspapier...)
je continue donc de chercher ;)
27 oct. 2010 à 18:53
j'ai remplacé le WM_HIDE par WM_SHOW histoire de voir le CMD.exe
lorsque je dit de ne pas intercepter les canaux (je retire STARTF_USESHOWWINDOW) mon programme s'execute normalement dans la fenetre du CMD.exe
lorsque je remet le STARTF_USESHOWWINDOW, le fenetre CMD.exe est vide. j'en conclu que j'ai bien redirigé le flux sur mon pipe. non ?
maintenant le problème provient du fait que la fonction ReadFile qui est synchrone bloc mon programme (VB6). Et le programme refuse de sortir du ReadFile ...
je suis en trein de regarder si on peut rendre assynchrone la lecture ou spécifier un timeOut...
27 oct. 2010 à 18:21
Il faudrait peut-être regarder si ces pointeurs sont corrects (<> 0) après le CreatePipe
27 oct. 2010 à 18:18
- Soit toutes les données renvoyées à la fin, retourné avec ExecuteCommand
- Soit récupération des données au fur et à mesure de leur arrivée, évènement ReceiveOutputs.
Le ReadFile est commun. Je ne pense pas que l'API puisse bloquer l'exécution du programme. Au pire, elle renvoie un buffer vide ou un hReadPipe/hWritePipe à 0.
Es-tu sous VB6 ?
As-tu modifié la classe ?
Le programme DOS se termine t-il ? et correctement ?
27 oct. 2010 à 16:40
Oui, c'est bien un "executable en mode console"
Je peux le lancer a partir de cmd.exe et il s'affiche dedans
Peut-on utiliser un FileRead non bloquant ? qui renvoie VBnullstring quand rien d'écrit par le programme ? Le freez venant du fait que le fileRead est bloquant...
27 oct. 2010 à 16:31
On est bien d'accord : cette source récupère le texte que peut être renvoyé une application de style console sous DOS.
Alors quand tu dis "J'ai un .exe avec lequel ca ne marche pas", je ne comprends pas trop ce que tu veux dire.
Tu es sous VB6 ?
Si, à la main, tu ouvres une fenêtre DOS et que tu tapes la séquence de commande, vois-tu des infos du programme appelé ressortir dans cette fenêtre ?
27 oct. 2010 à 16:07
J'ai un .exe avec lequel ca ne marche pas. Je cherche désespérément d'ou ca peut venir.
Quand je dit que ca ne marche pas, j'entends que le programme se bloque et que plus rien ne se passe. (freez de l'appli + rien dans la "console")
Pour info, je n'ai pas le droit de donner l'appli (c'est un soft avionnique protégé)
En revenche, je peux dire qu'il dépends d'une dll nommée cygwin1.dll
J'ai désespérément cherche une astuce du genre déscendre la priorité du processus mais je n'ai pas trouvé comment faire...
Une idée d'où peut venir le problème ?
15 juil. 2009 à 18:42
Je ne suis pas alle voir le code de sourceforge mais je signale qu'un exemple complet est fourni depuis fort longtemps dans MSDN (en C bien sur) avec la fonction CreatePipe.
15 juil. 2009 à 10:23
6 janv. 2009 à 19:46
Pour répondre a Angus59 qui attend depuis 2005 une solution pour son xcopy qui n'a pas une sortie standard comme les autres commandes, voici ce j'ai trouvé:
pour visualiser les fichiers qui seront copier
MyDOS.CommandLine = "cmd.exe /C echo.exe | xcopy.exe /EDFL g:\photos c:\photos"
et ensuite enlever l'option FL pour la copie
4 oct. 2008 à 19:20
22 juin 2008 à 14:37
25 janv. 2008 à 17:40
cette application m'a aider enormement
mais en executant ftp.exe sa ce plante
pourquoi?
13 août 2007 à 13:29
J'avais déjà essayer avec le process.standardoutput, mais avec cette méthode, je ne parviens à afficher la sortie standard qu'à la fin de l'exécution de la commande.
La commande que je lance s'exécute pendant environ une minute et il est préférable de voir les messages au fur et à mesure plutot que d'attendre la fin de la commande.
Vois-tu un moyen d'y parvenir ?
10 août 2007 à 15:12
10 août 2007 à 15:10
dommage que si peu de gens aient ce reflex de la parcourir quand une question survient...
http://msdn2.microsoft.com/en-us/library/system.diagnostics.process.standardoutput(vs.80).aspx
et encore, je ne code pas en .Net ^^ Google est décidement mon ami :p
10 août 2007 à 14:42
Cependant je cherche moi aussi à migrer cette source vers vb.net et cela je n'y parvient pas.
est-ce que quelqu'un a déjà rèussi ?
19 mars 2005 à 01:24
Je galere pas mal et j'aurais besoin de votre aide, je suis un debutant confirmé lol.
J'ai pas mal parcouru le forum et les sources afin de trouver la methode du Dos-Pipe
Voila je vous explique j'ai juste créé un form avec un bouton et une textbox qui sert normalement de "Dos Output" auquel j'ai rajouté un module de classe
En precisant MyDOS.CommandLine = "ping 127.0.0.1" ca fonctionne du feu de dieu.
Mais moi ce qui m'interesse c'est une ligne de commande qui fait appel a "XCOPY.exe" ou autre chose
par exemple "xcopy.exe c:\Poub\Scans e:\tempo /s"
Mais rien ne se passe , par contre si je met cette ligne de commande dans un batch et que j'inscris MyDOS.CommandLine = "batch.bat" , le retour dans la fenetre VB me met juste ca : E:\Focal\ProjetV1_VB>xcopy.exe c:\Poub\Scans e:\tempo /s et il ne se passe rien snifff.
Ce que je voudrais c'est que l'action se lance et que je vois ce qui se passe et si possible une interaction de notre part (par ex : Ctrl C ou Y ou N ou T ......) dans la fenetre prevue comme dans une fenetre CMD pure.
Voila je c'est pas si je me fait bien comprendre, mais ca m'aiderais vraiment vous avez la solution
D'avance un grand merci
Michel.
---------------------------------------------------------------------------------------------
'Private MyDOS As DOSClass
Private WithEvents MyDOS As DOSClass
Private Sub CmdQuitter_Click()
Unload Me
End Sub
Private Sub Form_Load()
Set MyDOS = New DOSClass
End Sub
Private Sub Form_Unload(Cancel As Integer)
MyDOS.ClosedCommand
Set MyDOS = Nothing
End Sub
Private Sub MyDOS_ReceiveOutputs(CommandOutputs As String)
TextDos = TextDos & CommandOutputs
End Sub
Private Sub Command1_Click()
'Lancer
TextDos = ""
MyDOS.CommandLine = "xcopy.exe c:\Poub\Scans e:\tempo /s"
MyDOS.ExecuteCommand
End Sub
7 mars 2005 à 15:16
Je cherche desesperement a faire fonctionner ce code sous VB.Net mais pas moyen, apres qque modifs, j arrive enfin a executer le code mais la fonction ReadFile ne retroune rien du process que j'execute.
QQu'un a t il deja essayé de porter ce code en .NET ?
SI oui pouvez vous me montrer comment vous avez fait ?
Merci bcp.
18 nov. 2004 à 19:04
16 nov. 2004 à 10:13
J'ai exposer mon problème là :
http://www.vbfrance.com/forum.v2.aspx?ID=331798&post=ok
Si vous voulez vous joindre à ceux qui tente de m'aider je vous invites de tout coeur.
14 nov. 2004 à 18:34
Je ne pense pas que la réponse soit là!.
Peut être est-ce moi qui est mal interprété ta question.
Moi, je voulais parler de console dos, ce que j'ai déjà réalisé.
De la à envoyer des infos à un programme en cours d'exécution il faut peut être regarder du coté des sendKeys.
En tout cas peut nous faut-il plus d'infos pour comprendre exactement ce que tu cherche à faire.
14 nov. 2004 à 12:54
Vince VG
12 nov. 2004 à 12:03
7 nov. 2004 à 17:33
Je bosse avec en ce moment et je connais ce code à fond.
-1- Comme toujours, il faut laisser le temps aux process externes de s'exécuter : Ajoute un simple DoEvents après le .ExecuteCommand, comme ça l'event de réception peut se déclencher.
-2- Durant l'exécution de la commande, la classe retransmet 256 octets par 256 octets le résultat qu'elle renvoie dans l'évènement "Outputs".
Pour récupérer ces données au fuir et à mesure qu'elle arrivent, il suffit, dans la forme dans laquelle tu déclares la Classe MyDOS, de bien utiliser :
Private WithEvents MyDOS As DOSClass
A partir de là, regarde parmi les objets de ta forme : Sur ta page de code, en haut à gauche, la ComboBox donne la liste, et dans cette liste, tu retrouveras l'objet que tu viens de déclarer (ici MyDOS).
Clique dessus et tu verras que l'evènement "Outputs" apparait et renvoie dans "CommandOutputs" les caractères reçus : Ce code s'exécutera à chaque fois que la classe enverra des données. A toi de les traiter.
C'est la manière la plus rapide de recevoir les données.
-2- Si tu n'as besoin des infos qu'après la fin de l'exécution de ExecuteCommand, utilise cette technique moins lourde à traiter :
Résultat = MyDOS.ExecuteCommand
ça suffit, mais il faut attendre la fin de l'exécution.
Vala.
Jack
7 nov. 2004 à 10:38
en revanche j'ai des problemes avec son utilisation dans une simple boucle => j'observe des problemes de priorités sur les instructions, exemple :
While i < 5
i = i + 1
status.Text = "TEST instruction"
MyDOS.CommandLine = "batch.bat"
MyDOS.ExecuteCommand
Wend
ça a pour effet de ne remplir la TextBox qu'une fois que le batch.bat ait été executé. Un moyen de palier à celà ?
18 oct. 2004 à 00:02
Ceci est réalisable via les apis Windows.
Suivre ce lien
http://www.vbfrance.com/code.aspx?ID=23012
17 oct. 2004 à 17:44
28 sept. 2004 à 16:52
27 sept. 2004 à 18:22
15 sept. 2004 à 14:57
14 sept. 2004 à 01:17
merci et surtout félicitations !
7 sept. 2004 à 17:17
y a pas de prob, c'etait juste pour rappeler qu'on n'oublie pas aussi d'aller voir les explications de l'API dans MSDN qui reste la source fondamentale en ce domaine.
Bonne continuation.
7 sept. 2004 à 17:09
Je m'étais mal exprimé.
J'ai traduit le code VB6 de fredLinx pour le porter sur Windev, comme ce code n'est pas de moi, j'ai pris la délicatesse d'en prévenir ici l'auteur.
[DrCCharly93] co-animateur du site rbesset.net
Merci à vous.
@+
7 sept. 2004 à 00:06
6 sept. 2004 à 23:38
Un petit merci pour cette ressource, et pour signaler que votre source à été portée sur Windev.
Vous trouverez le source sur :
http://sourceforge.net/project/showfiles.php?group_id=84918&package_id=120239
sous le nom de WDDos.
18 juin 2004 à 08:30
Bravo.
25 avril 2004 à 22:59
Et je pense kelle me sera utilise pour bcp de programe a venir :)
Merci et bonne continuation.
25 avril 2004 à 14:48
J'ai juste une petite question... est-il possible d'interargir avec un process executé via ta DosClass ?
Je m'explique... mettons que je lance un nc -l -v -p 1234 avec ta méthode, j'ouvre ainsi le port 1234 de mon ordinateur afin de discuter avec un ami qui s'y connecte sans problème depuis le sien. Je vois tout ce qu'il me dit dans la textbox, mais je n'ai pas moyen de lui répondre :(
Alors grand chef, une solution ? :-D
18 févr. 2004 à 13:56
Est il possible de mettre une barre fleche sur la droite de la fenetre pour pouvoir se balader dans la fenetre une fois l execution termine ???
17 févr. 2004 à 14:27
Chapeau !!!!
30 janv. 2004 à 21:23
Je te mets 11/10... zut ya pas moyen ;-)
Je compte l'utiliser dans un petit prog. de sauvegarde automatique... si j'ai ta permission (je déposerai la source sur vbfrance de toute manière)
V3
11 janv. 2004 à 00:54
si un programme dos n'affiche rien, ÇA VA BOGUER.
12 déc. 2003 à 16:13
Juste une petite remarque, sur des applis dos lentes ou gourmandes ça bloque tout le process, tu pourrais peut être envisager de mettre la conversation en asynchrone voir en multi-threading.
8 oct. 2003 à 10:21
Je vais le tester plus amplement sur différents OS mais ok sous w2k.
18 juil. 2003 à 00:15
21 mai 2003 à 21:49
13 mars 2003 à 23:17
meme peut etre meme a moi :D
je met 10 ca les vaut
13 mars 2003 à 11:41
Ton programme est excellent (10/10)!!!!
10 mars 2003 à 10:52
C'est nettement plus propre, c'est cool !
Merci
(fonctionne très bien sous 2000)
8 mars 2003 à 17:45
Le fruit complet n'est pas encore mur lol lol lol
8 mars 2003 à 15:34
@+
8 mars 2003 à 12:49
En tout cas c'est bien.
:)
8 mars 2003 à 02:17
Superbe. Bien commenté, innovateur.
Très bonne source