« dos2unix ? Mais tout le monde sait s’en servir ! Ce blog me prendrait-il pour une poire ou, pire, pour un jambon ?« , pensez-vous après avoir lu le titre de cet article.
Effectivement, la commande dos2unix et ses variantes (« dos2ux » sous HP-UX ou « unix2dos » sous MS Windows) appartiennent à la catégorie des outils de base, surtout si vous travaillez en environnement hétérogène. Le cas le plus courant étant des scripts développés sous Windows mais à destination d’un système Unix.
Son utilisation est simple mais il y a quelques pièges que nous allons détailler. Cela nous permettra aussi de voir la configuration des langues dans un terminal.
Le point de départ est donc un script en format texte (des instructions SQL) qui, lorsqu’il est ouvert sur sa machine de destination, montre plusieurs défauts :
^M set serveroutput on^M declare ^M v_existe int := 0 ;^M dbms_output.put_line(v_maj_Table1 ||' lignes modifi\303\251es dans la table Table1 '); --Afficher le nombre modifi\303\251 dans Table1 ^M dbms_output.put_line(v_maj_Table2 ||' lignes modifi\303\251es dans la table Table2 ' ); -- Afficher le nombre modifi\303\251 dans Table2^M
Comme vous pouvez le constater, il y a deux problèmes : le retour à la ligne est au format DOS (« ^M ») et les accents n’apparaissent pas correctement.
Le premier piège : seul un vrai éditeur (par exemple: « vi ») vous montre ces caractères inattendus. « cat », « head », « tail » affichent normalement les lignes (Les petits malins du fond de la classe feront remarquer qu’un dump en octal, avec « od -c », affiche aussi les anomalies. Certes. Mais si vous en êtes à utiliser ce genre d’outil avant d’exécuter un script, votre paranoïa dépasse la mienne. Félicitations et bon courage).
Pour convertir le fichier, il faut appeler la commande « dos2unix » avec le fichier en paramètre et une redirection vers un second fichier. Deuxième piège : la version Linux diffère en ce qu’elle autorise une modification sur le fichier d’origine si le second n’est pas précisé. Ça n’a l’air de rien mais c’est une source de confusion. Sous Solaris, sans ce paramètre, c’est la sortie standard qui est utilisée.
Utilisation avec Solaris :
dos2unix fichier_sale.txt fichier_propre.txt
Avec Linux :
dos2unix fichier_sale.txt [fichier_propre.txt]
Le retour à la ligne est passé en format Unix.
Par contre, nous avons un avertissement :
could not open /dev/kbd to get keyboard type US keyboard assumed could not get keyboard type US keyboard assumed
… et les accents sont toujours mal gérés. Explication : la gestion des jeux de caractères est rendue délicate par l’existence de nombreuses tables de codage. Heureusement que l’UTF-8 résout la majorité des anciens problèmes… au prix, parfois, d’ajout de nouveaux. Le « man dos2unix » sous Solaris l’écrit en toutes lettres : il faut ajouter un encodage ASCII. Soit. C’est curieux mais pourquoi pas.
dos2unix -ascii fichier_sale.txt fichier_propre.txt
Un coup d’œil dans fichier_propre.txt montre que cela ne change rien. Le problème se situe au niveau de la prise en charge des caractères accentués par votre session.
Pour lister les variables actives : « locale ». Pour lister les variables de langues disponibles « locale -a ». Par défaut, sur Solaris, nous avons :
$ locale LANG= LC_ALL=
Rien de positionné, donc encodage « C » (le plus neutre, doux pour vos cheveux comme pour votre linge). D’où les accents qui s’affichent mal.
« export LC_LANG=LANG=fr_FR.UTF-8 » et les lignes s’affichent correctement, voyez plutôt :
dbms_output.put_line(v_maj_Table1 ||' lignes modifiées dans la table Table1 '); --Afficher le nombre modifié dans Table1 dbms_output.put_line(v_maj_Table2 ||' lignes modifiées dans la table Table2 ' ); -- Afficher le nombre modifié dans Table2
Famille de DBA s’apprêtant à charger des données. Ont-ils fait attention à leur variables locales ?
Mais attention ! Troisième piège : le logiciel à qui est destiné les commandes utilise peut-être son propre jeu de caractères ! C’est le cas de ce lot de commande Oracle. En effet, Oracle repose sur des variables NLS, indépendantes de votre session mais embarque également un encodage dans la base… qui peut être complètement différent. Dans le cas de mise à jour de valeurs accentuées, les conséquences peuvent être catastrophiques. Imaginez tous les « François » d’une base cliente devant des « Fran%@ois »….
Conclusion : dès que vous entendez « encodage » ou « caractères bizarres… », soyez vigilant. Dans la mesure du possible, restez à l’anglais. Le support multilangue a fait d’énorme progrès mais reste un sac de nœud pour les européens. Argument supplémentaire en faveur des locales en anglais : les messages d’erreur seront beaucoup plus parlant et cela vous fera gagner du temps dans vos recherches. Pour autant, cela ne vous autorise pas à mettre des anglicismes partout.
Des problèmes ? des questions ? Exprimez-vous ! Les commentaires sont ouverts. Coquilles et fautes de grammaires sont notre lot quotidien : signalez-les nous à m.capello@dbsqware.com
« Mais ? Et l’avertissement au sujet du clavier ? » vous exclamez-vous en voyant arriver la conclusion de l’article ? Vous êtes attentifs. Bravo. Ce message indique que la commande ne sait pas quel type de clavier est défini sur le système. Plutôt normal sur des serveurs qui n’en ont jamais vu de prêt. Si vous êtes allergiques aux messages d’avertissement, fournissez manuellement un code de disposition :
dos2unix -ascii -437 fichier_sale.txt fichier_propre.txt