La syntaxe proposée est strictement équivalente à
De fait, elle ne change rien. Même problème..Code:(void)sprintf(tempo,"del \'%s\'",nom_fichier);
Eric.
Version imprimable
Et encoder le nom de fichier en UTF-8 ?
Puisque:Code:
1
2
3
4
5
6
7 gchar * g_filename_to_utf8 (const gchar *opsysstring, gssize len, gsize *bytes_read, gsize *bytes_written, GError **error);
Citation:
Converts a string which is in the encoding used by GLib for filenames into a UTF-8 string. Note that on Windows GLib uses UTF-8 for filenames; on other platforms, this function indirectly depends on the current locale.
Merci pour votre réponse,
C'est une bonne idée, mais je ne suis pas sûr de savoir comment l'appliquer à mon cas. Ce que j'ai fait, c'est que - dans le code que je donne précédemment - j'ai replacé la fonction suite() par:
Dans lequel je construits cette fois-ci la chaine passée à g_spawn_command_line_async() comme une chaine UTF8. Est-ce ceci l'idée ? Quoi qu'il en soit, je retombe sur le même problème.Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24 void suite(GtkWidget *bouton, GtkWidget *file_selection) { /* suite après que le nom du fichier ait été récupérer */ char tempo[2000]; gchar *sUtf8; GError *error = NULL; gboolean flag; (void)sprintf(tempo,"del \'%s\'",nom_fichier); sUtf8=g_locale_to_utf8(tempo, -1, NULL, NULL, NULL); (void)printf("%s\n",sUtf8); flag=g_spawn_command_line_async(sUtf8, &error); if(!flag) { g_printerr("%s\n", error->message); g_error_free(error); error = NULL; } g_free(sUtf8); gtk_widget_destroy(file_selection); gtk_main_quit(); return; }
Je continues à penser que ce sont les anti-slashs qui posent problème (mais n'en suis pas sûr), et que le problème est donc spécifique de Windows. Mais je n'ai toujours pas d'idée pour le résoudre.
Cordialement, Eric.
À mon avis, tu as une erreur "No such file or directory" parce que "del" n'est pas un binaire mais un mot-clé embarqué (built-in) dans l'interpréteur cmd.exe. Cherche sur ton système del.exe, ça m'étonnerait que tu le trouves. Au lieu de t'emm.... avec ça, utilise plutôt les fonctions de la glib, comme g_file_delete ou g_file_delete_async pour effacer un fichier, parce que de toute façon ce que tu faisais là n'est pas portable d'une plate-forme à une autre.
Merci,
Mais je dois une fois de plus répéter ce que j'ai dit ici plusieurs fois :
L'histoire de détruire un fichier n'est qu'un exemple bidon.
En fait, j'ai besoin de tout ceci pour lancer des applications avec plusieurs arguments, et - notamment pour répondre ici - ces applications ne sont pas des built-in d'autres commandes, mais bien des exécutables. Et j'ai le même problème. Je n'ai évidement pas besoin de toute cette histoire pour détruire un fichier !
Je n'ai toujours pas trouvé de solution..
Eric.
T’inquiète, t'es pas le seul ...Citation:
Mais je dois une fois de plus répéter ce que j'ai dit ici plusieurs fois
edit:
T'as essayé avec un chemin simple et en dur : g_spawn_command_line_sync("c:\simple\path\file.txt", &error) ?
Moi j'essayerai :
Si déjà la ça marche tu peux essayer en mode asynchrone. Sinon essay avec une autre commande (que del) peut être .Code:
1
2
3
4
5
6
7
8
9
10
11 main() { #define TEST(path) if(g_spawn_command_line_sync(path, &output, NULL, NULL, error)) g_print("Success with %s\n", path) else g_print("Failled with %s\n", path); GError *error = NULL; GError *output = NULL; TEST("del C:\\file.txt"); TEST("del \"C:\file.txt\""); TEST("del \"C:\\file.txt\""); TEST("del 'C:\file.txt'"); TEST("del \'C:\\file.txt\'"); }
Je confirme:
Car c'est fait pour être compatible avec Windows même si je n'ai jamais fait de programme gtk sous Windows j'ai assez lue la doc pour le savoir et il faudrait que tu installe la doc en locale, si ce n'est déjà fait.Citation:
Au lieu de t'emm.... avec ça, utilise plutôt les fonctions de la glib
Au lieu de t'emm... avec sprintf utilise plutôt g_sprintf:
Moi j'ai un penchant pour le couple g_strdup(...) et g_strdup_printf(...) pour les strings !Code:
1
2 gint g_sprintf(gchar *string, gchar const *format, ...) ;
Et pense a lire complètement les descriptions de la documentation afin de trouver le problème qu'a Windows avec les path, car la GLIb est censer régler ce genre de problèmes.
Sinon c'est que le problème vient d'ailleurs que de gtk.
Peut-être que tu est la proie d'un malfaisant et que ton système est corrompus sur ce point précis car les Virus ce n'est pas ce qui manque sous Windows.
Et qu'il te nargue jusqu'a que tu perde tes nerfs, une analyse anti-virus ne changera rien je pense.
Car il existe des gens qui n'ont que ça a faire a faire chier les gens, d'ailleurs ils ne mérite pas d'être traiter de pirate mais de: gtk_entry_new(...) (a compléter par vos soins pour soulager vos nerfs).
Si l'on regarde le résultat d'acte de piraterie au final c'est des commères qui font chier les gens.
Merci. Tout d'abord la commande g_spawn_command_line_async() ne fonctionne pas comme ca. Elle a besoin de plus d'arguments. Mais bon :
1) Essayé avec un chemin simple, sans blanc. Pareil.
2) Essayé codé en dur: Pareil.
3) Essayé dans ces deux cas en synchrone et asynchrone. Pareil.
4) Essayé toute ces possibilités. Pareil.
5) Avec d'autres commandes que del, ca marche avec un seul argument (au moins ca !) mais pas avec deux ou plus que deux arguments (et c'est pourtant ce dont j'ai besoin).
J'ai plus d'autres idées..
Eric.
Ce n'est pas l'explication, car (1) ca marche bien avec system() et (2) ca plante aussi si je passe l'argument en dur (voir mon post juste au-dessus).
Non, vraiment, je ne pense pas. Ma bécane est propre et derrière pas mal de protections en tout genre. Ce n'est pas l'explication. On se calme.
Eric.
Dans ce cas donne un exemple réel, que l'on puisse tester. Nous faire lire du code "hypothétique" qui n'est pas celui que tu testes ne sert à rien, puisqu'on peut passer à côté du problème. Donc merci de mettre un programme compilable, avec appelant une vraie commande disponible sur tout système Windows. Si l'erreur renvoyée reste toutefois la même, alors teste avec des chemins absolus pour l'exécutable et pour l'argument. Ton erreur vient peut être du fait que ton exécutable n'est pas dans ton PATH, du coup tu as besoin de l'appeler avec son chemin absolu. Si le soucis persiste, crée un fichier "C:\toto.txt" que tu utiliseras comme argument, comme ça pas de problème d'encodage non plus. N'utilise pas non plus de sprintf, claque à la place une chaine en dur dans chaque appel à g_spawn_command_line_async, ça rend le code plus lisible pour comprendre quelles chaînes tu as testé. Dans tous les cas, indique le message se trouvant dans le GError rempli par l'appel à g_spawn_command_line_async, qu'on sache exactement l'erreur provoquée par chaque test.
Bref, fais des tests unitaires pour cerner ton problème. La GLib embarque un framework de test unitaire pour ça (même si je préfère check, personnellement).
Ok,
Cependant, dans toutes les discussions ci-dessus, comme je l'ai expliqué :
1) Le programme que j'ai mis dans cette discussion est compilable.
2) Depuis le début je suis - évidement - sur des chemins absolus. D'ailleurs, je le rappelle, les noms des fichiers proviennent de gtk_file_selection et ils viennent donc en absolu.
3) Mon exécutable se lance bien sans argument. Pas de problème de PATH. C'est le rajout d'arguments qui pose apparement problème.
4) J'ai déjà fait le test avec des chemins simples du type "C:\toto.txt" (voir mon post d'aujourd'hui).
5) J'ai également testé sans sprintf en utilisant une chaine en dur (voir mon post d'aujourd'hui).
6) Le message d’erreur dans le GError est continuellement "l'exécution du processus file a échoué (No such file or directory)".
Tout ceci a été expliqué plusieurs fois ici.
Je peux essayer de vous mettre l'exemple réel, mais il fait appel à des exécutables présents que sur ma machine (calcul scientifique). Même si le code restera compilable, il ne pourra pas être testé de votre côté et renverra les mêmes problèmes qu'avec l'exemple de del. Je vais tacher de faire un autre exemple pour lancer MSWord avec un fichier doc, ce qui revient au même. Je vous tiens au courant.
Cordialement, Eric.
Sors de la problématique GTK. Pas besoin de GTK pour tester g_spawn_command_line_async, GTK ne fait que te fournir le nom du fichier. Vérifie que tu arrives toi même déjà à lancer une commande quelconque avec arguments.
Mets tes commandes à tester dans le tableau "commands" ci-dessous, compile et lance ce programme de test, et copie-colle le résultat qui s'affiche à l'écran stp.
Code:
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 #include <glib.h> #include <unistd.h> int main (int argc, char *argv[]) { int i; const char * commands[] = { /* ajoute les commandes a tester ici */ "echo toto", "ls /", "date", }; for (i = 0; i < G_N_ELEMENTS(commands); i++) { GError *error = NULL; const char *cmd = commands[i]; g_printf ("Testing: %s\n", cmd); if (! g_spawn_command_line_async (cmd, &error)) { g_printf("Error: %s\n", error->message); g_clear_error(&error); } sleep(1); } return 0; }
Merci encore pour votre disponibilité.
Inutile que je rajoute mes propres commandes dans cet exemple, ni même que j'essaye avec des arguments.. Si je le lance tel quel (sans le sleep() que ne compile pas sous windows, et en remplacant le "ls /" par "dir"), j'obtiends :
Et ces trois commandes fonctionnent parfaitement bien si je les lance à la main dans une fenetre dos.Citation:
Testing: echo toto
Error: L'ex├®cution du processus fils a ├®chou├® (No such file or directory)
Testing: dir
Error: L'ex├®cution du processus fils a ├®chou├® (No such file or directory)
Testing: date
Error: L'ex├®cution du processus fils a ├®chou├® (No such file or directory)
Process returned 0 (0x0) execution time : 0.120 s
Sans bavure, et pas besoin effectivement de GTK..
Mais c'est quoi le problème??
Eric.
Les commandes que j'ai mises sont pour la décoration... C'est ce que j'ai utilisé pour tester sous Linux. Il faut que tu testes avec des vrais noms de binaires, et des chemins absolus.
Bon, j'avance.
J'ai créé un binaire perso, qui est issu de la compilation du code C suivant, et qui est - chez moi - dans "D\Tempo\tempo 2\testing2.exe" :
Si je lance g_spawn_command_line_async (cmd, &error)) avecCode:
1
2
3
4
5
6
7
8
9
10
11 #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { int i; (void)printf("%d argument(s)\n",argc); for (i=0;i<argc;i++) (void)printf("%d %s\n",i,argv[i]); return 0; }
J'obtiens bienCode:const char * commands[] = {"\"D:\\Tempo\\tempo 2\\testing2.exe\" \"faire un test\""};
Et si je lance je lance g_spawn_command_line_async (cmd, &error)) cette fois-ci avecCitation:
2 argument(s)
0 D:\Tempo\tempo 2\testing2.exe
1 faire un test
J'obtiens bienCode:const char * commands[] = {"\"D:\\Tempo\\tempo 2\\testing2.exe\" faire un test"};
C'est le comportement normal. Il faut bien mettre des doubles anti-slash, et rajouter des guillemets où il convient, sans quoi ça ne marche pas.Citation:
4 argument(s)
0 D:\Tempo\tempo 2\testing2.exe
1 faire
2 un
3 test
Bon.
Je retourne à mon code originel et tâche de voir pourquoi je bataille depuis des jours avec ce truc.
Merci en tout cas - et encore - pour votre disponibilité.
Je vous tiens au courant.
Eric.
Et plutôt que d'appeler un word, fais ton propre exécutable que tu pourras appeler.
Voilà par exemple un programme sans dépendance à la GLib ni GTK qui devrait pouvoir s'exécuter de partout.
compile le, et nomme l'exécutable résultant print-args.exe, et mets le dans C:\, de telle sorte que le chemin absolu soit C:\print-args.exeCode:
1
2
3
4
5
6
7
8
9
10
11
12
13
14 #include <stdio.h> int main (int argc, char *argv[]) { int i; printf ("args: "); for (i = 0; i < argc; i++) printf ("%s ", argv[i]); printf ("\n"); return 0; }
Puis, essaie de l'appeler à partir de mon programme de test précédent.
EDIT: grillé :)
Bon, petite remarque sur le code, les casts en void ne servent à rien et nuisent à la lisibilité. Autant juste ignorer la valeur de retour.
Cool ! Maintenant que tu arrives à gérer le cas simple, tu devrais plus facilement comprendre le cas qui pose problème. Quand tu arriveras à lancer ton application de test avec tous les arguments, et au même endroit que ton application scientifique, ça devrait te permettre de comprendre ton erreur. Peut être ton application scientifique a des dépendances qu'elle ne peut pas trouver avec le PATH actuel ? Peut être que c'est le chemin renvoyé par ton appli GTK qui pose problème (là j'y crois moins, le message d'erreur te dit qu'il n'arrive déjà pas à trouver l'exécutable, peu de chance que ça vienne donc des autres arguments). Tiens nous au courant.
Autre chose, je vois dans un de tes messages la ligne suivante:
Tu lances ton code depuis un IDE ? Si c'est le cas méfie toi, il utilise sûrement un PATH spécial, qui peut masquer une partie du PATH du système. Je serais toi je lancerais les exécutables à partir de cmd.exe ou à partir d'une console mingw/msys, histoire d'être sûr de l'environnement.Citation:
Process returned 0 (0x0) execution time : 0.120 s
Mon petit bout de code C fini par "return 0", C'est normal que je récupère "Process returned 0 (0x0) execution time : 0.120 s". Non ? Non, je ne lance pas ce truc à partir d'une interface particulière. Tous mes exécutables sont lancés avec le chemin absolu. Par de problème de PATH a priori.
J'ai pris l'habitude de faire ca pour faire taire les vérificateurs automatiques de syntaxe qui me bassinaient en m'informant que des valeurs de retour étaient produites mais pas utilisées. C'est devenu une habiture de travail pour moi.
Effectivement, je vous tiens au courant. J'espère bosser sur ce truc la semaine prochaine.
Eric.
Bin ça ne ressemble pas à quelque chose qu'un shell renvoie, même cmd.exe. Ça me rappelle plus quelque chose qui sort d'un IDE genre Visual Studio ou d'un Code::Blocks. Dans un shell, tu n'as que le résultat de la sortie standard et la sortie d'erreur, et je ne vois rien dans ton code de test qui pourrait renvoyer ça. C'est pour ça que je me posais des questions sur la manière dont tu invoquais les exécutables.
Faut voir. Tu peux appeler un exécutable par son chemin absolu, s'il dépend de bibliothèques dynamiques qui ne sont pas dans le PATH, ton exécutable échouera à se lancer. C'est pour que ton exécutable de test sans dépendance te permettra de voir si le problème peut venir de là.
Ok... Ces vérificateurs sont là pour t'aider à améliorer le code, mais bon, personne ne teste la valeur de retour d'un printf, donc je comprends l'intérêt.