Lorsque je crée un fichier par une commande du type:
echo toto>toto.txt
Le fichier toto.txt généré contient 2 lignes, la redirection ajoutant un
retour chariot après le mot toto. comment faire pour que ce retour chariot
ne soit pas généré?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jacques Barathon [MS]
"Yannick ROGER" wrote in message news:
bonjour
Lorsque je crée un fichier par une commande du type: echo toto>toto.txt Le fichier toto.txt généré contient 2 lignes, la redirection ajoutant un retour chariot après le mot toto. comment faire pour que ce retour chariot ne soit pas généré?
Je ne suis pas sûr de comprendre ce qui pose problème. L'exemple suivant montre qu'aucun retour chariot n'est généré à part celui marquant un retour à la ligne après chaque mot:
---début--- C:test>echo toto>liste.txt
C:test>type liste.txt toto
C:test>echo titi>>liste.txt
C:test>type liste.txt toto titi
C:test> ---fin---
Jacques
"Yannick ROGER" <yroger@sqli.com> wrote in message
news:u2cizap9FHA.500@TK2MSFTNGP15.phx.gbl...
bonjour
Lorsque je crée un fichier par une commande du type:
echo toto>toto.txt
Le fichier toto.txt généré contient 2 lignes, la redirection ajoutant un
retour chariot après le mot toto. comment faire pour que ce retour chariot
ne soit pas généré?
Je ne suis pas sûr de comprendre ce qui pose problème. L'exemple suivant
montre qu'aucun retour chariot n'est généré à part celui marquant un retour
à la ligne après chaque mot:
Lorsque je crée un fichier par une commande du type: echo toto>toto.txt Le fichier toto.txt généré contient 2 lignes, la redirection ajoutant un retour chariot après le mot toto. comment faire pour que ce retour chariot ne soit pas généré?
Je ne suis pas sûr de comprendre ce qui pose problème. L'exemple suivant montre qu'aucun retour chariot n'est généré à part celui marquant un retour à la ligne après chaque mot:
---début--- C:test>echo toto>liste.txt
C:test>type liste.txt toto
C:test>echo titi>>liste.txt
C:test>type liste.txt toto titi
C:test> ---fin---
Jacques
Yannick ROGER
Ce qui pose problème est lorsque vous faites type liste.txt le retour est: --debut toto
C: --fin au lieu de --debut toto C: --fin ou encore, quand vous ouvrez le fichier sous notepad, il existe une 2e ligne de créée (le curseur est positionnable à la fin du fichier "en dessous" de toto au lieu de ne pouvoir aller qu'après toto.
Exactement mon soucis n'est pas celui-ci exactement mais c'est pour contourner un autre problème que je fais cela, peut-être avez-vous une solution pour la source du problème. Je veux créer des fichier de checksum md5 sur des fichiers qui seront transférés sur une machine unix et vérifiés à ce moment-là, hors tous les calculateurs md5 (md5sum, fmd5..) que j'ai trouvé ne formate pas leur sortie comme celui sous unix. Donc lorsque j'essaie de vérifier l'exactitude du fichier tranféré, il me détecte une erreur. Voici la cinématique exacte. Sur Windows, j'ai un fichier toto.zip Je fait un md5sum de ce fichier md5sum toto.zip > toto.md5 Le toto.md5 contient ceci: --debut da412c3babad7f7400110bc855c6e86e *toto.zip
--fin Je transfert par ftp ces 2 fichiers toto.zip et toto.md5 sur un serveur unix. Sur le serveur unix je vérifie la validité du fichier transféré par: md5sum -c toto.md5 Et il me retourne que le fichier toto.md5 ne contient aucun élément La génération de toto.md5 sur unix me retourne: --debut da412c3babad7f7400110bc855c6e86e toto.zip --fin La différence de formatage est pour moi responsable de l'echec du check md5 sur mon serveur unix. En effet, lorsque je modifie sur Windows le fichier toto.md5 avec notepad en remplaçant "*" par " " et en supprimant la ligne que rajoute Windows le checksum sur unix fonctionne très bien. Je suis parvenu à retraiter le problème de "*" avant le nom du fichier par: for /f "eol=*" %%i in ('md5sum toto.zip') do echo %%i toto.zip>toto.md5 Le fichier résultant est: --debut da412c3babad7f7400110bc855c6e86e toto.zip
--fin Il me reste simplement le souci du retour chariot.
"Jacques Barathon [MS]" a écrit dans le message de news:
"Yannick ROGER" wrote in message news:
bonjour
Lorsque je crée un fichier par une commande du type: echo toto>toto.txt Le fichier toto.txt généré contient 2 lignes, la redirection ajoutant un retour chariot après le mot toto. comment faire pour que ce retour chariot
ne soit pas généré?
Je ne suis pas sûr de comprendre ce qui pose problème. L'exemple suivant montre qu'aucun retour chariot n'est généré à part celui marquant un retour
à la ligne après chaque mot:
---début--- C:test>echo toto>liste.txt
C:test>type liste.txt toto
C:test>echo titi>>liste.txt
C:test>type liste.txt toto titi
C:test> ---fin---
Jacques
Ce qui pose problème est lorsque vous faites type liste.txt le retour est:
--debut
toto
C:
--fin
au lieu de
--debut
toto
C:
--fin
ou encore, quand vous ouvrez le fichier sous notepad, il existe une 2e ligne
de créée (le curseur est positionnable à la fin du fichier "en dessous" de
toto au lieu de ne pouvoir aller qu'après toto.
Exactement mon soucis n'est pas celui-ci exactement mais c'est pour
contourner un autre problème que je fais cela, peut-être avez-vous une
solution pour la source du problème.
Je veux créer des fichier de checksum md5 sur des fichiers qui seront
transférés sur une machine unix et vérifiés à ce moment-là, hors tous les
calculateurs md5 (md5sum, fmd5..) que j'ai trouvé ne formate pas leur sortie
comme celui sous unix. Donc lorsque j'essaie de vérifier l'exactitude du
fichier tranféré, il me détecte une erreur. Voici la cinématique exacte.
Sur Windows, j'ai un fichier toto.zip
Je fait un md5sum de ce fichier
md5sum toto.zip > toto.md5
Le toto.md5 contient ceci:
--debut
da412c3babad7f7400110bc855c6e86e *toto.zip
--fin
Je transfert par ftp ces 2 fichiers toto.zip et toto.md5 sur un serveur
unix.
Sur le serveur unix je vérifie la validité du fichier transféré par:
md5sum -c toto.md5
Et il me retourne que le fichier toto.md5 ne contient aucun élément
La génération de toto.md5 sur unix me retourne:
--debut
da412c3babad7f7400110bc855c6e86e toto.zip
--fin
La différence de formatage est pour moi responsable de l'echec du check md5
sur mon serveur unix. En effet, lorsque je modifie sur Windows le fichier
toto.md5 avec notepad en remplaçant "*" par " " et en supprimant la ligne
que rajoute Windows le checksum sur unix fonctionne très bien.
Je suis parvenu à retraiter le problème de "*" avant le nom du fichier par:
for /f "eol=*" %%i in ('md5sum toto.zip') do echo %%i toto.zip>toto.md5
Le fichier résultant est:
--debut
da412c3babad7f7400110bc855c6e86e toto.zip
--fin
Il me reste simplement le souci du retour chariot.
"Jacques Barathon [MS]" <jbaratho@online.microsoft.com> a écrit dans le
message de news:e2IypLw9FHA.3308@TK2MSFTNGP11.phx.gbl...
"Yannick ROGER" <yroger@sqli.com> wrote in message
news:u2cizap9FHA.500@TK2MSFTNGP15.phx.gbl...
bonjour
Lorsque je crée un fichier par une commande du type:
echo toto>toto.txt
Le fichier toto.txt généré contient 2 lignes, la redirection ajoutant un
retour chariot après le mot toto. comment faire pour que ce retour
chariot
ne soit pas généré?
Je ne suis pas sûr de comprendre ce qui pose problème. L'exemple suivant
montre qu'aucun retour chariot n'est généré à part celui marquant un
retour
Ce qui pose problème est lorsque vous faites type liste.txt le retour est: --debut toto
C: --fin au lieu de --debut toto C: --fin ou encore, quand vous ouvrez le fichier sous notepad, il existe une 2e ligne de créée (le curseur est positionnable à la fin du fichier "en dessous" de toto au lieu de ne pouvoir aller qu'après toto.
Exactement mon soucis n'est pas celui-ci exactement mais c'est pour contourner un autre problème que je fais cela, peut-être avez-vous une solution pour la source du problème. Je veux créer des fichier de checksum md5 sur des fichiers qui seront transférés sur une machine unix et vérifiés à ce moment-là, hors tous les calculateurs md5 (md5sum, fmd5..) que j'ai trouvé ne formate pas leur sortie comme celui sous unix. Donc lorsque j'essaie de vérifier l'exactitude du fichier tranféré, il me détecte une erreur. Voici la cinématique exacte. Sur Windows, j'ai un fichier toto.zip Je fait un md5sum de ce fichier md5sum toto.zip > toto.md5 Le toto.md5 contient ceci: --debut da412c3babad7f7400110bc855c6e86e *toto.zip
--fin Je transfert par ftp ces 2 fichiers toto.zip et toto.md5 sur un serveur unix. Sur le serveur unix je vérifie la validité du fichier transféré par: md5sum -c toto.md5 Et il me retourne que le fichier toto.md5 ne contient aucun élément La génération de toto.md5 sur unix me retourne: --debut da412c3babad7f7400110bc855c6e86e toto.zip --fin La différence de formatage est pour moi responsable de l'echec du check md5 sur mon serveur unix. En effet, lorsque je modifie sur Windows le fichier toto.md5 avec notepad en remplaçant "*" par " " et en supprimant la ligne que rajoute Windows le checksum sur unix fonctionne très bien. Je suis parvenu à retraiter le problème de "*" avant le nom du fichier par: for /f "eol=*" %%i in ('md5sum toto.zip') do echo %%i toto.zip>toto.md5 Le fichier résultant est: --debut da412c3babad7f7400110bc855c6e86e toto.zip
--fin Il me reste simplement le souci du retour chariot.
"Jacques Barathon [MS]" a écrit dans le message de news:
"Yannick ROGER" wrote in message news:
bonjour
Lorsque je crée un fichier par une commande du type: echo toto>toto.txt Le fichier toto.txt généré contient 2 lignes, la redirection ajoutant un retour chariot après le mot toto. comment faire pour que ce retour chariot
ne soit pas généré?
Je ne suis pas sûr de comprendre ce qui pose problème. L'exemple suivant montre qu'aucun retour chariot n'est généré à part celui marquant un retour
à la ligne après chaque mot:
---début--- C:test>echo toto>liste.txt
C:test>type liste.txt toto
C:test>echo titi>>liste.txt
C:test>type liste.txt toto titi
C:test> ---fin---
Jacques
Sebastian
Yannick ROGER wrote:
echo toto>toto.txt Le fichier toto.txt généré contient 2 lignes, la redirection ajoutant un retour chariot après le mot toto. comment faire pour que ce retour chariot ne soit pas généré?
bonjour,
ça doit fonctionner avec la commande echo de CoreUtils for Windows. http://gnuwin32.sourceforge.net/packages/coreutils.htm tenez nous informé. -- Sebastian pourquoi faire windows quand on peut faire simple ?
Yannick ROGER wrote:
echo toto>toto.txt
Le fichier toto.txt généré contient 2 lignes, la redirection ajoutant un
retour chariot après le mot toto. comment faire pour que ce retour chariot
ne soit pas généré?
bonjour,
ça doit fonctionner avec la commande echo de CoreUtils for Windows.
http://gnuwin32.sourceforge.net/packages/coreutils.htm
tenez nous informé.
--
Sebastian
pourquoi faire windows quand on peut faire simple ?
echo toto>toto.txt Le fichier toto.txt généré contient 2 lignes, la redirection ajoutant un retour chariot après le mot toto. comment faire pour que ce retour chariot ne soit pas généré?
bonjour,
ça doit fonctionner avec la commande echo de CoreUtils for Windows. http://gnuwin32.sourceforge.net/packages/coreutils.htm tenez nous informé. -- Sebastian pourquoi faire windows quand on peut faire simple ?
Yannick ROGER
Merci pour votre proposition, malheureusement le echo livré se comporte de la même façon que celui de Windows, il incère un retour chariot après l'entrée.
"Sebastian" a écrit dans le message de news:43902b8e$0$6683$
Yannick ROGER wrote:
echo toto>toto.txt Le fichier toto.txt généré contient 2 lignes, la redirection ajoutant un retour chariot après le mot toto. comment faire pour que ce retour chariot
ne soit pas généré?
bonjour,
ça doit fonctionner avec la commande echo de CoreUtils for Windows. http://gnuwin32.sourceforge.net/packages/coreutils.htm tenez nous informé. -- Sebastian pourquoi faire windows quand on peut faire simple ?
Merci pour votre proposition, malheureusement le echo livré se comporte de
la même façon que celui de Windows, il incère un retour chariot après
l'entrée.
"Sebastian" <sebastian.nospam.guillet@laposte.net> a écrit dans le message
de news:43902b8e$0$6683$8fcfb975@news.wanadoo.fr...
Yannick ROGER wrote:
echo toto>toto.txt
Le fichier toto.txt généré contient 2 lignes, la redirection ajoutant un
retour chariot après le mot toto. comment faire pour que ce retour
chariot
ne soit pas généré?
bonjour,
ça doit fonctionner avec la commande echo de CoreUtils for Windows.
http://gnuwin32.sourceforge.net/packages/coreutils.htm
tenez nous informé.
--
Sebastian
pourquoi faire windows quand on peut faire simple ?
Merci pour votre proposition, malheureusement le echo livré se comporte de la même façon que celui de Windows, il incère un retour chariot après l'entrée.
"Sebastian" a écrit dans le message de news:43902b8e$0$6683$
Yannick ROGER wrote:
echo toto>toto.txt Le fichier toto.txt généré contient 2 lignes, la redirection ajoutant un retour chariot après le mot toto. comment faire pour que ce retour chariot
ne soit pas généré?
bonjour,
ça doit fonctionner avec la commande echo de CoreUtils for Windows. http://gnuwin32.sourceforge.net/packages/coreutils.htm tenez nous informé. -- Sebastian pourquoi faire windows quand on peut faire simple ?
Sebastian
Yannick ROGER wrote:
Merci pour votre proposition, malheureusement le echo livré se comporte de la même façon que celui de Windows, il incère un retour chariot après l'entrée.
m'enfin, elle fonctionne très bien cette commande.
---------------------------------------------------- Usage: echo.exe [OPTION]... [STRING]... Echo the STRING(s) to standard output. -n do not output the trailing newline ----------------------------------------------------
qu'est-ce qui ne va pas ?
Yannick ROGER wrote:
Merci pour votre proposition, malheureusement le echo livré se comporte de
la même façon que celui de Windows, il incère un retour chariot après
l'entrée.
m'enfin, elle fonctionne très bien cette commande.
----------------------------------------------------
Usage: echo.exe [OPTION]... [STRING]...
Echo the STRING(s) to standard output.
-n do not output the trailing newline
----------------------------------------------------
Merci pour votre proposition, malheureusement le echo livré se comporte de la même façon que celui de Windows, il incère un retour chariot après l'entrée.
m'enfin, elle fonctionne très bien cette commande.
---------------------------------------------------- Usage: echo.exe [OPTION]... [STRING]... Echo the STRING(s) to standard output. -n do not output the trailing newline ----------------------------------------------------
qu'est-ce qui ne va pas ?
Jacques Barathon [MS]
"Yannick ROGER" wrote in message news:
Ce qui pose problème est lorsque vous faites type liste.txt le retour est: --debut toto
C: --fin au lieu de --debut toto C: --fin ou encore, quand vous ouvrez le fichier sous notepad, il existe une 2e ligne de créée (le curseur est positionnable à la fin du fichier "en dessous" de toto au lieu de ne pouvoir aller qu'après toto.
Ah ok, je vois. La commande "echo -n" dispo sur le site mentionné par Sebastian devrait résoudre ce problème.
<snip>
La différence de formatage est pour moi responsable de l'echec du check md5 sur mon serveur unix. En effet, lorsque je modifie sur Windows le fichier toto.md5 avec notepad en remplaçant "*" par " " et en supprimant la ligne que rajoute Windows le checksum sur unix fonctionne très bien. Je suis parvenu à retraiter le problème de "*" avant le nom du fichier par: for /f "eol=*" %%i in ('md5sum toto.zip') do echo %%i toto.zip>toto.md5 Le fichier résultant est: --debut da412c3babad7f7400110bc855c6e86e toto.zip
--fin
L'astérisque signale une lecture du fichier en mode binaire. Essaie "md5sum -t" pour forcer la lecture en mode texte, ça générera un checksum au format compatible avec celui d'Unix.
Il me reste simplement le souci du retour chariot.
Si la commande "echo -n" de Sebastian ne marche pas, vérifie avec un éditeur hexa sous Unix si un retour chariot est inséré après le checksum. Il pourrait alors s'agir d'un problème de compatibilité entre la façon dont le retour chariot est codé sur les deux plateformes: CR-LF sous Windows (0x0D, 0x0A) et LF uniquement sous Unix (0x0A). Je n'ai pas de solution à ce problème, il doit exister des outils de conversion mais je ne pratique pas, désolé...
Jacques
"Yannick ROGER" <yroger@sqli.com> wrote in message
news:OfS491x9FHA.3608@TK2MSFTNGP09.phx.gbl...
Ce qui pose problème est lorsque vous faites type liste.txt le retour est:
--debut
toto
C:
--fin
au lieu de
--debut
toto
C:
--fin
ou encore, quand vous ouvrez le fichier sous notepad, il existe une 2e
ligne
de créée (le curseur est positionnable à la fin du fichier "en dessous" de
toto au lieu de ne pouvoir aller qu'après toto.
Ah ok, je vois. La commande "echo -n" dispo sur le site mentionné par
Sebastian devrait résoudre ce problème.
<snip>
La différence de formatage est pour moi responsable de l'echec du check
md5
sur mon serveur unix. En effet, lorsque je modifie sur Windows le fichier
toto.md5 avec notepad en remplaçant "*" par " " et en supprimant la ligne
que rajoute Windows le checksum sur unix fonctionne très bien.
Je suis parvenu à retraiter le problème de "*" avant le nom du fichier
par:
for /f "eol=*" %%i in ('md5sum toto.zip') do echo %%i toto.zip>toto.md5
Le fichier résultant est:
--debut
da412c3babad7f7400110bc855c6e86e toto.zip
--fin
L'astérisque signale une lecture du fichier en mode binaire. Essaie
"md5sum -t" pour forcer la lecture en mode texte, ça générera un checksum au
format compatible avec celui d'Unix.
Il me reste simplement le souci du retour chariot.
Si la commande "echo -n" de Sebastian ne marche pas, vérifie avec un éditeur
hexa sous Unix si un retour chariot est inséré après le checksum. Il
pourrait alors s'agir d'un problème de compatibilité entre la façon dont le
retour chariot est codé sur les deux plateformes: CR-LF sous Windows (0x0D,
0x0A) et LF uniquement sous Unix (0x0A). Je n'ai pas de solution à ce
problème, il doit exister des outils de conversion mais je ne pratique pas,
désolé...
Ce qui pose problème est lorsque vous faites type liste.txt le retour est: --debut toto
C: --fin au lieu de --debut toto C: --fin ou encore, quand vous ouvrez le fichier sous notepad, il existe une 2e ligne de créée (le curseur est positionnable à la fin du fichier "en dessous" de toto au lieu de ne pouvoir aller qu'après toto.
Ah ok, je vois. La commande "echo -n" dispo sur le site mentionné par Sebastian devrait résoudre ce problème.
<snip>
La différence de formatage est pour moi responsable de l'echec du check md5 sur mon serveur unix. En effet, lorsque je modifie sur Windows le fichier toto.md5 avec notepad en remplaçant "*" par " " et en supprimant la ligne que rajoute Windows le checksum sur unix fonctionne très bien. Je suis parvenu à retraiter le problème de "*" avant le nom du fichier par: for /f "eol=*" %%i in ('md5sum toto.zip') do echo %%i toto.zip>toto.md5 Le fichier résultant est: --debut da412c3babad7f7400110bc855c6e86e toto.zip
--fin
L'astérisque signale une lecture du fichier en mode binaire. Essaie "md5sum -t" pour forcer la lecture en mode texte, ça générera un checksum au format compatible avec celui d'Unix.
Il me reste simplement le souci du retour chariot.
Si la commande "echo -n" de Sebastian ne marche pas, vérifie avec un éditeur hexa sous Unix si un retour chariot est inséré après le checksum. Il pourrait alors s'agir d'un problème de compatibilité entre la façon dont le retour chariot est codé sur les deux plateformes: CR-LF sous Windows (0x0D, 0x0A) et LF uniquement sous Unix (0x0A). Je n'ai pas de solution à ce problème, il doit exister des outils de conversion mais je ne pratique pas, désolé...
Jacques
Jacques Barathon [MS]
"Jacques Barathon [MS]" wrote in message news:uxhl%23A% <snip>
Si la commande "echo -n" de Sebastian ne marche pas, vérifie avec un éditeur hexa sous Unix si un retour chariot est inséré après le checksum. Il pourrait alors s'agir d'un problème de compatibilité entre la façon dont le retour chariot est codé sur les deux plateformes: CR-LF sous Windows (0x0D, 0x0A) et LF uniquement sous Unix (0x0A). Je n'ai pas de solution à ce problème, il doit exister des outils de conversion mais je ne pratique pas, désolé...
Je viens de voir qu'il existe un utilitaire en freeware qui fait la conversion: http://www.buchard.com/Dev.php?id_rubrique"
Jacques
"Jacques Barathon [MS]" <jbaratho@online.microsoft.com> wrote in message
news:uxhl%23A%239FHA.360@TK2MSFTNGP09.phx.gbl...
<snip>
Si la commande "echo -n" de Sebastian ne marche pas, vérifie avec un
éditeur hexa sous Unix si un retour chariot est inséré après le checksum.
Il pourrait alors s'agir d'un problème de compatibilité entre la façon
dont le retour chariot est codé sur les deux plateformes: CR-LF sous
Windows (0x0D, 0x0A) et LF uniquement sous Unix (0x0A). Je n'ai pas de
solution à ce problème, il doit exister des outils de conversion mais je
ne pratique pas, désolé...
Je viens de voir qu'il existe un utilitaire en freeware qui fait la
conversion:
http://www.buchard.com/Dev.php?id_rubrique"
"Jacques Barathon [MS]" wrote in message news:uxhl%23A% <snip>
Si la commande "echo -n" de Sebastian ne marche pas, vérifie avec un éditeur hexa sous Unix si un retour chariot est inséré après le checksum. Il pourrait alors s'agir d'un problème de compatibilité entre la façon dont le retour chariot est codé sur les deux plateformes: CR-LF sous Windows (0x0D, 0x0A) et LF uniquement sous Unix (0x0A). Je n'ai pas de solution à ce problème, il doit exister des outils de conversion mais je ne pratique pas, désolé...
Je viens de voir qu'il existe un utilitaire en freeware qui fait la conversion: http://www.buchard.com/Dev.php?id_rubrique"
Jacques
Ok, OK, RTFM!!! Je n'avais pas vu l'option -n
Merci
"Sebastian" a écrit dans le message de news: 43905072$0$6684$
Yannick ROGER wrote:
Merci pour votre proposition, malheureusement le echo livré se comporte de la même façon que celui de Windows, il incère un retour chariot après l'entrée.
m'enfin, elle fonctionne très bien cette commande.
---------------------------------------------------- Usage: echo.exe [OPTION]... [STRING]... Echo the STRING(s) to standard output. -n do not output the trailing newline ----------------------------------------------------
qu'est-ce qui ne va pas ?
Ok, OK, RTFM!!! Je n'avais pas vu l'option -n
Merci
"Sebastian" <sebastian.nospam.guillet@laposte.net> a écrit dans le message
de news: 43905072$0$6684$8fcfb975@news.wanadoo.fr...
Yannick ROGER wrote:
Merci pour votre proposition, malheureusement le echo livré se comporte
de
la même façon que celui de Windows, il incère un retour chariot après
l'entrée.
m'enfin, elle fonctionne très bien cette commande.
----------------------------------------------------
Usage: echo.exe [OPTION]... [STRING]...
Echo the STRING(s) to standard output.
-n do not output the trailing newline
----------------------------------------------------
"Sebastian" a écrit dans le message de news: 43905072$0$6684$
Yannick ROGER wrote:
Merci pour votre proposition, malheureusement le echo livré se comporte de la même façon que celui de Windows, il incère un retour chariot après l'entrée.
m'enfin, elle fonctionne très bien cette commande.
---------------------------------------------------- Usage: echo.exe [OPTION]... [STRING]... Echo the STRING(s) to standard output. -n do not output the trailing newline ----------------------------------------------------
