system et redirection sortie standard sous linux

Bonjour,

Je suis en train de developper une interface utilisant ncurses. Une de mes fonctionnalites est de pouvoir editer un fichier texte. Pour cela, j'utilise la commande system pour lancer un terminal et lancer un editeur. Seulement voila, lorsque system renvoie une erreur (s'il ne trouve pas le terminal) alors il m'affiche une chaine a l'ecran. C'est ca que je ne veux pas puisqu'utilisant ncurses, ca m'affiche ca n'importe comment.

voici le bout de code concerné :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

void FormScripts::editerFichier(string nomFichier) { string terminal = getTerminal(); string editeur = getEditeur();   string commande; if(terminal == "") { commande = editeur + " " + nomFichier;   } else { commande = terminal + " -e=\"" + editeur + " " + nomFichier + "\""; }   commande += " > Erreurs.log";   system(commande.c_str()); }

---

PS: j'ai aussi essayé dup et freopen mais ca me fait toujours la meme chose.

Comment faire pour empecher system d'afficher des infos à l'ecran ? Et comment les recuperer ?

Merci

[EDIT]
Le fichier Erreurs.log est créé mais il ne contient rien.

[EDIT2]
En fait la sortie ne se fait pas sur stdout mais sur stderr. En redirigeant la sortie stderr avec freopen, ca marche. Maintenant je ne sait pas comment remettre la sortie stderr comme avant

je pense que google est ton ami :
tape "man system" ;)

Euh je crois que j'ai passé pas mal de temps sur google deja. Sinon j'aurais pas posté ici.

Comme je l'ai mis dans mon 2eme edit, j'arrive a rediriger les messages ecris par la commande system par contre je n'arrive pas ensuite a rerediriger les messages d'erreurs vers la sortie stderr comme au debut.
Je ne vois pas comment faire merci

La redirection d'un flux standard se fait avec sa fonction membre rdbuf.

Code:

---

1 2 3 4 5 6 7

std::ofstream Errors("Toto.txt");   std::streambuf* OldBuf = std::cerr.rdbuf(Errors.rdbuf());   ...   std::cerr.rdbuf(OldBuf);

---

Ensuite j'imagine que comme sous Windows, il existe sous Linux des fonctions pour exécuter un programme sans utiliser system (exec ?).

Citation:

---

Ensuite j'imagine que comme sous Windows, il existe sous Linux des fonctions pour exécuter un programme sans utiliser system (exec ?).

---

oui tu as la serie des execc execl et execv ...

sinon tu peux peut etre rediriger ta commande dans un fichier ou mieu dans un pipe et de lire l autre bout du pipe

Merci pour vos réponses. Je n'ai pas de pc ce week end pour tester. Je testerais ça plus tard.

Citation:

---

std::ofstream Errors("Toto.txt");

std::streambuf* OldBuf = std::cerr.rdbuf(Errors.rdbuf());

...

std::cerr.rdbuf(OldBuf);

---

[EDIT]
Ca ne marche pas. J'ai l'impression que stderr et cerr ne sont pas du tout liés. Du coup, le message s'affiche toujours. Comment faire en C pour rediriger TEMPORAIREMENT stderr ? (je sais comment rediriger mais pas comment remettre a l'origine une fois mon traitement effectué).

Merci

Voici ce que je fais :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

FILE* sortie = freopen("Erreurs.log", "w", stderr); if(sortie != NULL) { int err = system(commande.c_str());   if(err != 0) { // afficher l'erreur contenue dans le fichier // ca ca marche } fclose(sortie);   // reouvrir la sortie erreur standard // ce que je cherche }

---

Ceci me permet de recuperer le message d'erreur dans un fichier donc ok.
Mon probleme est que je ne sait pas replacer la sortie erreur standard dans son flux.
Pouvez-vous m'aider ?
Merci

Il est trivial de faire des redirections avec boost.process.

Citation:

---

Envoyé par loufoque

boost.process.

---

C'est caché où ??
J'avais déjà utilisé popen() comme une source pour un boost.iostream, mais ne connaissait pas boost.process.

http://www.NetBSD.org/~jmmv/process/

Ya pas moyen de le faire sans boost?

Je viens de trouver une discution très intéressante sur un autre forum (en anglais).
En fait si ton code marche pas Laurent Gomilla c'est parce que cerr n'utilise pas de buffer donc pas de redirection possible de cette facon.

On connait tous (ou presque) l'operateur > pour rediriger la sortie standard dans un fichier. Ceci redirige donc cout dans un fichier.

Cependant pour cerr, l'operateur est 2>
Exemple de commande qui renvoie une erreur et qui la met dans le fichier erreur.txt :

Code:

---

1 2	system("aaaa aaa 2> erreur.txt");

---

Merci a tous pour vos reponses. J'ai enfin ma solution!!!

PS : Voici le lien http://www.velocityreviews.com/forum...6-stdcerr.html

Citation:

---

En fait si ton code marche pas Laurent Gomilla c'est parce que cerr n'utilise pas de buffer donc pas de redirection possible de cette facon

---

C'est tout de même étonnant.

La solution de Laurent intercepte les messages envoyés à la variable globale std::cerr de l'exécutable courant, pas ceux qui partent sur le canal 2 (stderr) des process invoqués. Il est normal que cela ne réponde pas à la question -- de ce que j'en sais.

Preuve.

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

// redirect-iostream.cpp #include <iostream> #include <fstream> #include <cstdlib>   void do_redirect(std::ostream & os, std::string const& dest) { std::ofstream Errors("Toto.txt");   std::streambuf* OldBuf = os.rdbuf(Errors.rdbuf());     os << "Debut" << std::endl; std::system(("echo 'toto'"+dest).c_str()); os << "Fin" << std::endl; os.rdbuf(OldBuf); }   int main (int argc, char **argv) { // do_redirect(std::cout, ""); do_redirect(std::cerr, " > /dev/stderr");   }

---

Code:

---

$> ./redirect-iostream 2> titi.txt

---

Code:

---

1 2	$> cat titi.txt toto

---

Recommencez avec cout, c'est tout pareil.
La bufferisation, n'a rien à voir a priori. C'est pour faire des flush automatiquement après chaque insertion, ce qui est sans rapport avec les détournements de canaux des sous-process.

Amusez-vous aussi à rajouter des (f)printf sur stdout, et stderr. Vous verrez que ce qui est détourné, c'est le stream C++, pas les canaux stdout/stderr.

Bref,

Code:

---

man pipe

---

On doit pouvoir y arriver avec. Peut-être avec popen, mais c'est moins sûr.

Re-bref. Mauvais forum => dev linux (faute de dev posix & cie).

Il peut y avoir des choses dans le code de mutt aussi. Vu qu'il permet de lancer d'autres outils comme vim, ...