Je souhaite rediriger la sortie complète vers un fichier résultat.
J'obtiens un résultat satisfaisant avec telnet toto > résultat
Cependant, à la fin de mon script, j'ai la ligne "Connection closed by
foreign host" qui s'affiche.
Je la trouve interessante car dans le cas où le routeur distant ne
répond pas au telnet, la ligne suivante s'affiche :telnet: connect to
address 10.33.21.24: No route to host
mais pas dans le fichier résultat...
Comment faire pour récupérer cette ligne dans mon fichier résultat ?
Je souhaite rediriger la sortie complète vers un fichier résultat. J'obtiens un résultat satisfaisant avec telnet toto > résultat Cependant, à la fin de mon script, j'ai la ligne "Connection closed by foreign host" qui s'affiche. Je la trouve interessante car dans le cas où le routeur distant ne répond pas au telnet, la ligne suivante s'affiche :telnet: connect to address 10.33.21.24: No route to host mais pas dans le fichier résultat...
Comment faire pour récupérer cette ligne dans mon fichier résultat ?
Je ne suis pas sûr que ma réponse correspondra exactement à ton attente, mais tu peux essayer de récupérer aussi la sortie d'erreur.
Un truc du genre 'telnet toto 2>&1 1> resultat' pourrait marcher.
-- Jean-Jacques Puig
[homepage] http://www-lor.int-evry.fr/~puig/
On 2004-02-05, Fred <fred@nospam.fr> wrote:
Bonjour,
j'ai un petit soucis avec telnet.
Je souhaite rediriger la sortie complète vers un fichier résultat.
J'obtiens un résultat satisfaisant avec telnet toto > résultat
Cependant, à la fin de mon script, j'ai la ligne "Connection closed by
foreign host" qui s'affiche.
Je la trouve interessante car dans le cas où le routeur distant ne
répond pas au telnet, la ligne suivante s'affiche :telnet: connect to
address 10.33.21.24: No route to host
mais pas dans le fichier résultat...
Comment faire pour récupérer cette ligne dans mon fichier résultat ?
Je ne suis pas sûr que ma réponse correspondra exactement à ton attente,
mais tu peux essayer de récupérer aussi la sortie d'erreur.
Un truc du genre 'telnet toto 2>&1 1> resultat' pourrait marcher.
Je souhaite rediriger la sortie complète vers un fichier résultat. J'obtiens un résultat satisfaisant avec telnet toto > résultat Cependant, à la fin de mon script, j'ai la ligne "Connection closed by foreign host" qui s'affiche. Je la trouve interessante car dans le cas où le routeur distant ne répond pas au telnet, la ligne suivante s'affiche :telnet: connect to address 10.33.21.24: No route to host mais pas dans le fichier résultat...
Comment faire pour récupérer cette ligne dans mon fichier résultat ?
Je ne suis pas sûr que ma réponse correspondra exactement à ton attente, mais tu peux essayer de récupérer aussi la sortie d'erreur.
Un truc du genre 'telnet toto 2>&1 1> resultat' pourrait marcher.
-- Jean-Jacques Puig
[homepage] http://www-lor.int-evry.fr/~puig/
Denis L'Excellent
Fred wrote:
Comment faire pour récupérer cette ligne dans mon fichier résultat ?
Merci beaucoup
Fred
Tu tapes telnet toto > résultat 2> résultat pour rediriger aussi les erreurs dans ton fichier (le pointeur 2 désignant la sortie standard en erreur qui par défaut est ta console)
-- AAB Lyon 2003 Sans L'Excellence ...
Fred wrote:
Comment faire pour récupérer cette ligne dans mon fichier résultat ?
Merci beaucoup
Fred
Tu tapes telnet toto > résultat 2> résultat pour rediriger aussi les
erreurs dans ton fichier (le pointeur 2 désignant la sortie standard en
erreur qui par défaut est ta console)
Comment faire pour récupérer cette ligne dans mon fichier résultat ?
Merci beaucoup
Fred
Tu tapes telnet toto > résultat 2> résultat pour rediriger aussi les erreurs dans ton fichier (le pointeur 2 désignant la sortie standard en erreur qui par défaut est ta console)
-- AAB Lyon 2003 Sans L'Excellence ...
Stephane Chazelas
2004-02-5, 10:27(+00), Jean-Jacques Puig: [...]
Un truc du genre 'telnet toto 2>&1 1> resultat' pourrait marcher.
Non, ça ça redirige la sortie d'erreur vers la sortie standard (le terminal à ce moment là), puis, la sortie standard vers "resultat".
Tu tapes telnet toto > résultat 2> résultat pour rediriger aussi les erreurs dans ton fichier (le pointeur 2 désignant la sortie standard en erreur qui par défaut est ta console)
Non, ça, ça ouvre le fichier deux fois, donc, les messages de stdout et stderr vont se marcher dessus (en gros ya deux curseurs indépendants sur le même fichier).
Tu tapes telnet toto > résultat 2> résultat pour rediriger aussi les
erreurs dans ton fichier (le pointeur 2 désignant la sortie standard en
erreur qui par défaut est ta console)
Non, ça, ça ouvre le fichier deux fois, donc, les messages de
stdout et stderr vont se marcher dessus (en gros ya deux
curseurs indépendants sur le même fichier).
Tu tapes telnet toto > résultat 2> résultat pour rediriger aussi les erreurs dans ton fichier (le pointeur 2 désignant la sortie standard en erreur qui par défaut est ta console)
Non, ça, ça ouvre le fichier deux fois, donc, les messages de stdout et stderr vont se marcher dessus (en gros ya deux curseurs indépendants sur le même fichier).
Tu tapes telnet toto > résultat 2> résultat pour rediriger aussi les erreurs dans ton fichier (le pointeur 2 désignant la sortie standard en erreur qui par défaut est ta console)
Non, ça, ça ouvre le fichier deux fois, donc, les messages de stdout et stderr vont se marcher dessus (en gros ya deux curseurs indépendants sur le même fichier).
Rhoo la honte, désolé, je ne répondrais plus, il y a des gens bien mieux placés que moi pour ça ....
-- AAB Lyon 2003 Sans L'Excellence ...
Stephane Chazelas wrote:
2004-02-05, 11:29(+01), Denis L'Excellent:
[...]
Tu tapes telnet toto > résultat 2> résultat pour rediriger aussi les
erreurs dans ton fichier (le pointeur 2 désignant la sortie standard en
erreur qui par défaut est ta console)
Non, ça, ça ouvre le fichier deux fois, donc, les messages de
stdout et stderr vont se marcher dessus (en gros ya deux
curseurs indépendants sur le même fichier).
Rhoo la honte, désolé, je ne répondrais plus, il y a des gens bien mieux
placés que moi pour ça ....
Tu tapes telnet toto > résultat 2> résultat pour rediriger aussi les erreurs dans ton fichier (le pointeur 2 désignant la sortie standard en erreur qui par défaut est ta console)
Non, ça, ça ouvre le fichier deux fois, donc, les messages de stdout et stderr vont se marcher dessus (en gros ya deux curseurs indépendants sur le même fichier).
Rhoo la honte, désolé, je ne répondrais plus, il y a des gens bien mieux placés que moi pour ça ....
-- AAB Lyon 2003 Sans L'Excellence ...
Nicolas.MICHEL
Stephane Chazelas wrote:
2004-02-5, 10:27(+00), Jean-Jacques Puig: [...]
Un truc du genre 'telnet toto 2>&1 1> resultat' pourrait marcher.
Non, ça ça redirige la sortie d'erreur vers la sortie standard (le terminal à ce moment là), puis, la sortie standard vers "resultat".
telnet toto > resultat 2>&1
(voir aussi la commande script).
si je comprends bien, bash évalues les redirections de droite à gauche ?
Donc dans le poste de Hugolino, le mois dernier, Message-ID: à la question "que fait : /etc/init.d/fetchmail awaken >/dev/null 2>&1 || /etc/init.d/fetchmail start"
il commence par exécuter fetchmail awaken , puis il lance fetchmail start s'il y a une erreur, puis il redirige l'erreur sur stdout, puis il envoie stdout (stderr inclus) vers /dev/null ?
Si c'est ça, alors j'ai compris le principes :) -- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Un truc du genre 'telnet toto 2>&1 1> resultat' pourrait marcher.
Non, ça ça redirige la sortie d'erreur vers la sortie standard
(le terminal à ce moment là), puis, la sortie standard vers
"resultat".
telnet toto > resultat 2>&1
(voir aussi la commande script).
si je comprends bien, bash évalues les redirections de droite à gauche ?
Donc dans le poste de Hugolino, le mois dernier,
Message-ID: <slrnbvn24o.hku.hugolino@Deborah.RocknRoll.org>
à la question "que fait :
/etc/init.d/fetchmail awaken >/dev/null 2>&1 || /etc/init.d/fetchmail
start"
il commence par exécuter fetchmail awaken , puis il lance fetchmail
start s'il y a une erreur, puis il redirige l'erreur sur stdout, puis il
envoie stdout (stderr inclus) vers /dev/null ?
Si c'est ça, alors j'ai compris le principes :)
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
Un truc du genre 'telnet toto 2>&1 1> resultat' pourrait marcher.
Non, ça ça redirige la sortie d'erreur vers la sortie standard (le terminal à ce moment là), puis, la sortie standard vers "resultat".
telnet toto > resultat 2>&1
(voir aussi la commande script).
si je comprends bien, bash évalues les redirections de droite à gauche ?
Donc dans le poste de Hugolino, le mois dernier, Message-ID: à la question "que fait : /etc/init.d/fetchmail awaken >/dev/null 2>&1 || /etc/init.d/fetchmail start"
il commence par exécuter fetchmail awaken , puis il lance fetchmail start s'il y a une erreur, puis il redirige l'erreur sur stdout, puis il envoie stdout (stderr inclus) vers /dev/null ?
Si c'est ça, alors j'ai compris le principes :) -- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Stephane Chazelas
2004-02-5, 13:31(+01), Nicolas MICHEL: [...]
telnet toto > resultat 2>&1
(voir aussi la commande script).
si je comprends bien, bash évalues les redirections de droite à gauche ?
??? Ben non, de gauche à droite (attention, le '|' n'est pas (qu')un opérateur de redirection). On le refait au ralenti:
Dans cmd > file 2>&1
Au départ: fd1 (stdout) associé au terminal fd2 (stderr) associé au terminal
puis, après "> file" fd1 (stdout) associé au fichier "file" fd2 (stderr) pas changé (terminal)
pui, après "2>&1" fd1 (stdout) pas changé ("file") fd2 (stderr) associé à la même chose que 1 (&1), c'est à dire "file" [internally au moyen d'une dupplication de fd, ce qui fait qu'un seul curseur sur le fichier est partagé pour les fd 1 et 2].
Si ça avait été lu à l'envers, on aurait eu: fd2 associé à la même chose que 1 (terminal), puis fd 1 associé (re-affecté, ça n'influe pas sur ce sur quoi est ouvert le fd 2) au fichier "file".
si je comprends bien, bash évalues les redirections de droite à gauche ?
??? Ben non, de gauche à droite (attention, le '|' n'est pas
(qu')un opérateur de redirection). On le refait au ralenti:
Dans cmd > file 2>&1
Au départ:
fd1 (stdout) associé au terminal
fd2 (stderr) associé au terminal
puis, après "> file"
fd1 (stdout) associé au fichier "file"
fd2 (stderr) pas changé (terminal)
pui, après "2>&1"
fd1 (stdout) pas changé ("file")
fd2 (stderr) associé à la même chose que 1 (&1), c'est à dire
"file" [internally au moyen d'une dupplication de fd, ce qui
fait qu'un seul curseur sur le fichier est partagé pour les fd 1
et 2].
Si ça avait été lu à l'envers, on aurait eu: fd2 associé à la
même chose que 1 (terminal), puis fd 1 associé (re-affecté, ça
n'influe pas sur ce sur quoi est ouvert le fd 2) au fichier
"file".
si je comprends bien, bash évalues les redirections de droite à gauche ?
??? Ben non, de gauche à droite (attention, le '|' n'est pas (qu')un opérateur de redirection). On le refait au ralenti:
Dans cmd > file 2>&1
Au départ: fd1 (stdout) associé au terminal fd2 (stderr) associé au terminal
puis, après "> file" fd1 (stdout) associé au fichier "file" fd2 (stderr) pas changé (terminal)
pui, après "2>&1" fd1 (stdout) pas changé ("file") fd2 (stderr) associé à la même chose que 1 (&1), c'est à dire "file" [internally au moyen d'une dupplication de fd, ce qui fait qu'un seul curseur sur le fichier est partagé pour les fd 1 et 2].
Si ça avait été lu à l'envers, on aurait eu: fd2 associé à la même chose que 1 (terminal), puis fd 1 associé (re-affecté, ça n'influe pas sur ce sur quoi est ouvert le fd 2) au fichier "file".
si je comprends bien, bash évalues les redirections de droite à gauche ?
??? Ben non, de gauche à droite (attention, le '|' n'est pas (qu')un opérateur de redirection). On le refait au ralenti:
Dans cmd > file 2>&1
Au départ: fd1 (stdout) associé au terminal fd2 (stderr) associé au terminal
puis, après "> file" fd1 (stdout) associé au fichier "file" fd2 (stderr) pas changé (terminal)
pui, après "2>&1" fd1 (stdout) pas changé ("file") fd2 (stderr) associé à la même chose que 1 (&1), c'est à dire "file" [internally au moyen d'une dupplication de fd, ce qui fait qu'un seul curseur sur le fichier est partagé pour les fd 1 et 2].
Si ça avait été lu à l'envers, on aurait eu: fd2 associé à la même chose que 1 (terminal), puis fd 1 associé (re-affecté, ça n'influe pas sur ce sur quoi est ouvert le fd 2) au fichier "file".
[...]
Si c'est ça, alors j'ai compris le principes :)
C'était pas ça.
Merci beaucoup, ca fonctionne très bien
fred
2004-02-5, 13:31(+01), Nicolas MICHEL:
[...]
telnet toto > resultat 2>&1
(voir aussi la commande script).
si je comprends bien, bash évalues les redirections de droite à gauche ?
??? Ben non, de gauche à droite (attention, le '|' n'est pas
(qu')un opérateur de redirection). On le refait au ralenti:
Dans cmd > file 2>&1
Au départ:
fd1 (stdout) associé au terminal
fd2 (stderr) associé au terminal
puis, après "> file"
fd1 (stdout) associé au fichier "file"
fd2 (stderr) pas changé (terminal)
pui, après "2>&1"
fd1 (stdout) pas changé ("file")
fd2 (stderr) associé à la même chose que 1 (&1), c'est à dire
"file" [internally au moyen d'une dupplication de fd, ce qui
fait qu'un seul curseur sur le fichier est partagé pour les fd 1
et 2].
Si ça avait été lu à l'envers, on aurait eu: fd2 associé à la
même chose que 1 (terminal), puis fd 1 associé (re-affecté, ça
n'influe pas sur ce sur quoi est ouvert le fd 2) au fichier
"file".
si je comprends bien, bash évalues les redirections de droite à gauche ?
??? Ben non, de gauche à droite (attention, le '|' n'est pas (qu')un opérateur de redirection). On le refait au ralenti:
Dans cmd > file 2>&1
Au départ: fd1 (stdout) associé au terminal fd2 (stderr) associé au terminal
puis, après "> file" fd1 (stdout) associé au fichier "file" fd2 (stderr) pas changé (terminal)
pui, après "2>&1" fd1 (stdout) pas changé ("file") fd2 (stderr) associé à la même chose que 1 (&1), c'est à dire "file" [internally au moyen d'une dupplication de fd, ce qui fait qu'un seul curseur sur le fichier est partagé pour les fd 1 et 2].
Si ça avait été lu à l'envers, on aurait eu: fd2 associé à la même chose que 1 (terminal), puis fd 1 associé (re-affecté, ça n'influe pas sur ce sur quoi est ouvert le fd 2) au fichier "file".
[...]
Si c'est ça, alors j'ai compris le principes :)
C'était pas ça.
Nicolas.MICHEL
Stephane Chazelas wrote:
pui, après "2>&1" fd1 (stdout) pas changé ("file") fd2 (stderr) associé à la même chose que 1 (&1), c'est à dire "file" [internally au moyen d'une dupplication de fd, ce qui fait qu'un seul curseur sur le fichier est partagé pour les fd 1 et 2].
ok, là je comprends mieux. 2>&1 envoie stderr (/dev/fd/2 chez moi) non-pas sur stdout, mais sur la même dirrection que lui. Il y a donc "deux flux" allant au même endroit, et non "un flux" contennant à la fois stdout et stderr.
Celà n'explique pas ce que fait le || dans ce cas : commande >/dev/null 2>&1 || autre commande mais je suppose qu'il dévie le flux d'erreur qui allait vers /dev/null pour le lire et l'envoyer ensuite là où il allait précédement, soit sur /dev/null ?
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
pui, après "2>&1"
fd1 (stdout) pas changé ("file")
fd2 (stderr) associé à la même chose que 1 (&1), c'est à dire
"file" [internally au moyen d'une dupplication de fd, ce qui
fait qu'un seul curseur sur le fichier est partagé pour les fd 1
et 2].
ok, là je comprends mieux.
2>&1 envoie stderr (/dev/fd/2 chez moi) non-pas sur stdout, mais sur la
même dirrection que lui. Il y a donc "deux flux" allant au même endroit,
et non "un flux" contennant à la fois stdout et stderr.
Celà n'explique pas ce que fait le || dans ce cas :
commande >/dev/null 2>&1 || autre commande
mais je suppose qu'il dévie le flux d'erreur qui allait vers /dev/null
pour le lire et l'envoyer ensuite là où il allait précédement, soit sur
/dev/null ?
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
pui, après "2>&1" fd1 (stdout) pas changé ("file") fd2 (stderr) associé à la même chose que 1 (&1), c'est à dire "file" [internally au moyen d'une dupplication de fd, ce qui fait qu'un seul curseur sur le fichier est partagé pour les fd 1 et 2].
ok, là je comprends mieux. 2>&1 envoie stderr (/dev/fd/2 chez moi) non-pas sur stdout, mais sur la même dirrection que lui. Il y a donc "deux flux" allant au même endroit, et non "un flux" contennant à la fois stdout et stderr.
Celà n'explique pas ce que fait le || dans ce cas : commande >/dev/null 2>&1 || autre commande mais je suppose qu'il dévie le flux d'erreur qui allait vers /dev/null pour le lire et l'envoyer ensuite là où il allait précédement, soit sur /dev/null ?
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Stephane Chazelas
2004-02-5, 16:54(+01), Nicolas MICHEL: [...]
Celà n'explique pas ce que fait le || dans ce cas : commande >/dev/null 2>&1 || autre commande [...]
Pour le coup, "||" n'a rien à voir avec un opérateur de redirection.
"> file 2>&1", c'est comme d'hab, (redirige stdout et stderr de cmd1 sur une ouverture en écriture de /dev/null)
"||", ça a rapport avec les codes de retour (l'exit status envoyé lors du exit(), et récupéré par le shell par un waitpid) pas les file descriptors.
cmd1 || cmd2
(deux commandes avec chacunes leurs redirections if any)
Le shell lance cmd1, attend qu'elle se termine, récupère son exit status. Et ssi ce exit status est différent de 0, alors il lance cmd2 (avec && c'est si exit status == 0). Attention, dans:
cmd1 || cmd2 && cmd3
faut lire
( cmd1 || cmd2 ) && cmd3
c.a.d. que si l'exit status de cmd1 est 0, cmd2 n'est pas lancé, mais cmd3 si (&& et || sont d'égale precedence).
Celà n'explique pas ce que fait le || dans ce cas :
commande >/dev/null 2>&1 || autre commande
[...]
Pour le coup, "||" n'a rien à voir avec un opérateur de
redirection.
"> file 2>&1", c'est comme d'hab, (redirige stdout et stderr de
cmd1 sur une ouverture en écriture de /dev/null)
"||", ça a rapport avec les codes de retour (l'exit status
envoyé lors du exit(), et récupéré par le shell par un waitpid)
pas les file descriptors.
cmd1 || cmd2
(deux commandes avec chacunes leurs redirections if any)
Le shell lance cmd1, attend qu'elle se termine, récupère son
exit status. Et ssi ce exit status est différent de 0, alors il
lance cmd2 (avec && c'est si exit status == 0). Attention, dans:
cmd1 || cmd2 && cmd3
faut lire
( cmd1 || cmd2 ) && cmd3
c.a.d. que si l'exit status de cmd1 est 0, cmd2 n'est pas lancé,
mais cmd3 si (&& et || sont d'égale precedence).
Celà n'explique pas ce que fait le || dans ce cas : commande >/dev/null 2>&1 || autre commande [...]
Pour le coup, "||" n'a rien à voir avec un opérateur de redirection.
"> file 2>&1", c'est comme d'hab, (redirige stdout et stderr de cmd1 sur une ouverture en écriture de /dev/null)
"||", ça a rapport avec les codes de retour (l'exit status envoyé lors du exit(), et récupéré par le shell par un waitpid) pas les file descriptors.
cmd1 || cmd2
(deux commandes avec chacunes leurs redirections if any)
Le shell lance cmd1, attend qu'elle se termine, récupère son exit status. Et ssi ce exit status est différent de 0, alors il lance cmd2 (avec && c'est si exit status == 0). Attention, dans:
cmd1 || cmd2 && cmd3
faut lire
( cmd1 || cmd2 ) && cmd3
c.a.d. que si l'exit status de cmd1 est 0, cmd2 n'est pas lancé, mais cmd3 si (&& et || sont d'égale precedence).
