Je travail sur un projet en java qui se trouve sur un serveur cvs. Certaines
personnes travaillent sur windows, d'autres linux. Une classe utilise
readline pour decortiquer un fichier de configuration. Le pb c que si on
modifie ce fichier de config sous linux, qu'on le renvoi sur cvs, et que
les developpeurs sous windows le recuperent, alors readline ne fonctionne
plus sous windows, cela parce que les caratères de fin de lignes sont
différents sous windows et sous linux.
Ca fonctionne en revanche dans l'autre sens (si le fichier est édité sous
windows, readline fonctionne sous linux).
Quelqu'un à t il une solution à ce pb ?
Merci bcp !!
Damien_
--
Web : http://tux-system.ath.cx
Gnomemeeting : damien83.ath.cx
E-mail : damien83@orange.fr
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
oliv
Damien Bardon wrote:
Je travail sur un projet en java qui se trouve sur un serveur cvs. Certaines personnes travaillent sur windows, d'autres linux. Une classe utilise readline pour decortiquer un fichier de configuration. Le pb c que si on modifie ce fichier de config sous linux, qu'on le renvoi sur cvs, et que les developpeurs sous windows le recuperent, alors readline ne fonctionne plus sous windows, cela parce que les caratères de fin de lignes sont différents sous windows et sous linux. En effet,
Mac : CR = 0DH = r Nix : LF = 0AH = n Dos : CR puis LF
Ce qui m'étonne c'est que normalement readLine() devrait détecter correctement les uns comme les autres.
Alors pour contourner : - choisir l'option CRLF dans l'éditeur s'il le permet ou - passer dans un filtre avant d'envoyer sur cvs
par exemple unix2dos qui doit pouvoir se trouver s'il n'est pas déjà présent,
ou pour remplacer LF par CR+LF, cette commande :
sed 's/$/^M/g' <infile >outfile
(^M s'obtient selon systeme et clavier généralement par ctrl-v ctrl-m, chez moi ctrl-v ctrl-j, ...)
vérifier par : sed 's/$/^M/g' <petitfichier | hexdump
Comme ça le fichier sera toujours envoyé en format Windows et l'avantage serait que c'est transparent au programme ?
-- oliv
Damien Bardon wrote:
Je travail sur un projet en java qui se trouve sur un serveur cvs. Certaines
personnes travaillent sur windows, d'autres linux. Une classe utilise
readline pour decortiquer un fichier de configuration. Le pb c que si on
modifie ce fichier de config sous linux, qu'on le renvoi sur cvs, et que
les developpeurs sous windows le recuperent, alors readline ne fonctionne
plus sous windows, cela parce que les caratères de fin de lignes sont
différents sous windows et sous linux.
En effet,
Mac : CR = 0DH = r
Nix : LF = 0AH = n
Dos : CR puis LF
Ce qui m'étonne c'est que normalement readLine() devrait détecter
correctement les uns comme les autres.
Alors pour contourner :
- choisir l'option CRLF dans l'éditeur s'il le permet
ou
- passer dans un filtre avant d'envoyer sur cvs
par exemple unix2dos qui doit pouvoir se trouver s'il n'est pas déjà
présent,
ou pour remplacer LF par CR+LF, cette commande :
sed 's/$/^M/g' <infile >outfile
(^M s'obtient selon systeme et clavier généralement par ctrl-v ctrl-m,
chez moi ctrl-v ctrl-j, ...)
vérifier par :
sed 's/$/^M/g' <petitfichier | hexdump
Comme ça le fichier sera toujours envoyé en format Windows et
l'avantage serait que c'est transparent au programme ?
Je travail sur un projet en java qui se trouve sur un serveur cvs. Certaines personnes travaillent sur windows, d'autres linux. Une classe utilise readline pour decortiquer un fichier de configuration. Le pb c que si on modifie ce fichier de config sous linux, qu'on le renvoi sur cvs, et que les developpeurs sous windows le recuperent, alors readline ne fonctionne plus sous windows, cela parce que les caratères de fin de lignes sont différents sous windows et sous linux. En effet,
Mac : CR = 0DH = r Nix : LF = 0AH = n Dos : CR puis LF
Ce qui m'étonne c'est que normalement readLine() devrait détecter correctement les uns comme les autres.
Alors pour contourner : - choisir l'option CRLF dans l'éditeur s'il le permet ou - passer dans un filtre avant d'envoyer sur cvs
par exemple unix2dos qui doit pouvoir se trouver s'il n'est pas déjà présent,
ou pour remplacer LF par CR+LF, cette commande :
sed 's/$/^M/g' <infile >outfile
(^M s'obtient selon systeme et clavier généralement par ctrl-v ctrl-m, chez moi ctrl-v ctrl-j, ...)
vérifier par : sed 's/$/^M/g' <petitfichier | hexdump
Comme ça le fichier sera toujours envoyé en format Windows et l'avantage serait que c'est transparent au programme ?
-- oliv
Damien Bardon
Merci bcp pour cette réponse tres complete. Mais c vraiment dommage que la JVM de windows ne detecte pas LF !!! Je vais choisir l'option unix2dos je crois. Mais sais tu s'il est possible d'ajouter à cvs un filtre automatique qd tu lui envois un fichier ? (je n'ai pas trouvé dans les commandes cvs).
encore merci !!
oliv wrote:
Damien Bardon wrote:
Je travail sur un projet en java qui se trouve sur un serveur cvs. Certaines personnes travaillent sur windows, d'autres linux. Une classe utilise readline pour decortiquer un fichier de configuration. Le pb c que si on modifie ce fichier de config sous linux, qu'on le renvoi sur cvs, et que les developpeurs sous windows le recuperent, alors readline ne fonctionne plus sous windows, cela parce que les caratères de fin de lignes sont différents sous windows et sous linux. En effet,
Mac : CR = 0DH = r Nix : LF = 0AH = n Dos : CR puis LF
Ce qui m'étonne c'est que normalement readLine() devrait détecter correctement les uns comme les autres.
Alors pour contourner : - choisir l'option CRLF dans l'éditeur s'il le permet ou - passer dans un filtre avant d'envoyer sur cvs
par exemple unix2dos qui doit pouvoir se trouver s'il n'est pas déjà présent,
ou pour remplacer LF par CR+LF, cette commande :
sed 's/$/^M/g' <infile >outfile
(^M s'obtient selon systeme et clavier généralement par ctrl-v ctrl-m, chez moi ctrl-v ctrl-j, ...)
vérifier par : sed 's/$/^M/g' <petitfichier | hexdump
Comme ça le fichier sera toujours envoyé en format Windows et l'avantage serait que c'est transparent au programme ?
-- Web : http://tux-system.ath.cx Gnomemeeting : damien83.ath.cx E-mail :
Merci bcp pour cette réponse tres complete. Mais c vraiment dommage que la
JVM de windows ne detecte pas LF !!! Je vais choisir l'option unix2dos je
crois. Mais sais tu s'il est possible d'ajouter à cvs un filtre automatique
qd tu lui envois un fichier ? (je n'ai pas trouvé dans les commandes cvs).
encore merci !!
oliv wrote:
Damien Bardon wrote:
Je travail sur un projet en java qui se trouve sur un serveur cvs.
Certaines personnes travaillent sur windows, d'autres linux. Une classe
utilise readline pour decortiquer un fichier de configuration. Le pb c
que si on modifie ce fichier de config sous linux, qu'on le renvoi sur
cvs, et que les developpeurs sous windows le recuperent, alors readline
ne fonctionne plus sous windows, cela parce que les caratères de fin de
lignes sont différents sous windows et sous linux.
En effet,
Mac : CR = 0DH = r
Nix : LF = 0AH = n
Dos : CR puis LF
Ce qui m'étonne c'est que normalement readLine() devrait détecter
correctement les uns comme les autres.
Alors pour contourner :
- choisir l'option CRLF dans l'éditeur s'il le permet
ou
- passer dans un filtre avant d'envoyer sur cvs
par exemple unix2dos qui doit pouvoir se trouver s'il n'est pas déjà
présent,
ou pour remplacer LF par CR+LF, cette commande :
sed 's/$/^M/g' <infile >outfile
(^M s'obtient selon systeme et clavier généralement par ctrl-v ctrl-m,
chez moi ctrl-v ctrl-j, ...)
vérifier par :
sed 's/$/^M/g' <petitfichier | hexdump
Comme ça le fichier sera toujours envoyé en format Windows et
l'avantage serait que c'est transparent au programme ?
--
Web : http://tux-system.ath.cx
Gnomemeeting : damien83.ath.cx
E-mail : damien83@orange.fr
Merci bcp pour cette réponse tres complete. Mais c vraiment dommage que la JVM de windows ne detecte pas LF !!! Je vais choisir l'option unix2dos je crois. Mais sais tu s'il est possible d'ajouter à cvs un filtre automatique qd tu lui envois un fichier ? (je n'ai pas trouvé dans les commandes cvs).
encore merci !!
oliv wrote:
Damien Bardon wrote:
Je travail sur un projet en java qui se trouve sur un serveur cvs. Certaines personnes travaillent sur windows, d'autres linux. Une classe utilise readline pour decortiquer un fichier de configuration. Le pb c que si on modifie ce fichier de config sous linux, qu'on le renvoi sur cvs, et que les developpeurs sous windows le recuperent, alors readline ne fonctionne plus sous windows, cela parce que les caratères de fin de lignes sont différents sous windows et sous linux. En effet,
Mac : CR = 0DH = r Nix : LF = 0AH = n Dos : CR puis LF
Ce qui m'étonne c'est que normalement readLine() devrait détecter correctement les uns comme les autres.
Alors pour contourner : - choisir l'option CRLF dans l'éditeur s'il le permet ou - passer dans un filtre avant d'envoyer sur cvs
par exemple unix2dos qui doit pouvoir se trouver s'il n'est pas déjà présent,
ou pour remplacer LF par CR+LF, cette commande :
sed 's/$/^M/g' <infile >outfile
(^M s'obtient selon systeme et clavier généralement par ctrl-v ctrl-m, chez moi ctrl-v ctrl-j, ...)
vérifier par : sed 's/$/^M/g' <petitfichier | hexdump
Comme ça le fichier sera toujours envoyé en format Windows et l'avantage serait que c'est transparent au programme ?
-- Web : http://tux-system.ath.cx Gnomemeeting : damien83.ath.cx E-mail :
oliv
Damien Bardon wrote:
Merci bcp pour cette réponse tres complete. Mais c vraiment dommage que la JVM de windows ne detecte pas LF !!! Malheureusement je n'ai pas de moyen de tester sous Windows
prochainement. Et à vrai dire je n'ai pas trouvé de moyen pour adapter le comportement de readLine() bien que System.getProperty("Line.separator") soit accessible.
Un connaisseur dans l'assistance saurait-il le faire ?
Je vais choisir l'option unix2dos je crois. Mais sais tu s'il est possible d'ajouter à cvs un filtre automatique qd tu lui envois un fichier ? (je n'ai pas trouvé dans les commandes cvs). Il faudrait voir du côté des wrappers définis dans CVSROOT/cvswrappers
ou ~/.cvswrappers.
Ils permettent justement de lancer une commande sur matching d'un nom de fichier, à l'upload ou au download.
voir par exemple : http://developer.apple.com/documentation/DeveloperTools/cvs/cvs_156.html
-- oliv
Damien Bardon wrote:
Merci bcp pour cette réponse tres complete. Mais c vraiment dommage que la
JVM de windows ne detecte pas LF !!!
Malheureusement je n'ai pas de moyen de tester sous Windows
prochainement. Et à vrai dire je n'ai pas trouvé de moyen pour adapter
le comportement de readLine() bien que
System.getProperty("Line.separator") soit accessible.
Un connaisseur dans l'assistance saurait-il le faire ?
Je vais choisir l'option unix2dos je
crois. Mais sais tu s'il est possible d'ajouter à cvs un filtre automatique
qd tu lui envois un fichier ? (je n'ai pas trouvé dans les commandes cvs).
Il faudrait voir du côté des wrappers définis dans CVSROOT/cvswrappers
ou ~/.cvswrappers.
Ils permettent justement de lancer une commande sur matching d'un nom
de fichier, à l'upload ou au download.
voir par exemple :
http://developer.apple.com/documentation/DeveloperTools/cvs/cvs_156.html
Merci bcp pour cette réponse tres complete. Mais c vraiment dommage que la JVM de windows ne detecte pas LF !!! Malheureusement je n'ai pas de moyen de tester sous Windows
prochainement. Et à vrai dire je n'ai pas trouvé de moyen pour adapter le comportement de readLine() bien que System.getProperty("Line.separator") soit accessible.
Un connaisseur dans l'assistance saurait-il le faire ?
Je vais choisir l'option unix2dos je crois. Mais sais tu s'il est possible d'ajouter à cvs un filtre automatique qd tu lui envois un fichier ? (je n'ai pas trouvé dans les commandes cvs). Il faudrait voir du côté des wrappers définis dans CVSROOT/cvswrappers
ou ~/.cvswrappers.
Ils permettent justement de lancer une commande sur matching d'un nom de fichier, à l'upload ou au download.
voir par exemple : http://developer.apple.com/documentation/DeveloperTools/cvs/cvs_156.html
