Ligne de commande + résultat

Version imprimable

Voir 40 message(s) de cette discussion en une page

02/08/2009, 16h47
mick009

Ligne de commande + résultat

Bonjour,
J'aimerais dans mon programme pouvoir utiliser quelques commandes afin de pouvoir automatiser le travail et éviter l'utilisateur à tout faire.
Par exemple, il faut qu'il télécharge un fichier à partir d'un serveur ftp, qu'il le décompresse, et qu'après avoir travaillé sur ces fichiers, le programme doit les supprimer.

Donc j'avais pensé utiliser les commandes wget et les autres pour faire ces tâches. L'ennui c'est que je ne sais pas comment les faire exécuter dans mon programme...
Je m'explique : pendant le téléchargement, j'aimerais que l'utilisateur puisse voir l'avancée du téléchargement et de même pour la décompression. En console avec system("wget...");, il affiche bien l'avancée de wget, l'ennui c'est que ca reste que de la console...

Si vous connaissez un moyen pour pouvoir contrôler tout ceci en ayant toujours l'avancée des opérations !

Je ne sais pas si je me suis bien exprimé :oops:
Enfin, merci par avance pour votre aide :D !
02/08/2009, 17h58
teuf13

http://library.gnome.org/devel/glib/...ync-with-pipes te permet de récupérer la sortie de ton programme mais est un peu complexe à utiliser. Je te laisse te plonger dans la doc :)
02/08/2009, 18h29
mick009

Une question qui me vient à l'esprit en lisant la documentation :
Quelle est la différence entre les async et async_with_pipes ?

Je pense que dans mon cas, c'est ble et bien l'a-synchronisé et non le sync que je dois choisir...
02/08/2009, 18h40
teuf13

Le async_with_pipes te donne un moyen d'accéder à la sortie standard du programme que tu as lancé, la version async tout court n'a pa ça.
02/08/2009, 18h46
mick009

Je pensais par exemple afficher la progression du téléchargement comme avec Synaptic sur Ubuntu...
L'ennui c'est qu'il faut des renseignements constants sur le travail du processus et pas la sortie finale du processus :aie:
Pas très facile de faire travailler un programme et les commandes liés à l'environnement...

Une autre alternative intéressante pourrait être d'afficher une barre de progression navigant de droite à gauche et de gauche à droite qui tourne en boucle tant que le programme n'a pas fini de télécharger. L'inconvénient c'est que l'utilisateur ne sera pas renseignée :(
02/08/2009, 18h53
teuf13

T'as testé async_with_pipes déjà ?
02/08/2009, 19h05
mick009

Et bien j'ai beau relire le prototype de la fonction, je n'arrive toujours pas à voir où je récupérerai les informations de l'application :?
02/08/2009, 19h23
teuf13

Via les paramètres standard_output/standard_error
02/08/2009, 19h33
mick009

Ah...
Heu, une question un peu bête mais qu'est-ce qu'on peut mettre pour un gint* ??
Le Gint se transformera en 0 pour dire que l'application s'est bien déroulé et 1 s'il y a eu une erreur, non ? Ou alors, c'est que j'ai mal compris :lol: (il y a des chances que ce soit ca en fait :D)
02/08/2009, 19h50
teuf13

If non-NULL, the standard_input, standard_output, standard_error locations will be filled with file descriptors for writing to the child's standard input or reading from its standard output or standard error. The caller of g_spawn_async_with_pipes() must close these file descriptors when they are no longer in use. If these parameters are NULL, the corresponding pipe won't be created.
02/08/2009, 20h30
mick009

Oui, ca je l'avais lu mais je ne comprends pas le "file descriptor" (j'ai pas fait du GTK pendant plus de quatre ans :aie:... Oui je sais c'est pas une escuse :mouarf:).
Mais théoriquement, qu'est-ce qu'on peut mettre avec ces paramètres ? Des gint ? Et même si je reçois un nombre, comment je vais savoir l'état du programme ?

Désolé pour toutes ces questions qui peuvent paraître un peu bête :aie:...
02/08/2009, 21h06
gerald3d

Le gint récupéré correspond à un file descriptor comme l'indique l'extrait de la doc. que t'a donné Teuf. Donc pour faire simple un numéro qui correspond à un fichier.
La sortie console de l'application va se trouver sous forme de fichier si on peut dire. Ce n'est pas tout à fait exacte mais on peut le voir comme ca.

Maintenant quoi en faire?
Il faut les utiliser avec les gio_channel. tu peux connecter le file descriptor de sortie avec la fonction g_io_channel_unix_new(); puis y adjoindre une fonction callback avec la fonction g_io_add_watch();. Ce callback sera appelé à chaque fois que le programme produira une sortie.
Ainsi, s'il affiche par exemple un pourcentage d'avancement des travaux, tu récupèreras cette ligne d'affichage dans le callback. Tu pourras alors mettre à jour ta ProgressBar.
03/08/2009, 10h16
mick009

Très bien merci pour tous ces renseignements !!
Et encore merci d'avoir pris du temps pour me répondre ;)

Alors voila mon code :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
static gboolean read_input(GIOChannel *source, GIOCondition condition, gpointer data)
{
  printf("ma fonction est appele!!\n");
  return FALSE;
}
 
gboolean load_black_lists(GtkProgressBar* progress)
{
  gchar** argv = NULL;
  if (!g_shell_parse_argv("wget ftp://ftp.univ-tlse1.fr/pub/reseau/cache/squidguard_contrib/blacklists.tar.gz", NULL, &argv, NULL))
    return FALSE;
 
  gint std_input, std_output;
  g_spawn_async_with_pipes(NULL, argv, NULL, G_SPAWN_SEARCH_PATH, NULL, NULL, NULL, &std_input, &std_output, NULL, NULL);
 
  GIOChannel* channel_input = g_io_channel_unix_new(std_input);
  GIOChannel* channel_output = g_io_channel_unix_new(std_output);
  g_io_add_watch(channel_input, G_IO_OUT, read_input, NULL);
  g_io_add_watch(channel_output, G_IO_IN | G_IO_HUP | G_IO_ERR | G_IO_NVAL, (GIOFunc) read_input, NULL);
 
  g_strfreev(argv);
  return TRUE;
}

L'ennui c'est que la fonction read_input n'est jamais appelé :(
J'ai trouvé des exemples sur internet et ils diffèrent peu de mon code.
Est-ce que vous voyez quelque chose qui coince ?

Merci par avance pour vos réponses !

03/08/2009, 20h44
gerald3d

Tu as inversé les entrées avec les sorties. Ta fonction read_input(); doit réagir avec les G_IO_IN et vis et versa et recto verso ;)
03/08/2009, 22h36
mick009

Non, même en inversant, et en mettant tous les paramètres, ca ne marche pas :(
03/08/2009, 23h06
gerald3d

As-tu contrôlé le contenu de argv histoire de s'assurer que les données nécessaires sont biens transmises?
03/08/2009, 23h21
mick009

Oui, argv est bon !
Par contre, je viens de voir sur internet que la fonction appelée ne doit pas retourner FALSE sinon elle n'est plus rappelée ;)
03/08/2009, 23h28
mick009

Mais pour être sur d'avoir compris le principe (que j'aborde pour la première fois il faut dire :D), je vais poser une dernière question :
quelle est la différence entre stdin, stdout ?

Un gère ce que produit le programme ! Mais l'autre qu'est-ce que c'est ?
04/08/2009, 13h28
gerald3d

Un programme en console emet sur stdout lorsqu'il a quelque chose à dire. C'est donc ce qui s'affiche à l'écran.
Parfois ce même programme à besoin qu'on lui donne des informations. Il écoute alors stdin.
Pour être complet il existe aussi stderr. Il peut être assimilé dans son fonctionnement à stdout. Cependant il n'affiche que des messages d'erreur.

Voir 40 message(s) de cette discussion en une page