Copie de la sortie standard dans un fichier

Le
Gloops
Bonjour tout le monde,

Voici une question que j'ai posée deux fois en même temps que d'autres
questions, à intervalle de temps assez espacé. Je vais voir si en la
posant séparément j'aurai plus de chance. Est-il possible, sous Windows
XP, en mode "ligne de commande", d'obtenir la sortie standard,
simultanément, à l'écran et dans un fichier (l'un étant copie de l'autre) ?

La première fois, en l'absence de réponse j'envisageais de me plonger
dans l'assembleur, c'est des trucs assez bateaux à faire avec ce genre
de joujou, si ce n'est que forcément on y passe un peu de temps.

Avant la deuxième fois, j'ai trouvé une piste plus élégante dans l'aide
de Windows XP, dans la matière de duplicateurs de handles de fichiers
(dans la doc des batchs), mais je n'ai pas trouvé la syntaxe exacte,
donc peut-être faut-il y appliquer une astuce.

Le critère pour avoir la réponse peut être simplement d'arriver le jour
où celui qui sait vient lire
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
Pierre TORRIS
Le #1380054
Gloops
Bonjour tout le monde,

Voici une question que j'ai posée deux fois en même temps que d'autres
questions, à intervalle de temps assez espacé. Je vais voir si en la posant
séparément j'aurai plus de chance. Est-il possible, sous Windows XP, en mode
"ligne de commande", d'obtenir la sortie standard, simultanément, à l'écran
et dans un fichier (l'un étant copie de l'autre) ?

La première fois, en l'absence de réponse j'envisageais de me plonger dans
l'assembleur, c'est des trucs assez bateaux à faire avec ce genre de joujou,
si ce n'est que forcément on y passe un peu de temps.

Avant la deuxième fois, j'ai trouvé une piste plus élégante dans l'aide de
Windows XP, dans la matière de duplicateurs de handles de fichiers (dans la
doc des batchs), mais je n'ai pas trouvé la syntaxe exacte, donc peut-être
faut-il y appliquer une astuce.

Le critère pour avoir la réponse peut être simplement d'arriver le jour où
celui qui sait vient lire ...


Bonjour,

Faire une redirection dans un fichier suivi de son affichage écran. ;-)
Ceci fonctionne : dir > filetemp.txt & type filetemp.txt

Mis dans un .CMD appelé "go.cmd" donne la syntaxe allégée : go dir

Le soucis en cas de redirection dans un fichier destiné à être lu sous
Windows étant que le jeu de caractères n'est pas le même. L'affichage à
l'écran sera correct, mais l'affichage du fichier sous Windows
n'affichera pas certains caractères (les accents par exemple).

Classiquement, on peut obtenir les caractères corrects dans le fichier
en changeant la page de codes avec la commande CHCP, mais ici, si le
fichier sera correctement créé, l'affichage écran ne le sera plus
(puisque nous relisons ce fichier vers la console) !

Dans ces conditions, opérons un double changement de pages. ;-)
Et profitons-en pour supprimer le texte affiché de la cmd CHCP.

Exemple (avec changements page de codes & paramètres possibles) :

---------- --------- --------- --------- --------- ----------
@Echo OFF
chcp 1252 > nul
%1 %2 %3 %4 %5 > filetemp.txt & chcp 850 > nul & type filetemp.txt
---------- --------- --------- --------- --------- ----------

--
Bien à vous. Pierre TORRIS

E-mail : - Internet : http://www.ptorris.com
[Nombreux logiciels gratuits de l'auteur pour Win9x-Me-NT-2000-XP]

Gloops
Le #1380044
Salut Pierre,

Oui, c'est vrai que faire l'un après l'autre est bien plus simple que
les deux à la fois. Pour la liste des fichiers d'un répertoire, c'est
d'ailleurs ce que je fais habituellement.

Ce que je vise, c'est le suivi de ma sauvegarde sous XCOPY, donc savoir
en direct ce qui s'inscrit peut donner une idée du temps qui reste à
attendre, alors que si je ne l'affiche qu'à la fin, bien entendu, je
perds cet avantage.

C'est pour ça que j'avais d'abord envisagé le principe du filtre, qui
teste le type de support de la sortie standard, et qui si c'est un
fichier met une copie en sortie d'erreur. Pour la fin de programme il y
a plusieurs solutions, dont le caractère-clef, ou le dépassement de
temps. Seul inconvénient, il me faudrait bien quelques jours pour mettre
ça au point.

Quand j'ai vu que sous Windows XP on pouvait dupliquer les handles, je
me suis dit qu'il devait y avoir radicalement plus simple comme solution
pour faire la même chose, mais à condition de trouver exactement la
bonne syntaxe.

C'est vrai qu'on peut envisager le problème sous un autre angle et se
dire qu'il y a d'autres solutions de sauvegarde, comme Robocopy par
exemple (malgré sa fâcheuse tendance à se mettre en icône quand on le
lance, ce qui fait qu'on ne voit rien de ce qui se passe, ce qui le sort
finalement du champ de réponse à la question -mais j'ai peut-être mal
épluché les options), et probablement d'autres (d'ailleurs j'avais mis
la main à la pâte). A la limite on peut gérer les deux problèmes
séparément, pour le cas où la copie dans un fichier de ce qui passe à
l'écran pourrait servir à une autre occasion -ce qui ne paraît pas
exclus, on peut par exemple penser à un pilote de matériel d'analyse,
qui pour simplifier son développement enverrait ses résultats simplement
à la sortie standard.

Ah mais ça fait tilt, tout-à-coup : peut-être n'ai-je pas fait la bonne
recherche, si ça se trouve c'est un logiciel de capture de fenêtre qui
serait capable de faire ça. Enfin il faut vérifier, vu que d'habitude,
une capture de fenêtre obtient ce qui apparaît à l'écran, alors que dans
une fenêtre de lignes de commandes, on peut faire un défilement.
____________________________________________
Bonjour,

Faire une redirection dans un fichier suivi de son affichage écran. ;-)
Ceci fonctionne : dir > filetemp.txt & type filetemp.txt

Mis dans un .CMD appelé "go.cmd" donne la syntaxe allégée : go dir


Si je te suis bien, dans go.cmd, tu envisages de mettre
%1 >filetemp.txt & type filetemp.txt

(sous réserve de vérifier que dans un fichier de commande il n'y a pas
lieu de doubler le signe &)


Le soucis en cas de redirection dans un fichier destiné à être lu sous
Windows étant que le jeu de caractères n'est pas le même. L'affichage à
l'écran sera correct, mais l'affichage du fichier sous Windows
n'affichera pas certains caractères (les accents par exemple).

Classiquement, on peut obtenir les caractères corrects dans le fichier
en changeant la page de codes avec la commande CHCP, mais ici, si le
fichier sera correctement créé, l'affichage écran ne le sera plus
(puisque nous relisons ce fichier vers la console) !

Dans ces conditions, opérons un double changement de pages. ;-)
Et profitons-en pour supprimer le texte affiché de la cmd CHCP.

Exemple (avec changements page de codes & paramètres possibles) :

---------- --------- --------- --------- --------- ----------
@Echo OFF
chcp 1252 > nul
%1 %2 %3 %4 %5 > filetemp.txt & chcp 850 > nul & type filetemp.txt
---------- --------- --------- --------- --------- ----------



Pierre TORRIS
Le #1379904
Gloops
Salut Pierre,

Oui, c'est vrai que faire l'un après l'autre est bien plus simple que les
deux à la fois. Pour la liste des fichiers d'un répertoire, c'est d'ailleurs
ce que je fais habituellement.

Ce que je vise, c'est le suivi de ma sauvegarde sous XCOPY, donc savoir en
direct ce qui s'inscrit peut donner une idée du temps qui reste à attendre,
alors que si je ne l'affiche qu'à la fin, bien entendu, je perds cet
avantage.

... bla-bla-bla :-)


Bonjour,

Le mieux quand on recherche quelque chose, c'est encore de l'exprimer
entièrement, n'est-il pas ! :-)

Donc, si j'ai bien compris, tu utilises XCOPY en redirigeant la sortie
vers un fichier, et de ce fait, tu ne vois plus ce qui se passe sur
l'écran. Ma solution ne te convient pas ici, car ton XCOPY dure un
certain temps, voire un temps certain, et tu ne sais donc pas où il en
est et ce qu'il fabrique, ... et cela t'agace profondément. lool

Tu veux donc continuer à voir ce qui se passe sur l'écran, mais aussi
obtenir un fichier log qui aura tracé toutes les opérations. Est-ce
bien cela ?

Si affirmatif, et sans rechercher plus avant, ni savoir si un outil
existerait déjà, j'ai "pondu" une 'p'tite' appli nommé "cmdlog" (50
Ko). A utiliser sous la ligne de commandes. Elle est capable
d'intercepter l'entrée et de la renvoyer, tout en l'enregistrant au
passage, le tout en temps réel.

En pratique, un XCOPY (par exemple) continue d'afficher ses
informations de copie sur l'écran, tandis qu'un fichier log reçoit
exactement le même contenu (en temps réel également).

Pour obtenir l'aide, tapez : cmdlog /?

C:temp>cmdlog /?
CMDLOG v1.0 Copyright © 2006 Pierre TORRIS
Crée un fichier (log) de l'entrée standard

Syntaxe : cmd [params] | cmdlog [filename]

cmd : commande à exécuter
params : paramètres classiques de la commande
filename : nom du fichier à créer (défaut : cmdlog.log)

Exemples : dir | cmdlog
xcopy *.* x:backup | cmdlog "backup log.txt"

NB : la commande s'affranchie automatiquement des jeux de caractères.
L'écran conserve son affichage et le fichier est codé ANSI (Windows).

PS : je n'ai pas poussé plus loin ni effectué mille tests. A priori,
cela fonctionne très bien. A tester donc et à rendre compte. MERCI. :-)

Ben oui, ... il faudrait quand même que je donne un petit lien :
http://www.ptorris.com/cgi-bin/download.pl?cmdlog.zip

--
Bien à vous. Pierre TORRIS

E-mail : - Internet : http://www.ptorris.com
[Nombreux logiciels gratuits de l'auteur pour Win9x-Me-NT-2000-XP]

Gloops
Le #1379898
Eh bien en effet, ça m'a tout-à-fait l'air d'être ça !

Pour que tu aies quelque chose qui réponde si bien à la question et que
tu aies eu tant de mal à la comprendre, c'est qu'elle devait être bien
mal formulée en effet ;)

Je me demande bien comment tu aurais dit ...

Merci.
____________________________________________

Bonjour,

Le mieux quand on recherche quelque chose, c'est encore de l'exprimer
entièrement, n'est-il pas ! :-)

Donc, si j'ai bien compris, tu utilises XCOPY en redirigeant la sortie
vers un fichier, et de ce fait, tu ne vois plus ce qui se passe sur
l'écran. Ma solution ne te convient pas ici, car ton XCOPY dure un
certain temps, voire un temps certain, et tu ne sais donc pas où il en
est et ce qu'il fabrique, ... et cela t'agace profondément. lool

Tu veux donc continuer à voir ce qui se passe sur l'écran, mais aussi
obtenir un fichier log qui aura tracé toutes les opérations. Est-ce bien
cela ?

Si affirmatif, et sans rechercher plus avant, ni savoir si un outil
existerait déjà, j'ai "pondu" une 'p'tite' appli nommé "cmdlog" (50 Ko).
A utiliser sous la ligne de commandes. Elle est capable d'intercepter
l'entrée et de la renvoyer, tout en l'enregistrant au passage, le tout
en temps réel.

En pratique, un XCOPY (par exemple) continue d'afficher ses informations
de copie sur l'écran, tandis qu'un fichier log reçoit exactement le même
contenu (en temps réel également).

Pour obtenir l'aide, tapez : cmdlog /?

C:temp>cmdlog /?
CMDLOG v1.0 Copyright © 2006 Pierre TORRIS
Crée un fichier (log) de l'entrée standard

Syntaxe : cmd [params] | cmdlog [filename]

cmd : commande à exécuter
params : paramètres classiques de la commande
filename : nom du fichier à créer (défaut : cmdlog.log)

Exemples : dir | cmdlog
xcopy *.* x:backup | cmdlog "backup log.txt"

NB : la commande s'affranchie automatiquement des jeux de caractères.
L'écran conserve son affichage et le fichier est codé ANSI (Windows).

PS : je n'ai pas poussé plus loin ni effectué mille tests. A priori,
cela fonctionne très bien. A tester donc et à rendre compte. MERCI. :-)

Ben oui, ... il faudrait quand même que je donne un petit lien :
http://www.ptorris.com/cgi-bin/download.pl?cmdlog.zip



Pierre TORRIS
Le #1379870
Gloops
Eh bien en effet, ça m'a tout-à-fait l'air d'être ça !


;-)

Pour que tu aies quelque chose qui réponde si bien à la question...


Faut dire que le "quelque chose" a quand même été conçu cette fin d'APM
en 3 neurones et 4 réflexions pour TA cause (et par extension à plein
d'autres). :-)

et que tu
aies eu tant de mal à la comprendre, c'est qu'elle devait être bien mal
formulée en effet ;)


En fait, je crois que j'avais quand même bien compris (avec du mal
c'est vrai - sisi © lool). Ma première solution fonctionne très bien.
Je ne pouvais pas savoir qu'il s'agissait plutôt d'un 'long'
traitement... Pour la suite, je te faisais un peu marcher, histoire que
je comprenne vraiment bien ... :-)

Je me demande bien comment tu aurais dit ...


Heu... ben... Voyons, un truc court... du genre, heu... :

Je fais un XCOPY en redirigeant la sortie vers un fichier, mais
j'aimerais également obtenir la sortie standard. Est-ce bin possible ?

Et la réponse : NON NON, c'est pas possible ! Faut choisir m'enfin !
Et Gloops : SI SI, c'est parfaitement possible, avec le cmdlog de pT.

:-)

--
Bien à vous. Pierre TORRIS

E-mail : - Internet : http://www.ptorris.com
[Nombreux logiciels gratuits de l'auteur pour Win9x-Me-NT-2000-XP]

Gloops
Le #1379845

Faut dire que le "quelque chose" a quand même été conçu cette fin d'APM
en 3 neurones et 4 réflexions pour TA cause (et par extension à plein
d'autres). :-)



Ah, tu es en train de laisser entendre que tu programmes plus vite que
moi ...

Bon, ça doit bien exister ...
C'est vrai que le langage qui va bien, je n'y ai plus touché depuis au
moins dix ans.

Daniel92
Le #1379497
*Pierre TORRIS* écrit dans
http://groups.google.com/groups?threadm=mn.ac297d66b0ff9e34.35147%40ptorris.com

|
| chcp 1252 > nul
|

Merci, ... j'avais la flemme de chercher comment faire
disparaître la réponse écran à l'utilisation de chcp .

Daniel92 .
Gloops
Le #1379361
*Pierre TORRIS* écrit dans
http://groups.google.com/groups?threadm=mn.ac297d66b0ff9e34.35147%40ptorris.com

|
| chcp 1252 > nul
|

Merci, ... j'avais la flemme de chercher comment faire
disparaître la réponse écran à l'utilisation de chcp .


:)


Daniel92 .




Sabrem JORAM
Le #1377236
*Pierre TORRIS* écrit dans
http://groups.google.com/groups?threadm=mn.ac297d66b0ff9e34.35147%40ptorris.com


chcp 1252 > nul



Merci, ... j'avais la flemme de chercher comment faire
disparaître la réponse écran à l'utilisation de chcp .

Daniel92 .


Salut Daniel,

Tu es demandé :

http://groups.google.com/groups?as_umsgid=ubzsnhpngha.1592%40tk2msftngp04.phx.gbl

Merci.

Amicalement,

Pascal.

--
... S.J. alias Pascal MONNOURY [MVP Windows-Shell/ User 2006]

Si F1 t'a pas aidé, si Gougueule t'a méprisé, tu peux sur ces forums ta
question alors poser :-)


Poster une réponse
Anonyme