Bonjour,
Je souhaite toujours piloter ma carte radio FM à distance ;-)
Avec l'aide d'Emmanuel, j'y parviens de la sorte :
$ telnet serveur 5000
Trying 192.168.0.100...
Connected to serveur.novazur.fr (192.168.0.100).
Escape character is '^]'.
off
^] (CTRL-V+])
telnet> quit
Connection closed.
$
coupe bien la radio.
Par contre, je ne parviens pas à utiliser ça dans un script.
$ echo -e "offn^]nquit" | telnet serveur 5000
Trying 192.168.0.100...
Connected to serveur.novazur.fr (192.168.0.100).
Escape character is '^]'.
telnet> Connection closed.
n'a aucune action.
De plus, dans le premier mode, (telnet serveur 5000), je ne sais pas
comment récupérer l'information de retour.
Si quelqu'un peut/veut bien m'aider.
Merci d'avance.
Bonjour,
Je souhaite toujours piloter ma carte radio FM à distance ;-)
Avec l'aide d'Emmanuel, j'y parviens de la sorte :
$ telnet serveur 5000
Trying 192.168.0.100...
Connected to serveur.novazur.fr (192.168.0.100).
Escape character is '^]'.
off
^] (CTRL-V+])
telnet> quit
Connection closed.
$
coupe bien la radio.
Par contre, je ne parviens pas à utiliser ça dans un script.
$ echo -e "offn^]nquit" | telnet serveur 5000
Trying 192.168.0.100...
Connected to serveur.novazur.fr (192.168.0.100).
Escape character is '^]'.
telnet> Connection closed.
n'a aucune action.
De plus, dans le premier mode, (telnet serveur 5000), je ne sais pas
comment récupérer l'information de retour.
Si quelqu'un peut/veut bien m'aider.
Merci d'avance.
Bonjour,
Je souhaite toujours piloter ma carte radio FM à distance ;-)
Avec l'aide d'Emmanuel, j'y parviens de la sorte :
$ telnet serveur 5000
Trying 192.168.0.100...
Connected to serveur.novazur.fr (192.168.0.100).
Escape character is '^]'.
off
^] (CTRL-V+])
telnet> quit
Connection closed.
$
coupe bien la radio.
Par contre, je ne parviens pas à utiliser ça dans un script.
$ echo -e "offn^]nquit" | telnet serveur 5000
Trying 192.168.0.100...
Connected to serveur.novazur.fr (192.168.0.100).
Escape character is '^]'.
telnet> Connection closed.
n'a aucune action.
De plus, dans le premier mode, (telnet serveur 5000), je ne sais pas
comment récupérer l'information de retour.
Si quelqu'un peut/veut bien m'aider.
Merci d'avance.
telnet (et ftp, et en général, tout les programmes interactifs) est
embêtant à utiliser dans un script. Si on insiste pour telnet, le
mieux est d'utiliser expect qui simule le rôle de l'utilisateur.
Mais dans ton cas, l'outil le plus approprié semble être netcat, où à
la limite, bash:
echo off > /dev/tcp/192.168.0.100/5000
man, man bash, etc,
(D'ailleurs, si les sessions de commande ne constituent toujours que
d'une seule commande, et donc d'un seul paquet, le serveur pourrait
trés bien utiliser plutôt udp, et alors ça donnerait sur bash:
echo off > /dev/udp/192.168.0.100/5000
telnet (et ftp, et en général, tout les programmes interactifs) est
embêtant à utiliser dans un script. Si on insiste pour telnet, le
mieux est d'utiliser expect qui simule le rôle de l'utilisateur.
Mais dans ton cas, l'outil le plus approprié semble être netcat, où à
la limite, bash:
echo off > /dev/tcp/192.168.0.100/5000
man, man bash, etc,
(D'ailleurs, si les sessions de commande ne constituent toujours que
d'une seule commande, et donc d'un seul paquet, le serveur pourrait
trés bien utiliser plutôt udp, et alors ça donnerait sur bash:
echo off > /dev/udp/192.168.0.100/5000
telnet (et ftp, et en général, tout les programmes interactifs) est
embêtant à utiliser dans un script. Si on insiste pour telnet, le
mieux est d'utiliser expect qui simule le rôle de l'utilisateur.
Mais dans ton cas, l'outil le plus approprié semble être netcat, où à
la limite, bash:
echo off > /dev/tcp/192.168.0.100/5000
man, man bash, etc,
(D'ailleurs, si les sessions de commande ne constituent toujours que
d'une seule commande, et donc d'un seul paquet, le serveur pourrait
trés bien utiliser plutôt udp, et alors ça donnerait sur bash:
echo off > /dev/udp/192.168.0.100/5000
Le Thu, 28 Aug 2003 22:39:23 +0200, Pascal Bourguignon a écrit:telnet (et ftp, et en général, tout les programmes interactifs) est
embêtant à utiliser dans un script. Si on insiste pour telnet, le
mieux est d'utiliser expect qui simule le rôle de l'utilisateur.
Mais dans ton cas, l'outil le plus approprié semble être netcat, où à
la limite, bash:
Alors, je ne m'accrocherai pas à telnet ;-)
Mais nc, nous avions déjà essayé, et c'est pour sortir de la session que
ça coince, il me faut faire un CTRL-C pour couper le process, et là,
l'action est bien exécutée par le serveur.
Par contre, toujours aucune sortie (retour d'info)
$ echo "off" | nc serveur 5000
punt! (ici, un CTRL-C)
$echo off > /dev/tcp/192.168.0.100/5000
Wahou, super !!
Alors ça, faut connaître !
Et comment je récupère l'info de retour avec ça ?man, man bash, etc,
Bien sûr, dès que je saurai ce que je dois y chercher ;-)
(D'ailleurs, si les sessions de commande ne constituent toujours que
d'une seule commande, et donc d'un seul paquet, le serveur pourrait
trés bien utiliser plutôt udp, et alors ça donnerait sur bash:
echo off > /dev/udp/192.168.0.100/5000
C'est bien mon cas, toujours un seul argument, mais pourtant ça ne
fonctionne pas.
Le Thu, 28 Aug 2003 22:39:23 +0200, Pascal Bourguignon a écrit:
telnet (et ftp, et en général, tout les programmes interactifs) est
embêtant à utiliser dans un script. Si on insiste pour telnet, le
mieux est d'utiliser expect qui simule le rôle de l'utilisateur.
Mais dans ton cas, l'outil le plus approprié semble être netcat, où à
la limite, bash:
Alors, je ne m'accrocherai pas à telnet ;-)
Mais nc, nous avions déjà essayé, et c'est pour sortir de la session que
ça coince, il me faut faire un CTRL-C pour couper le process, et là,
l'action est bien exécutée par le serveur.
Par contre, toujours aucune sortie (retour d'info)
$ echo "off" | nc serveur 5000
punt! (ici, un CTRL-C)
$
echo off > /dev/tcp/192.168.0.100/5000
Wahou, super !!
Alors ça, faut connaître !
Et comment je récupère l'info de retour avec ça ?
man, man bash, etc,
Bien sûr, dès que je saurai ce que je dois y chercher ;-)
(D'ailleurs, si les sessions de commande ne constituent toujours que
d'une seule commande, et donc d'un seul paquet, le serveur pourrait
trés bien utiliser plutôt udp, et alors ça donnerait sur bash:
echo off > /dev/udp/192.168.0.100/5000
C'est bien mon cas, toujours un seul argument, mais pourtant ça ne
fonctionne pas.
Le Thu, 28 Aug 2003 22:39:23 +0200, Pascal Bourguignon a écrit:telnet (et ftp, et en général, tout les programmes interactifs) est
embêtant à utiliser dans un script. Si on insiste pour telnet, le
mieux est d'utiliser expect qui simule le rôle de l'utilisateur.
Mais dans ton cas, l'outil le plus approprié semble être netcat, où à
la limite, bash:
Alors, je ne m'accrocherai pas à telnet ;-)
Mais nc, nous avions déjà essayé, et c'est pour sortir de la session que
ça coince, il me faut faire un CTRL-C pour couper le process, et là,
l'action est bien exécutée par le serveur.
Par contre, toujours aucune sortie (retour d'info)
$ echo "off" | nc serveur 5000
punt! (ici, un CTRL-C)
$echo off > /dev/tcp/192.168.0.100/5000
Wahou, super !!
Alors ça, faut connaître !
Et comment je récupère l'info de retour avec ça ?man, man bash, etc,
Bien sûr, dès que je saurai ce que je dois y chercher ;-)
(D'ailleurs, si les sessions de commande ne constituent toujours que
d'une seule commande, et donc d'un seul paquet, le serveur pourrait
trés bien utiliser plutôt udp, et alors ça donnerait sur bash:
echo off > /dev/udp/192.168.0.100/5000
C'est bien mon cas, toujours un seul argument, mais pourtant ça ne
fonctionne pas.
Faut tout lire! Voir par exemple, la section REDIRECTION.
Pour faire des essais comme le suivant, activer le service echo dans
inetd, et:
( while read -p 'comande: ' comande < /dev/tty ; do echo $comande ; read
rep ; echo reponse: $rep >/dev/tty ; done ) 0<>/dev/tcp/localhost/echo 1>&0
comande: hello
reponse: hello
Donc, un:
( echo off ; read rep ; echo reponse: $rep >/dev/tty )
0<>/dev/tcp/192.168.0.100/5000 1>&0
devrait fonctionner...
Avec bash, si on ne veut pas s'amuser (et s'embêter) avec des
sous-shells en parallèle, il vaut peut être mieux utiliser tcp que
udp, j'ai l'impression.
Faut tout lire! Voir par exemple, la section REDIRECTION.
Pour faire des essais comme le suivant, activer le service echo dans
inetd, et:
( while read -p 'comande: ' comande < /dev/tty ; do echo $comande ; read
rep ; echo reponse: $rep >/dev/tty ; done ) 0<>/dev/tcp/localhost/echo 1>&0
comande: hello
reponse: hello
Donc, un:
( echo off ; read rep ; echo reponse: $rep >/dev/tty )
0<>/dev/tcp/192.168.0.100/5000 1>&0
devrait fonctionner...
Avec bash, si on ne veut pas s'amuser (et s'embêter) avec des
sous-shells en parallèle, il vaut peut être mieux utiliser tcp que
udp, j'ai l'impression.
Faut tout lire! Voir par exemple, la section REDIRECTION.
Pour faire des essais comme le suivant, activer le service echo dans
inetd, et:
( while read -p 'comande: ' comande < /dev/tty ; do echo $comande ; read
rep ; echo reponse: $rep >/dev/tty ; done ) 0<>/dev/tcp/localhost/echo 1>&0
comande: hello
reponse: hello
Donc, un:
( echo off ; read rep ; echo reponse: $rep >/dev/tty )
0<>/dev/tcp/192.168.0.100/5000 1>&0
devrait fonctionner...
Avec bash, si on ne veut pas s'amuser (et s'embêter) avec des
sous-shells en parallèle, il vaut peut être mieux utiliser tcp que
udp, j'ai l'impression.
( echo off ; read rep ; echo reponse: $rep >/dev/tty )
0<>/dev/tcp/192.168.0.100/5000 1>&0
devrait fonctionner...
Ne fonctionne que lorsque je fais CTRL-C pour quitter.
Toujours le même problème qu'avec nc et telnet d'ailleurs.
( echo off ; read rep ; echo reponse: $rep >/dev/tty )
0<>/dev/tcp/192.168.0.100/5000 1>&0
devrait fonctionner...
Ne fonctionne que lorsque je fais CTRL-C pour quitter.
Toujours le même problème qu'avec nc et telnet d'ailleurs.
( echo off ; read rep ; echo reponse: $rep >/dev/tty )
0<>/dev/tcp/192.168.0.100/5000 1>&0
devrait fonctionner...
Ne fonctionne que lorsque je fais CTRL-C pour quitter.
Toujours le même problème qu'avec nc et telnet d'ailleurs.
Lire le manuel de *votre* commande.
Lire le manuel de *votre* commande.
Lire le manuel de *votre* commande.
Lire le manuel de *votre* commande.
Ma commande ?
Ben, c'est juste un script bash qui traite l'entrée $1.
Lire le manuel de *votre* commande.
Ma commande ?
Ben, c'est juste un script bash qui traite l'entrée $1.
Lire le manuel de *votre* commande.
Ma commande ?
Ben, c'est juste un script bash qui traite l'entrée $1.
Le Thu, 28 Aug 2003 22:43:19 -0400, Christophe PEREZ a écrit:( echo off ; read rep ; echo reponse: $rep >/dev/tty )
0<>/dev/tcp/192.168.0.100/5000 1>&0
devrait fonctionner...
[...]
Où est donc l'astuce ?
Je pense qu'en fait, lorsque ce problème sera résolu, tout le reste
fonctionnera comme cela devrait.
Le Thu, 28 Aug 2003 22:43:19 -0400, Christophe PEREZ a écrit:
( echo off ; read rep ; echo reponse: $rep >/dev/tty )
0<>/dev/tcp/192.168.0.100/5000 1>&0
devrait fonctionner...
[...]
Où est donc l'astuce ?
Je pense qu'en fait, lorsque ce problème sera résolu, tout le reste
fonctionnera comme cela devrait.
Le Thu, 28 Aug 2003 22:43:19 -0400, Christophe PEREZ a écrit:( echo off ; read rep ; echo reponse: $rep >/dev/tty )
0<>/dev/tcp/192.168.0.100/5000 1>&0
devrait fonctionner...
[...]
Où est donc l'astuce ?
Je pense qu'en fait, lorsque ce problème sera résolu, tout le reste
fonctionnera comme cela devrait.
Peut être qu'il serait mieux de concevoir le script comme un vrai
serveur, et qu'il prenne ses commandes sur l'entrée standard et ses
réponses sur la sortie standard, au lieu de passer par les arguments.
Ainsi, tu pourras éviter d'utiliser xargs dans la configuration
xinetd: directement le script serveur. (Rien n'empêche le script
d'accepter des arguments, mais de lire l'entrée standard s'il n'y en a
pas).
Peut être qu'il serait mieux de concevoir le script comme un vrai
serveur, et qu'il prenne ses commandes sur l'entrée standard et ses
réponses sur la sortie standard, au lieu de passer par les arguments.
Ainsi, tu pourras éviter d'utiliser xargs dans la configuration
xinetd: directement le script serveur. (Rien n'empêche le script
d'accepter des arguments, mais de lire l'entrée standard s'il n'y en a
pas).
Peut être qu'il serait mieux de concevoir le script comme un vrai
serveur, et qu'il prenne ses commandes sur l'entrée standard et ses
réponses sur la sortie standard, au lieu de passer par les arguments.
Ainsi, tu pourras éviter d'utiliser xargs dans la configuration
xinetd: directement le script serveur. (Rien n'empêche le script
d'accepter des arguments, mais de lire l'entrée standard s'il n'y en a
pas).
Peut être qu'il serait mieux de concevoir le script comme un vrai
serveur, et qu'il prenne ses commandes sur l'entrée standard et ses
réponses sur la sortie standard, au lieu de passer par les arguments.
Peut être qu'il serait mieux de concevoir le script comme un vrai
serveur, et qu'il prenne ses commandes sur l'entrée standard et ses
réponses sur la sortie standard, au lieu de passer par les arguments.
Peut être qu'il serait mieux de concevoir le script comme un vrai
serveur, et qu'il prenne ses commandes sur l'entrée standard et ses
réponses sur la sortie standard, au lieu de passer par les arguments.