je suis en train de développer un ptit programme (rudimentaire) de
compression de données. Je l'ai d'abord ecrit sous ouindoz et
aujourd'hui, je l'ai porté sous ... LINUX (ouais, yeepeee !!)
...MAIS... BIG problem...
TOUT marche sauf un truc : à moment donné, j'ai besoin de remplacer tous
les caractères \ avec la chaine \\.
sous ouinedo, evidement ça marche...
pas sous linux. Or la compilation se passe bien... tout se passe tres
bien... sauf evidement que la recherche du caractere \ ne donne
strictement rien.
dans le détail, voila GROSSO MODO comment je procede:
(je ne remplace pas ici un cara par une chaine, mais le pbm est
EXACTEMENT le meme)
Le 2/11/03 13:54, dans , « Erwan David » a écrit :
Éric Lévénez écrivait :
Ce code n'est pas portable car tu supposes un encodage ASCII, ce qui n'est pas forcément le cas.
De toute façopn le code utilise open, read et write qui ne sont pas portables...
Oui, mais c'est pour cela qu'il faut utiliser fopen, fread... dans des cas simples comme celui-là.
Puisqu'il est limité aux suystèmes POSIX,
Comme les unix(-like), et dans l'exemple comme sous Windows qui a copié unix.
il faudrait vérifier si POSIX n'impose pas l'ASCII...
Possible, mais l'ASCII c'est du 7 bits, et là on parle de portabilité du code source, et Posix s'appuie sur la norme du C qui elle n'impose rien.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
david
désolé, le code source que je vous ai fourni etait nul et n'illustrait pas du tout mon probleme.
Cependant l'integralité du code fait plusieurs milliers de lignes il m'etait impossible de les poster ici, d'autant que je ne tiens pas à en publier toutes les parties.
Ceux qui sont curieux d'en voir l'application pourront aller sur http://www.frontere.org/?MenuClick(3,2)
J'ai fait fausse route, mon probleme venait pas de mon code source. Voici comment le probleme s'est resolu :
je me suis rendu compte que cette partie du code ne fonctionnait pas. j'ai testé plus longuement la fonction ByteFind(), comme vous avez pu le remarquer, il m'avait semblé que le probleme venait de ce que les '' etaient mal interprétés : çad que, peut etre le cara '' n'etait pas le meme sous Win et Linux ou, que la fonction read() (peut etre du à un mauvais argument de open()) opérait des transformations (c'est le cas sous DOS avec O_TEXT je crois) sur les données qu'elle transmet. C'est ce que je pensais que l'on allait m'expliquer ici.
Et donc un test plus approfondi m'a montré que j'avais tort.
Il me restait à vérifier 2 fonctions, j'ai commencé par IndexRewind() (dont la fonction est de faire un 'lseek(fp,0,SEEK_SET)', çad positionner l'index fichier à 0)
et là, surprise, la fonction ne faisait pas son boulot.Pourtant partout dans le reste du code, elle marchait...
et ap vérif, apres le second IndexRewind(), l'index etait bien à zero (ce qui n'etait pas le cas apres le premier).
jusque la, je nage...
3°) derniere modif du code : // ---------------------------------------- // /* js->IndexRewind(); */ // je supprime le premier appel de la fonction js->IndexRewind();//rajout while(js->ByteFind('')) { js->ByteInsert(''); } // ---------------------------------------- //
ET la ça marche (comme cela aurait toujours du marcher).
Alors maintenant, si qq1 peut m'aider à trouver une explication !!
(j'ai eu un autre cas de comportement anormal d'une fonction, laquelle s'est mise à fonctionner normalement lorsque j'ai réécrite sa ligne de code (petite fonction qui tient sur une ligne: long StrIndex(){return _StrIndex;} )
Je pense que c'est un pbm qui touche la compilation (j'utilise g++)
Mon hypothese serait que la conversion du code au format texte DOS (avec des retours à la ligne du style rn) en texte UNIX (retours à la ligne n) aurait pu etre mal fait et rendre une ligne invisible aux yeux de gcc. Pour la conversion, j'ai utilisé arachnophilia qui me sert surtout d'editeur (HTML et etc...) mais qui, accessoirement fait ce genre de trucs.
qq1 peut-il m'eclairer?
désolé, le code source que je vous ai fourni etait nul et n'illustrait
pas du tout mon probleme.
Cependant l'integralité du code fait plusieurs milliers de lignes il
m'etait impossible de les poster ici, d'autant que je ne tiens pas à en
publier toutes les parties.
Ceux qui sont curieux d'en voir l'application pourront aller sur
http://www.frontere.org/?MenuClick(3,2)
J'ai fait fausse route, mon probleme venait pas de mon code source.
Voici comment le probleme s'est resolu :
je me suis rendu compte que cette partie du code ne fonctionnait pas.
j'ai testé plus longuement la fonction ByteFind(), comme vous avez pu le
remarquer, il m'avait semblé que le probleme venait de ce que les '\'
etaient mal interprétés : çad que, peut etre le cara '\' n'etait pas le
meme sous Win et Linux ou, que la fonction read() (peut etre du à un
mauvais argument de open()) opérait des transformations (c'est le cas
sous DOS avec O_TEXT je crois) sur les données qu'elle transmet. C'est
ce que je pensais que l'on allait m'expliquer ici.
Et donc un test plus approfondi m'a montré que j'avais tort.
Il me restait à vérifier 2 fonctions, j'ai commencé par IndexRewind()
(dont la fonction est de faire un 'lseek(fp,0,SEEK_SET)', çad
positionner l'index fichier à 0)
et là, surprise, la fonction ne faisait pas son boulot.Pourtant partout
dans le reste du code, elle marchait...
et ap vérif, apres le second IndexRewind(), l'index etait bien à zero
(ce qui n'etait pas le cas apres le premier).
jusque la, je nage...
3°) derniere modif du code :
// ---------------------------------------- //
/* js->IndexRewind(); */ // je supprime le premier appel de la fonction
js->IndexRewind();//rajout
while(js->ByteFind('\'))
{
js->ByteInsert('\');
}
// ---------------------------------------- //
ET la ça marche (comme cela aurait toujours du marcher).
Alors maintenant, si qq1 peut m'aider à trouver une explication !!
(j'ai eu un autre cas de comportement anormal d'une fonction, laquelle
s'est mise à fonctionner normalement lorsque j'ai réécrite sa ligne de
code (petite fonction qui tient sur une ligne: long StrIndex(){return
_StrIndex;} )
Je pense que c'est un pbm qui touche la compilation (j'utilise g++)
Mon hypothese serait que la conversion du code au format texte DOS (avec
des retours à la ligne du style rn) en texte UNIX (retours à la ligne
n) aurait pu etre mal fait et rendre une ligne invisible aux yeux de
gcc. Pour la conversion, j'ai utilisé arachnophilia qui me sert surtout
d'editeur (HTML et etc...) mais qui, accessoirement fait ce genre de trucs.
désolé, le code source que je vous ai fourni etait nul et n'illustrait pas du tout mon probleme.
Cependant l'integralité du code fait plusieurs milliers de lignes il m'etait impossible de les poster ici, d'autant que je ne tiens pas à en publier toutes les parties.
Ceux qui sont curieux d'en voir l'application pourront aller sur http://www.frontere.org/?MenuClick(3,2)
J'ai fait fausse route, mon probleme venait pas de mon code source. Voici comment le probleme s'est resolu :
je me suis rendu compte que cette partie du code ne fonctionnait pas. j'ai testé plus longuement la fonction ByteFind(), comme vous avez pu le remarquer, il m'avait semblé que le probleme venait de ce que les '' etaient mal interprétés : çad que, peut etre le cara '' n'etait pas le meme sous Win et Linux ou, que la fonction read() (peut etre du à un mauvais argument de open()) opérait des transformations (c'est le cas sous DOS avec O_TEXT je crois) sur les données qu'elle transmet. C'est ce que je pensais que l'on allait m'expliquer ici.
Et donc un test plus approfondi m'a montré que j'avais tort.
Il me restait à vérifier 2 fonctions, j'ai commencé par IndexRewind() (dont la fonction est de faire un 'lseek(fp,0,SEEK_SET)', çad positionner l'index fichier à 0)
et là, surprise, la fonction ne faisait pas son boulot.Pourtant partout dans le reste du code, elle marchait...
et ap vérif, apres le second IndexRewind(), l'index etait bien à zero (ce qui n'etait pas le cas apres le premier).
jusque la, je nage...
3°) derniere modif du code : // ---------------------------------------- // /* js->IndexRewind(); */ // je supprime le premier appel de la fonction js->IndexRewind();//rajout while(js->ByteFind('')) { js->ByteInsert(''); } // ---------------------------------------- //
ET la ça marche (comme cela aurait toujours du marcher).
Alors maintenant, si qq1 peut m'aider à trouver une explication !!
(j'ai eu un autre cas de comportement anormal d'une fonction, laquelle s'est mise à fonctionner normalement lorsque j'ai réécrite sa ligne de code (petite fonction qui tient sur une ligne: long StrIndex(){return _StrIndex;} )
Je pense que c'est un pbm qui touche la compilation (j'utilise g++)
Mon hypothese serait que la conversion du code au format texte DOS (avec des retours à la ligne du style rn) en texte UNIX (retours à la ligne n) aurait pu etre mal fait et rendre une ligne invisible aux yeux de gcc. Pour la conversion, j'ai utilisé arachnophilia qui me sert surtout d'editeur (HTML et etc...) mais qui, accessoirement fait ce genre de trucs.
qq1 peut-il m'eclairer?
Pascal Bourguignon
david writes:
3°) derniere modif du code : // ---------------------------------------- // /* js->IndexRewind(); */ // je supprime le premier appel de la fonction js->IndexRewind();//rajout while(js->ByteFind('')) { js->ByteInsert(''); } // ---------------------------------------- //
ET la ça marche (comme cela aurait toujours du marcher). qq1 peut-il m'eclairer?
Serait-y-pas que le fichier contient des CR ou des LF mals convertis et que le // à la fin du commentaire continue à commenter la premier ligne que finalement tu n'as pas supprimé du tout?
Quel éditeur utilises tu? (Il y en a qui se croient malins et qui affichent deux lignes quand ils trouvent un CR).
Sur unix afin d'éviter tout problème avec le compilateur, tu pourrais faire:
for f in *.[hc] ; do cp $f $f~ && tr ' 15' ' 12' < $f~ >$f done
sur tes sources...
Dans tous les cas, tu peux vérifier le code généré avec:
objdump -d file.o
et constater s'il y a ou non l'appel à IndexRewind.
3°) derniere modif du code :
// ---------------------------------------- //
/* js->IndexRewind(); */ // je supprime le premier appel de la fonction
js->IndexRewind();//rajout
while(js->ByteFind('\'))
{
js->ByteInsert('\');
}
// ---------------------------------------- //
ET la ça marche (comme cela aurait toujours du marcher).
qq1 peut-il m'eclairer?
Serait-y-pas que le fichier contient des CR ou des LF mals convertis
et que le // à la fin du commentaire continue à commenter la premier
ligne que finalement tu n'as pas supprimé du tout?
Quel éditeur utilises tu? (Il y en a qui se croient malins et qui
affichent deux lignes quand ils trouvent un CR).
Sur unix afin d'éviter tout problème avec le compilateur, tu pourrais faire:
for f in *.[hc] ; do
cp $f $f~ && tr ' 15' ' 12' < $f~ >$f
done
sur tes sources...
Dans tous les cas, tu peux vérifier le code généré avec:
objdump -d file.o
et constater s'il y a ou non l'appel à IndexRewind.
3°) derniere modif du code : // ---------------------------------------- // /* js->IndexRewind(); */ // je supprime le premier appel de la fonction js->IndexRewind();//rajout while(js->ByteFind('')) { js->ByteInsert(''); } // ---------------------------------------- //
ET la ça marche (comme cela aurait toujours du marcher). qq1 peut-il m'eclairer?
Serait-y-pas que le fichier contient des CR ou des LF mals convertis et que le // à la fin du commentaire continue à commenter la premier ligne que finalement tu n'as pas supprimé du tout?
Quel éditeur utilises tu? (Il y en a qui se croient malins et qui affichent deux lignes quand ils trouvent un CR).
Sur unix afin d'éviter tout problème avec le compilateur, tu pourrais faire:
for f in *.[hc] ; do cp $f $f~ && tr ' 15' ' 12' < $f~ >$f done
sur tes sources...
Dans tous les cas, tu peux vérifier le code généré avec:
objdump -d file.o
et constater s'il y a ou non l'appel à IndexRewind.
j'utilise fte sous Linux. et sous windows : arachnophilia ou l'EDI de BorlandBuilder 3
...pour les fragments de code que j'ai posté, il s'agit de recopies qui montrent ce que j'ai vu avec mes différents editeurs.
je n'ai malheureusement gardé aucune version des sources qui m'ont posé le pbm. Je pourrais les réécrires depuis la version antérieure la + proche (version windows), mais pfff... je considére avoir deja perdu trop de temps avec ça. Je garde précieusement cet echange de posts pour y revienir des qu'un pbm similaire se fera voir.
je ne connaissaisais pas objdump, ça me parait etre un outil ideal pour resoudre ce pbm et, c'est sur, je vais m'y mettre !
merci :)
j'utilise fte sous Linux.
et sous windows : arachnophilia ou l'EDI de BorlandBuilder 3
...pour les fragments de code que j'ai posté, il s'agit de recopies qui
montrent ce que j'ai vu avec mes différents editeurs.
je n'ai malheureusement gardé aucune version des sources qui m'ont posé
le pbm. Je pourrais les réécrires depuis la version antérieure la +
proche (version windows), mais pfff... je considére avoir deja perdu
trop de temps avec ça.
Je garde précieusement cet echange de posts pour y revienir des qu'un
pbm similaire se fera voir.
je ne connaissaisais pas objdump, ça me parait etre un outil ideal pour
resoudre ce pbm et, c'est sur, je vais m'y mettre !
j'utilise fte sous Linux. et sous windows : arachnophilia ou l'EDI de BorlandBuilder 3
...pour les fragments de code que j'ai posté, il s'agit de recopies qui montrent ce que j'ai vu avec mes différents editeurs.
je n'ai malheureusement gardé aucune version des sources qui m'ont posé le pbm. Je pourrais les réécrires depuis la version antérieure la + proche (version windows), mais pfff... je considére avoir deja perdu trop de temps avec ça. Je garde précieusement cet echange de posts pour y revienir des qu'un pbm similaire se fera voir.
je ne connaissaisais pas objdump, ça me parait etre un outil ideal pour resoudre ce pbm et, c'est sur, je vais m'y mettre !
merci :)
Hugues Hiegel
Ce cher david a dit :
j'utilise fte sous Linux. et sous windows : arachnophilia ou l'EDI de BorlandBuilder 3
...pour les fragments de code que j'ai posté, il s'agit de recopies qui montrent ce que j'ai vu avec mes différents editeurs.
je n'ai malheureusement gardé aucune version des sources qui m'ont posé le pbm. Je pourrais les réécrires depuis la version antérieure la + proche (version windows), mais pfff... je considére avoir deja perdu trop de temps avec ça. Je garde précieusement cet echange de posts pour y revienir des qu'un pbm similaire se fera voir.
je ne connaissaisais pas objdump, ça me parait etre un outil ideal pour resoudre ce pbm et, c'est sur, je vais m'y mettre !
Pour info, emacs fonctionne sous windows et unix et te premet, entre autres, de 'voir' le CR.. (il affiche un ^M en fin de ligne). De meme, tu peux lui dire d'enregistrer un fichier au format DOS ou Unix.
Tu as egalement, sous windows, ConTEXT et UltraEdit qui te permettent de gerer ces retours a la ligne assez empoisonnants. (Du temps ou j'utilisais encore windows, je configurais mes editeurs pour editer les fichiers au format unix par defaut.)
-- « La plus value latente d'une entreprise est toujours a priori subordonnée aux moins-values éventuelles de la concurrence. » - L'auberge espagnole -
Ce cher david <nobody@free.fr> a dit :
j'utilise fte sous Linux.
et sous windows : arachnophilia ou l'EDI de BorlandBuilder 3
...pour les fragments de code que j'ai posté, il s'agit de recopies
qui montrent ce que j'ai vu avec mes différents editeurs.
je n'ai malheureusement gardé aucune version des sources qui m'ont
posé le pbm. Je pourrais les réécrires depuis la version antérieure la
+ proche (version windows), mais pfff... je considére avoir deja perdu
trop de temps avec ça.
Je garde précieusement cet echange de posts pour y revienir des qu'un
pbm similaire se fera voir.
je ne connaissaisais pas objdump, ça me parait etre un outil ideal
pour resoudre ce pbm et, c'est sur, je vais m'y mettre !
Pour info, emacs fonctionne sous windows et unix et te premet, entre
autres, de 'voir' le CR.. (il affiche un ^M en fin de ligne).
De meme, tu peux lui dire d'enregistrer un fichier au format DOS ou
Unix.
Tu as egalement, sous windows, ConTEXT et UltraEdit qui te permettent
de gerer ces retours a la ligne assez empoisonnants. (Du temps ou
j'utilisais encore windows, je configurais mes editeurs pour editer
les fichiers au format unix par defaut.)
--
« La plus value latente d'une entreprise est toujours a priori
subordonnée aux moins-values éventuelles de la concurrence. »
- L'auberge espagnole -
j'utilise fte sous Linux. et sous windows : arachnophilia ou l'EDI de BorlandBuilder 3
...pour les fragments de code que j'ai posté, il s'agit de recopies qui montrent ce que j'ai vu avec mes différents editeurs.
je n'ai malheureusement gardé aucune version des sources qui m'ont posé le pbm. Je pourrais les réécrires depuis la version antérieure la + proche (version windows), mais pfff... je considére avoir deja perdu trop de temps avec ça. Je garde précieusement cet echange de posts pour y revienir des qu'un pbm similaire se fera voir.
je ne connaissaisais pas objdump, ça me parait etre un outil ideal pour resoudre ce pbm et, c'est sur, je vais m'y mettre !
Pour info, emacs fonctionne sous windows et unix et te premet, entre autres, de 'voir' le CR.. (il affiche un ^M en fin de ligne). De meme, tu peux lui dire d'enregistrer un fichier au format DOS ou Unix.
Tu as egalement, sous windows, ConTEXT et UltraEdit qui te permettent de gerer ces retours a la ligne assez empoisonnants. (Du temps ou j'utilisais encore windows, je configurais mes editeurs pour editer les fichiers au format unix par defaut.)
-- « La plus value latente d'une entreprise est toujours a priori subordonnée aux moins-values éventuelles de la concurrence. » - L'auberge espagnole -
Stephane Chazelas
2003/11/03, 12:40(+01), Hugues Hiegel: [...]
Pour info, emacs fonctionne sous windows et unix et te premet, entre autres, de 'voir' le CR.. (il affiche un ^M en fin de ligne). De meme, tu peux lui dire d'enregistrer un fichier au format DOS ou Unix. [...]
Puisqu'on ne peut parler d'emacs sans parler de vi, vim est aussi disponible pour Windows.
On choisit le format des fichiers par l'option (locale à chaque buffer) 'fileformat' (abrégée: ff)
Exemple:
:set ff=unix supprime les ^M.
Voir aussi les options 'encoding', "encodings' et 'fileencoding' si on a des soucis de charsets.
Pour info, emacs fonctionne sous windows et unix et te premet, entre
autres, de 'voir' le CR.. (il affiche un ^M en fin de ligne).
De meme, tu peux lui dire d'enregistrer un fichier au format DOS ou
Unix.
[...]
Puisqu'on ne peut parler d'emacs sans parler de vi, vim est
aussi disponible pour Windows.
On choisit le format des fichiers par l'option (locale à chaque
buffer) 'fileformat' (abrégée: ff)
Exemple:
:set ff=unix
supprime les ^M.
Voir aussi les options 'encoding', "encodings' et 'fileencoding'
si on a des soucis de charsets.
Pour info, emacs fonctionne sous windows et unix et te premet, entre autres, de 'voir' le CR.. (il affiche un ^M en fin de ligne). De meme, tu peux lui dire d'enregistrer un fichier au format DOS ou Unix. [...]
Puisqu'on ne peut parler d'emacs sans parler de vi, vim est aussi disponible pour Windows.
On choisit le format des fichiers par l'option (locale à chaque buffer) 'fileformat' (abrégée: ff)
Exemple:
:set ff=unix supprime les ^M.
Voir aussi les options 'encoding', "encodings' et 'fileencoding' si on a des soucis de charsets.
Puisqu'on ne peut parler d'emacs sans parler de vi, vim est aussi disponible pour Windows.
On choisit le format des fichiers par l'option (locale à chaque buffer) 'fileformat' (abrégée: ff)
Exemple:
:set ff=unix supprime les ^M.
Et pour supprimer tous ces ^M génants, on peut faire: :1,$s/r//
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- FF> Tiens, et combien de programmeurs faut-il pour changer une ampoule? Ben, un pour appeler la maintenance et quatorze pour lui expliquer qu'avec Linux ce serait mieux. -+- JR in <http://neuneu.mine.nu> : Fiat lux, et tux fit.
On Mon, 3 Nov 2003, Stephane Chazelas wrote:
Puisqu'on ne peut parler d'emacs sans parler de vi, vim est
aussi disponible pour Windows.
On choisit le format des fichiers par l'option (locale à chaque
buffer) 'fileformat' (abrégée: ff)
Exemple:
:set ff=unix
supprime les ^M.
Et pour supprimer tous ces ^M génants, on peut faire:
:1,$s/r//
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
FF> Tiens, et combien de programmeurs faut-il pour changer une ampoule?
Ben, un pour appeler la maintenance et quatorze pour lui expliquer
qu'avec Linux ce serait mieux.
-+- JR in <http://neuneu.mine.nu> : Fiat lux, et tux fit.
Puisqu'on ne peut parler d'emacs sans parler de vi, vim est aussi disponible pour Windows.
On choisit le format des fichiers par l'option (locale à chaque buffer) 'fileformat' (abrégée: ff)
Exemple:
:set ff=unix supprime les ^M.
Et pour supprimer tous ces ^M génants, on peut faire: :1,$s/r//
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- FF> Tiens, et combien de programmeurs faut-il pour changer une ampoule? Ben, un pour appeler la maintenance et quatorze pour lui expliquer qu'avec Linux ce serait mieux. -+- JR in <http://neuneu.mine.nu> : Fiat lux, et tux fit.
Stephane Chazelas
2003/11/3, 14:46(+01), Erwann ABALEA: [...]
:set ff=unix supprime les ^M.
Et pour supprimer tous ces ^M génants, on peut faire: :1,$s/r//
Pas avec vim si le 'fileformat' est "dos". Ça ne ferait que supprimer les ^M qui ne précèdent pas un ^J (enfin le premier sur chaque ligne à moins de rajouter le flag `g' à la substitution).
vim, à la lecture d'un fichier, détecte le 'fileformat' en regardant si les lignes se terminent par rn (dos) n (unix) ou r (mac). Quand on change la valeur de 'fileformat', il ne se passe rien jusqu'au moment où vim enregistre le fichier auquel cas il insère le bon séparateur entre chaque ligne.
En gros, quand vim charge un fichier DOS, il n'y a plus de notion de r ou rn, il voit juste une liste de lignes, point. Ces lignes peuvent contenir des r, mais pas de rn puisque c'est le séparateur de ligne.
Il est possible de configurer vim pour qu'il considère tous les fichiers d'un type ou d'un autre (voire aussi du côté des options 'binary' et 'noeol'), grace à l'option 'fileformats' ('ffs').
Avec :set ffs=unix là, oui il faudra faire un %s/r$// pour enlever les ^M terminaux. Sinon, il suffit juste de spécifier le format que l'on veut.
Et pour supprimer tous ces ^M génants, on peut faire:
:1,$s/r//
Pas avec vim si le 'fileformat' est "dos". Ça ne ferait que
supprimer les ^M qui ne précèdent pas un ^J (enfin le premier
sur chaque ligne à moins de rajouter le flag `g' à la
substitution).
vim, à la lecture d'un fichier, détecte le 'fileformat' en
regardant si les lignes se terminent par rn (dos) n (unix) ou
r (mac). Quand on change la valeur de 'fileformat', il ne se
passe rien jusqu'au moment où vim enregistre le fichier auquel
cas il insère le bon séparateur entre chaque ligne.
En gros, quand vim charge un fichier DOS, il n'y a plus de
notion de r ou rn, il voit juste une liste de lignes, point.
Ces lignes peuvent contenir des r, mais pas de rn puisque
c'est le séparateur de ligne.
Il est possible de configurer vim pour qu'il considère tous les
fichiers d'un type ou d'un autre (voire aussi du côté des
options 'binary' et 'noeol'), grace à l'option 'fileformats'
('ffs').
Avec :set ffs=unix
là, oui il faudra faire un %s/r$// pour enlever les ^M
terminaux. Sinon, il suffit juste de spécifier le format que
l'on veut.
Et pour supprimer tous ces ^M génants, on peut faire: :1,$s/r//
Pas avec vim si le 'fileformat' est "dos". Ça ne ferait que supprimer les ^M qui ne précèdent pas un ^J (enfin le premier sur chaque ligne à moins de rajouter le flag `g' à la substitution).
vim, à la lecture d'un fichier, détecte le 'fileformat' en regardant si les lignes se terminent par rn (dos) n (unix) ou r (mac). Quand on change la valeur de 'fileformat', il ne se passe rien jusqu'au moment où vim enregistre le fichier auquel cas il insère le bon séparateur entre chaque ligne.
En gros, quand vim charge un fichier DOS, il n'y a plus de notion de r ou rn, il voit juste une liste de lignes, point. Ces lignes peuvent contenir des r, mais pas de rn puisque c'est le séparateur de ligne.
Il est possible de configurer vim pour qu'il considère tous les fichiers d'un type ou d'un autre (voire aussi du côté des options 'binary' et 'noeol'), grace à l'option 'fileformats' ('ffs').
Avec :set ffs=unix là, oui il faudra faire un %s/r$// pour enlever les ^M terminaux. Sinon, il suffit juste de spécifier le format que l'on veut.
