Envoyer des commandes dos et récupérer la réponse [Résolu]

Messages postés
38
Date d'inscription
mercredi 4 juillet 2007
Dernière intervention
23 février 2009
- - Dernière réponse : sspizer
Messages postés
38
Date d'inscription
mercredi 4 juillet 2007
Dernière intervention
23 février 2009
- 6 juil. 2007 à 13:15
Bonjour à tous


Je suis actuellement en train de faire une application qui doit ouvrir
une fenetre dos et envoyer une commande à un logiciel puis récupérer
les données renvoyées.


Voici le code que j'utilise:
<!-- BEGIN TEMPLATE: bbcode_code -->

Code :

 
proc.StartInfo.FileName = "E:\\Semestre6\\ScoopLive\\Encoder\\FFMPEG\\ffmpeg.exe";
proc.StartInfo.Arguments = "-i testAVI.avi";
proc.StartInfo.RedirectStandardOutput = true;
proc.StartInfo.UseShellExecute = false;
 
proc = System.Diagnostics.Process.Start(proc.StartInfo);
 
string str = proc.StandardOutput.ReadToEnd();

return str;
 

<!-- END TEMPLATE: bbcode_code -->

Mon probleme est le suivant:

Lorsque je tape dans une fenêtre dos les commandes qui précèdes la
réponse du logiciel s'affiche dans la fenêtre msdos. Et lorsque je le
lance à partir de mon code le retour est null, j'ai vérifié avec une
autre ligne de commande - L (donne la version du logiciel) et là ma
string contient bien les infos sur le logiciel.

Une dernière précision lorsque j'utilise une autre ligne de commande
qui crée un nouveau fichier à partir d'un présent dans le même dossier
que mon logiciel (ffmpeg) en la lançant sous msdos, ça la crée et quand
je la lance avec mon logiciel ça ne la crée pas et ça ne me retourne
rien.


Alors je me demande est ce que en passant par le code il ne peut pas
trouver le fichier ou autre, je ne sais plus trop ou chercher.
Afficher la suite 

Votre réponse

8 réponses

Meilleure réponse
Messages postés
1025
Date d'inscription
mardi 4 février 2003
Dernière intervention
7 juin 2010
66
3
Merci
Et pour les codes d'erreurs, ils sont peut-être dans le StandardError, et pas dans le
StandardOutput.
Amicalement, SharpMao

"C'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!"
(Coluche / 1944-1986 / Pensées et anecdotes)

Dire « Merci » 3

Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire

Codes Sources 112 internautes nous ont dit merci ce mois-ci

Commenter la réponse de SharpMao
Messages postés
38
Date d'inscription
mercredi 4 juillet 2007
Dernière intervention
23 février 2009
0
Merci
Sinon j'aimerais savoir si il y a une façon plus simple de faire executer
des commandes à un logiciel et de récupérer la réponse de celui-ci sous
windows.
Commenter la réponse de sspizer
Messages postés
3248
Date d'inscription
lundi 25 avril 2005
Dernière intervention
27 octobre 2012
36
Commenter la réponse de Lutinore
Messages postés
1025
Date d'inscription
mardi 4 février 2003
Dernière intervention
7 juin 2010
66
0
Merci
Hello,

Comme tu le dis, je pense qu'il ne trouve pas le fichier.
Si tu ne renseigne pas proc.
StartInfo.
WorkingDirectory, il pense que c'est le même répertoire que celui de ton appli principale.
Alors soit tu donnes ce WorkingDirectory, soit tu donne le chemin complet du fichier dans l'argument :
proc.StartInfo.Arguments = "-i "E:\\Semestre6\\ScoopLive\\Encoder\\FFMPEG\\testAVI.avi""; //Si c'est bien ce chemin.

Amicalement, SharpMao

"C'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!"
(Coluche / 1944-1986 / Pensées et anecdotes)
Commenter la réponse de SharpMao
Messages postés
38
Date d'inscription
mercredi 4 juillet 2007
Dernière intervention
23 février 2009
0
Merci
En fait j'avais déjà lu l'article que Lutinor à mis, j'avais testé ça ne marchait pas plus.
Ensuite SharpMao , j'ai déjà essayé de mettre un WorkingDirectory ça n'a rien changé.
Limite j'ai essayé une commande qui ne demande aucun fichier pour être executé normalement il doit me lancer un code d'erreur quand je tape argument = "-i" du genre: veuillez spécifier au moins un fichier.
 Et je ne reçois pas cette réponse lorsque je passe par mon code C# alors qu'en tapant les commandes par une fenêtre dos, je reçois un retour.
Maintenant quand je fais un argument = "-L" pour avoir les info du logiciel là je reçois étrangement un retour aussi bien en passant par le code C# qu'en passant par la consol dos.
Des idées ?
Commenter la réponse de sspizer
Messages postés
38
Date d'inscription
mercredi 4 juillet 2007
Dernière intervention
23 février 2009
0
Merci
j'ai testé un autre truc pour voir si ça venait du logiciel que j'appelais.
Cette fois pour le test j'appel cmd.exe.
Avec comme argument = "dir". Si je le lance dans une fenetre dos effectivement j'ai un retour.
Si je le lance à partir du C# j'ai
"Microsoft Windows XP [version 5.1.2600]"
"(C) Copyright 1985-2001 Microsoft Corp."
""

et si je continue à lire ligne par ligne mon programme se lance dans une lecture à l'infini sans revenir sur mon point d'arret qui m'affiche ce que vous avez vu précédemment.

Donc imaginons qu'on essaye de passer directement par le dos pour lancer mon logiciel et prendre le retour qui s'affiche dans notre fenêtre dos, même ça je ne pourrais pas le faire.
Commenter la réponse de sspizer
Messages postés
1025
Date d'inscription
mardi 4 février 2003
Dernière intervention
7 juin 2010
66
0
Merci
Le problème vient peut-être d'aiileurs.
Si tu utilise ReadToEnd, le programme reste bloqué tant que le processus lancé n'est pas terminé.

Amicalement, SharpMao

"C'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!"
(Coluche / 1944-1986 / Pensées et anecdotes)
Commenter la réponse de SharpMao
Messages postés
38
Date d'inscription
mercredi 4 juillet 2007
Dernière intervention
23 février 2009
0
Merci
Effectivement, bizaremment l'ensemble des réponses de mon logiciels sont dans le StandardError qu'elles soit des erreurs ou des réponses  de bonnes executions.
En tout cas merci beaucoup SharpMao tu es l'homme de la situation .

Voici un lien pour ceux qui serait interessés par ce type de code:
http://jab.developpez.com/tutoriels/dotnet/process/synchrone/
Commenter la réponse de sspizer

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.