Discussion :

[hornetbzz]

Bonjour,

C'est une proposition d'ajout à la FAQ:

Windows et Unix ont des caractères de fin de ligne différents. En cas d'import de fichiers texte (y compris des scripts bash par exemple), il faut les convertir au format Unix sans quoi l'interprêteur (/bin/sh ou /bin/bash par exemple) ne pourra pas les exécuter :

Le fichier au format Windows non converti au format Unix fera apparaitre des caractères ^M (ASCII=\x0D$)si vous l'ouvrez dans un éditeur (vi, vim, nano, gedit, ..). Il faut donc convertir les fichiers vers le format UNIX de la manière suivante :

Code :

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

find /chemin/vers/mon/repertoire/de/fichiersWindoz/ -type f -exec sed -i -e "s/\r$//" {} \;

Vérification que les caractères de fin de ligne ont bien été converti :

Code :

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

cat -Ev <mon_fichier_converti_au_format_UNIX>

ou plus simple :

Code :

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

cat -e <mon_fichier_converti_au_format_UNIX>

Note 1: cela n'est a priori pas nécessaire si vous copiez/collez un code écrit sous Windows dans un éditeur Linux. La conversion se fait à la volée par l'éditeur dans le cas de gedit par exemple. Par contre, il faut convertir les formats pour des fichiers transférés par copie de fichiers.

EDIT:
Note2: Il existe aussi le paquet dos2unix sur les principales distributions, mais ça impose d'ajouter un paquet supplémentaire, pas forcément utile sur une machine vouée à la production par exemple.

[lavazavio]

Sinon, il existe l'outil dos2unix, contenu dans le package tofrodos sous Debian et Debian-Like.

Prenons le fichier foo.txt avec les fameux ^M en fin de ligne.
Pour le convertir au format linux :

Code :

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

dos2unix foo.txt bar.txt

[hornetbzz]

Merci.
Oui mais tout le monde n'a pas Debian/Ubuntu. Mais je peux effectivement l'ajouter en commentaire.

[N_BaH]

Bonjour,

sed -ie signifie qu'une sauvegarde nommée fichiere sera créée !

[hornetbzz]

merci, tipo corrigée

[lavazavio]

- Avec awk :

Code :

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

awk '{ sub("\r$", ""); print }' $1 > $2

- Avec tr :

Code :

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

cat $1 | tr -d '\r' >$2

- Avec perl :

Code :

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

perl -pi -e 's/\r//g'

[hornetbzz]

oui, effectivement, les solutions sont très nombreuses.

pas vérifié mais ça devrait aussi le faire :

Code :

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

awk -F= '{gsub("\r$","",$1)}1' OFS="=" mon_fichier

mais il me semble que awk est plus difficile à appréhender que sed. Pour moi en ts cas. Et la solution Perl peut-elle convenir dans cette FAQ, alors que la FAQ Perl est bien fournie et comporte déjà ce point ?

Donc je pense me restreindre à une seule solution qui fonctionne, sinon il faut écrire un tuto. Et même remarque, awk est rarement dispo en busybox alors que sed, si.

[lennelei]

pour des raisons de compatibilité, je trouve que la solution

Code :

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

tr -d '\r' < fichier1 > fichier2

est la plus pratique non ?

edit: de même, le cat -Ev peut être avantageusement remplacé par cat -e plus universel

[hornetbzz]

pour des raisons de compatibilité, je trouve que la solution

Code :

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

tr -d '\r' < fichier1 > fichier2

est la plus pratique non ?

edit: de même, le cat -Ev peut être avantageusement remplacé par cat -e plus universel

tr:
Oui je suis d'accord, plus pratique et plus élégant aussi. Et donc, tu l'intègres comment ta redirection dans un find ?

cat:
le man dit que les 2 sont strictement équivalents et ne parle pas d'obsolescence de l'un par rapport à l'autre. Donc je préfère la solution "lisible". Un coup de man, et le lecteur comprend tout de suite à quoi servent les options. Mais là, c'est du chipotage :-)

[lennelei]

tr:
Oui je suis d'accord, plus pratique et plus élégant aussi. Et donc, tu l'intègres comment ta redirection dans un find ?

cat:
le man dit que les 2 sont strictement équivalents et ne parle pas d'obsolescence de l'un par rapport à l'autre. Donc je préfère la solution "lisible". Un coup de man, et le lecteur comprend tout de suite à quoi servent les options. Mais là, c'est du chipotage :-)

Etant arrivé en cours de route, j'avais zappé le find du début et je répondais plus par rapport aux propositions de lavazavio
Avec find, le sed est naturellement plus adapté (Mais est-ce que le g est bien nécessaire ?! Tu n'auras jamais qu'un seul \r$ par ligne normalement non ?).

Pour ce qui est des histoires d'options, le problème, c'est que beaucoup de gens passent ici mais travaillent sur des machines sous Unix où un bon paquet de paramètres n'existent pas (comme -E pour cat, -i pour sed,...), c'est pour ça que je fais la remarque. Et je pense que l'option -e est plus utile que -E mais bon...

[hornetbzz]

Merci

Effectivement l'option "g" ne sert à rien ici.
Pour le cat, il suffit de mettre les deux versions, j'édite comme ça.

[zipe31]

Salut,

Pour la portabilité il serait peut être bon d'ajouter :

Code :

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

sed 's/^M$//'

Le ^M s'obtenant par la séquence de touches "CTRL-V" + "CTRL-M".

De même sous GNU-sed la notation ASCII est aussi possible :

Code :

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

sed 's/\x0D$//'

[hornetbzz]

merci- ajouté le code ASCII.

[djibril]

http://perl.developpez.com/sources/?...chier#dos2unix

[hornetbzz]

Ok, quand je pourrai éditer, j'ajouterai aussi cette possibilité.

[hornetbzz]

Bon voila, merci pour les commentaires que j'ai récapitulés pour la proposition d'ajout à la FAQ:
-----------------------------------------------------------------------
Windows et Unix ont des caractères de fin de ligne différents. En cas d'import de fichiers texte (y compris des scripts bash par exemple), il faut les convertir au format Unix sans quoi l'interpréteur (/bin/sh ou /bin/bash par exemple) ne pourra pas les exécuter ou risque de mener à des résultats étranges et venus d'ailleurs - je plaisante -, en tous cas, des erreurs difficiles à tracer :

Le fichier au format Windows non converti au format Unix fera apparaitre des caractères ^M si vous l'ouvrez dans un éditeur (vi, vim, nano, gedit, ..).

Remarque: Ce caractère "^M" s'obtient par la combinaison de touches "CTRL-V" + "CTRL-M". Le code ASCII du caractère "^M" est \x0D$.


Voici un panel de solutions possibles :

# commande GNU-sed (SOLUTION PORTABLE)

Code :

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

find /home -type f -name "*.ext" -exec sed -i -e 's/^M$//' {} \;

# commande GNU-sed

Code :

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

find /home -type f -name "*.ext" -exec sed -i -e "s/\x0D$//g" {} \;

# commande SED pour les distributions relativement récentes

Code :

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

find /home -type f -name "*.ext" -exec sed -i -e "s/\r$//g" {} \;

# DOS2UNIX (un simple "apt-get" à mener dans les distros de type Debian)

Code :

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

find /home -type f -name "*.ext" -print0 | while read -r -d "$(printf "\000")" -r path; do dos2unix $path $path"_new"; done

# commande AWK

Code :

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

find /home -type f -name "*.ext" -print0 | while read -r -d "$(printf "\000")" -r path; do awk '{ sub("\r$", ""); print }' $path > $path"_new"; done

# commande TR

Code :

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

 find /home -type f -name "*.ext" -print0 | while read -r -d "$(printf "\000")" -r path; do cat $path | tr -d '\r' > $path"_new"; done

# PERL

Code :

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

 find /home -type f -name "*.ext" -exec perl -pi -e 's/\r//g' {} \;

[ok.Idriss]

Bonsoir.

Une nouvelle Q/R a été rédigée en fonction des remarques faites dans ce thread : Comment convertir des fichiers texte Windows vers Unix ?

J'ai un peu moins insisté sur le find ou je n'ai mis qu'un seul exemple (savoir parcourir une liste de fichiers n'étant pas l'objet de cette Q/R).

à tous.

Idriss

[Xtian]

Bonjour,

Je sais que la discussion date, néanmoins, je voulais savoir si quelqu'un connait la fonction inverse, c'est à dire convertir des fichiers unix en text windows.

je m'explique :
Mon problème c'est que je sors des fichiers avec des champs délimités extraits d'une base tournant sur unix, en exportant les fichiers par ftp, je dois compresser avec un tar gz, lorsque les utilisateurs essayent d'ouvrir les fichiers avec bloc note ou autre, la délimitation n'est plus respecté, sauf s'il l'ouvre TEXTPAD par exemple et enregistre le fichier sous format PC au lieu de UNIX.

Merci bien