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 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 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
---------- --------- --------- --------- --------- ----------
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
---------- --------- --------- --------- --------- ----------
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
---------- --------- --------- --------- --------- ----------
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 :-)
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 :-)
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
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
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
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 ...
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 ...
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 ...
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). :-)
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). :-)
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). :-)
*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 .
*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 .
*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 .
*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 .
*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 .
*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 .