Caractère EOF des fichiers textes : \n pour Unix et \r\n pour Windows

Caractère de fin de ligne EOF (« End Of Line »)

J’ai une précision technique à apporter au sujet du caractère EOF. En effet, dans l’article concernant les aspects logiciels de la machine à blague Chuck Norris, j’indiquais que :

« Ici, le seul moyen que j’ai trouvé pour créer un fichier source valide, c’est par le biais d’un copier-coller de l’ensemble du texte à travers l’utilitaire PuTTY. »

C’est vrai que cette technique peu élégante fonctionne. Néanmoins, je n’ai compris que récemment pourquoi la commande strfile ne générait pas de fichier .dat valide depuis le fichier .txt copié depuis mon PC Windows… explications techniques. Revenons tout d’abord à ce qui se produit lorsqu’on applique la commande strfile sur un fichier .txt crée sur un environnement Microsoft. Voici « l’erreur » qui se produit :

Erreur de la commande strfile sur un fichier utilisant le caractère \r\n comme EOF
Erreur de la commande strfile sur un fichier utilisant le caractère \r\n comme EOF

Le retour de la commande indique qu’il n’y a qu’un seul string dans le fichier .dat généré. Ce qui est faux puisque le gisement de blagues Chuck Norris en contient près de 10 000 ! Quoi qu’il en soit, le fichier ainsi généré ne permettra pas à la commande fortune de fonctionner.

Caractère EOF différent selon l’environnement

Ceci s’explique par le caractère EOF. En effet, les fichiers textes n’utilisent pas le même caractère de fin de ligne selon qu’ils sont créés sur un système Windows (\r\n) ou Unix (\n).

Pour s’en convaincre, on pourra lancer la commande :

permet d’afficher le contenu du fichier en octal en faisant apparaître le caractère EOL. La solution consiste donc à supprimer les caractères \r du fichier créé sous Windows pour qu’il soit exploitable sur le Raspberry.

Pour cela, on pourra utiliser la commande sed (Stream Editor) :

qui permet de substituer le caractère \r par rien (en prenant soin auparavant de faire une sauvegarde chucky.txt.old du fichier original avec l’option –i.old). On remarquera ici qu’on remplace ‘\r’ par rien. On aurait pu essayer de remplacer ‘\r\n’ par ‘\n’… mais cela ne fonctionne pas. Pourquoi ? Ceci est lié au fonctionnement de la commande sed qui travaille ligne par ligne :

  1. elle parcourt le Stream jusqu’au caractère ‘\n’ ;
  2. charge tous les caractères avant le caractère ‘\n’ dans une zone de travail, le caractère EOF exclus ;
  3. effectue le traitement de substitution ;
  4. si l’option -i n’est pas précisée, la commande affiche le résultat sur stdout (l’écran) et aucune modification n’est faite sur le fichier passé en paramètre.

Une fois la commande exécutée, si on relance la commande :

on s’aperçoit que la substitution a fonctionner et que le caractère EOL est désormais \n. La commande strfile génère désormais un fichier .dat correct :

Commande strfile sur un fichier utilisant le caractère \n comme caractère EOF
Commande strfile sur un fichier utilisant le caractère \n comme caractère EOF

Le fichier .dat ainsi généré contient cette fois-ci 9692 strings ! En effet, les fichiers textes n’utilisent pas le même caractère de fin de ligne selon qu’ils sont créés sur un système Windows (\r\n) ou Unix (\n). Un simple copier-coller de l’ensemble du texte à travers l’utilitaire PuTTY réalisera la conversion automatiquement.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *