Forum Programmation.c Lancer le programme 'chat' sur un port série

Posté par  .
Étiquettes :
0
26
mai
2011

Bonjour,

Pour lancer une connexion Internet à partir d'un modem, j'utilise le programme "chat" qui permet de lancer des commandes sur port série, en fonction des réponses du modem.

Pour l'utiliser, à partir d'une console Bash il faut que je lance le commande :

"stty -F /dev/ttyMODEM speed 9600"

pour configurer le port série, puis

chat -v -f /etc/chatscripts/gprs-signal <> /dev/ttyMODEM >&0

pour que le script chat dialogue avec le modem.

Il s'agit donc d'une redirection Read & Write des entrées/sorties standard de chat vers le port série ttyMODEM.

Les informations sont envoyées sur stderr.

J'aimerai réaliser les mêmes redirections dans un programme C, pour me passer du shell.
Il faut donc que j'effectue les redirections avant de lancer le processus "chat" par execv.

J'ai essayé :

   freopen("/dev/ttyMODEM", "w", stdout);
   freopen("/dev/ttyMODEM", "r", stdin     
   char * argv[5];
   argv[0] = "chat";
   argv[1] = "-v";
   argv[2] = "-f";
   argv[3] = "/etc/chatscripts/gprs-signal";
   argv[4] = (char *) NULL;
   execv("/usr/sbin/chat", argv);
   perror("execv");
   return;

Mais cela ne fonctionne pas.

  • # parce que execv() lance un shell, non ?

    Posté par  . Évalué à 2.

    dans ton programme tu fais

    execv("/usr/sbin/chat", argv);

    hors il me semble qu'en C, la fonction execv() lance un appel systeme qui remplace les infos courantes par une nouvelle

    ce qui semble confirmé par la page de man execv()

    The exec() family of functions replaces the current process image with a new process image.

  • # Parce que <> ne fait pas ce que tu crois.

    Posté par  . Évalué à 2.

    $ man bash

    Ouverture en Lecture/Écriture d'un descripteur de fichier

     L'opérateur de redirection

         [n]<>mot

 conduit  à  l'ouverture du fichier dont le nom résulte du développement
 du mot, à la fois en lecture et en écriture et lui affecte le  descrip‐
 teur de fichier n ou bien le descripteur 0 si n n'est pas mentionné. Si
 le fichier n'existe pas, il est créé.

    D'ailleurs, la redirection >&0 devrai t'avoir mis la puce à l'oreille. C'est de la bonne grosse redirection de flux imbitable ce qu'on à là.

  • # dup2 + fcntl

    Posté par  . Évalué à 1.

    C'est sûrement dû au CLOSE-ON-EXEC. Je ne pense pas que tu puisses le manipuler directement en utilisant des FILE *, mais avec des file descriptor ça devrait marcher, comme dans ce bout de code : 

    #include <stdio.h>
#include <fcntl.h>
#include <unistd.h>

int main(int ac, char **av)
{
    int input, output;
    const char * modem = "/dev/ttyMODEM";
    const char * argv[4];

    input = open(modem, O_RDONLY);
    if (input < 0) {
	fprintf(stderr, "Can't open <%s> for reading: %m\n", modem);
	return 1;
    }

    output = open(modem, O_WRONLY);
    if (output < 0) {
	fprintf(stderr, "Can't open <%s> for writing: %m\n", modem);
	return 1;
    }

    if (fcntl(input, F_SETFD, 0) < 0) {
	fprintf(stderr, "Failed to clear close-on-exec flag in input: %m\n");
	return 1;
    }

    if (fcntl(output, F_SETFD, 0) < 0) {
	fprintf(stderr, "Failed to clear close-on-exec flag in output: %m\n");
	return 1;
    }

    if (dup2(input, STDIN_FILENO) < 0) {
	fprintf(stderr, "Cant set input: %m\n");
	return 1;
    }

    if (dup2(output, STDOUT_FILENO) < 0) {
	fprintf(stderr, "Cant set output: %m\n");
	return 1;
    }

    close(input);
    close(output);

    argv[0] = "/usr/sbin/chat";
    argv[1] = "-v";
    argv[2] = "-f";
    argv[3] = NULL;
    if (execv(argv[0], argv) < 0) {
	fprintf(stderr, "Failed to execv(%s, %s, %s): %m\n", argv[0], argv[1], argv[2]);
	return 1;
    }

    return 0;
}

    • [^] # Re: dup2 + fcntl

      Posté par  . Évalué à 0.

      Bonjour

      En effet ça marche, c'est ce que je cherchai, merci.

      Maintenant je vais essayer de dupliquer la sortie d'erreur du programme chat, pour l'enregistrer dans un fichier.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.