Discussion :

[BaygonV]

Bonjour,
J'ai réalisé un programme qui (ne fait pas que .... mais c'est la où se situe mon problème) copie un fichier texte (txt.from) caractère par caractère vers un fichier (txt.to).
Cette partie a très bien fonctionné tant que les textes originaux ont été "fabriqués" sous linux...
Par contre quand txt.from est fabriqué sous windows alors quand j'ouvre txt.to sous emacs il apparaît des ^M à chaque saut de ligne et le corps de txt.to tient du coup sur une seule et même ligne.
N.B. sous emacs toujours, l'édition de txt.from ne pose aucun problème de ce genre !
D'où une première question (Q1) à laquelle il me semble que j'ai une réponse partielle (H1) qui doit être incomplète car elle n'apporte pas de réponse aux questions suivantes.

Q1 : Comment expliquer ce comportement ?
H1 : Par la différence des formats de retour à la ligne entre linux ('\r') et windows ("\r\n").

Malheureusement H1 ne m'explique :

Q2 : Ni pourquoi j'ai un une différence de comportement entre l'édition de txt.from et txt.to, la copie se faisant caractère par caractère et (à priori) sans interprétation de ceux ci l'édition de ces deux fichiers devrait provoquer le même comportement...

Q3 : Ni pourquoi l'éditeur de texte de KDE (KWrite) ne pose aucun problème d'édition, que ce soit avec txt.fromou avec txt.to.

Je précise, même si je ne crois pas que ce soit important, que le programme qui effectue la copie tourne sous linux et que les fichiers txt.* proviennent d'une partition partagée avec windows.

Edit : Je suis absolument sûr que ca doit être une problèmatique ultra classique mais (pour l'instant) je ne trouve pas de requête google qui me conduise à autre chose que mon hypothèse H1.

[Bktero]

Les ^M vient en effet des retours à la ligne différents. J'ai souvent eu le problème avec Vim. Si un autre éditeur n'a pas de problème, c'est qu'il doit être capable de les gérer correctement.

Tes fichiers Windows possèdent un caractère en plus. Quand tu copies avec Linux, si tu copies caractère par caractère sans interprétation, alors tu reproduis ce caractère dans ton fichier de sortie. Et tu le vois quand tu l'ouvres.

[Médinoc]

Bonjour,

1. Au niveau des logiciels:
   
   • Emacs est connu pour pouvoir s'adapter aux retours à ligne provenant d'OS différents. C'est le cas pour d'autres éditeurs modernes comme Notepad++ ou Visual Studio.
   • Notepad et VI sont connus pour ne supporter que les retours à la ligne de leur OS.
2. Au niveau des traitements:
   
   • Le mode d'ouverture des fichiers (du moins, sous Windows) peut avoir une influence: Un fichier ouvert en mode binaire est lu et écrit tel quel, mais si un fichier est ouvert en mode texte, les \r suivis d'un \n sont sautés lors de la lecture (pour que le programme ne voie que des \n) et insérés lors de l'écriture.

Quels sont les modes d'ouverture utilisés par ton programme?

[BaygonV]

@Médinoc :
Voila les lignes de codes qui répondront à ta question, je dois dire que je fais du C par obligation et pour pouvoir lire les doc de flex et bison, quand j'en arriverai aux parties de ces docs me permettant d'utiliser du C++ je serai ravi de pouvoir faire les choses autrement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
// Ouverture du fichier de sortie : située dans un fichier de spec de bison
out = fopen(name_file_out,"w");
 
// Ouverture du fichier d'entrée : située dans un fichier de spec de flex
yyin = fopen(_name_file_in,"r");
 
// ailleurs dans le fichier de spec de flex figure la règle : 
. {fprintf(out,"%c", yytext[0]);} 
 
/* au cas où vous auriez oublié votre B.A.BA de flex :
* cette règle fait que le lexer généré par flex execute le code C situé entre { et } lorsqu'il tombe sur 
* un caractère ne matchant pas dans les règles précédentes.
*/

Par ailleurs, je compile et exécute mon programme (pas que) de recopie sous linux et lui fait traiter des fichiers piochés à droite et à gauche, venant du monde windows, linux, (pas encore mac mais c est l'idée à terme)...

C'est justement le fait qu emacs s'adapte à un de mes fichiers et pas à l'autre qui me fait m'alerter puisque moralement ces fichiers sont censés être les même.

[ternel]

Sous unix/linux, il y a des programmes dos2unix et unix2dos pour contourner ce problème
Pour windows, le mode binaire/texte modifie le comportement avec les \r.
En mode binaire, tu les verras passer, pas en mode texte.