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

sspizer 38 Messages postés mercredi 4 juillet 2007Date d'inscription 23 février 2009 Dernière intervention - 5 juil. 2007 à 18:18 - Dernière réponse : sspizer 38 Messages postés mercredi 4 juillet 2007Date d'inscription 23 février 2009 Dernière intervention
- 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
SharpMao 1025 Messages postés mardi 4 février 2003Date d'inscription 7 juin 2010 Dernière intervention - 6 juil. 2007 à 11:37
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)

Merci SharpMao 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 93 internautes ce mois-ci

Commenter la réponse de SharpMao
sspizer 38 Messages postés mercredi 4 juillet 2007Date d'inscription 23 février 2009 Dernière intervention - 5 juil. 2007 à 18:43
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
Lutinore 3248 Messages postés lundi 25 avril 2005Date d'inscription 27 octobre 2012 Dernière intervention - 5 juil. 2007 à 20:48
Commenter la réponse de Lutinore
SharpMao 1025 Messages postés mardi 4 février 2003Date d'inscription 7 juin 2010 Dernière intervention - 6 juil. 2007 à 08:07
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
sspizer 38 Messages postés mercredi 4 juillet 2007Date d'inscription 23 février 2009 Dernière intervention - 6 juil. 2007 à 10:21
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
sspizer 38 Messages postés mercredi 4 juillet 2007Date d'inscription 23 février 2009 Dernière intervention - 6 juil. 2007 à 10:48
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
SharpMao 1025 Messages postés mardi 4 février 2003Date d'inscription 7 juin 2010 Dernière intervention - 6 juil. 2007 à 11:32
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
sspizer 38 Messages postés mercredi 4 juillet 2007Date d'inscription 23 février 2009 Dernière intervention - 6 juil. 2007 à 13:15
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.