Si vous avez déjà fait du développement Web pour vos besoins, pour partager une astuce ou une ressource ou pour contribuer à un projet, il vous est probablement déjà arrivé l’un de ces cas de figure :
- Vous avez à demander de l’aide, répondre à quelqu’un ou partager une astuce sur un forum, et pour cela, vous avez à poster un code venant directement de votre éditeur de texte. Mais une fois votre message envoyé, vous remarqué que vos lignes sont séparées par un saut de ligne, ce qui fait que vous devez éditer votre message pour virer les retours à la ligne en trop !
- Vous vous mettez au développement collaboratif avec Git, puis on vous signale un problème de sauts de ligne causant des différences entre deux versions d’un fichier.
Si un de ces cas de figure vous est arrivé, lisez ce qui suit. …et même si ça ne vous était jamais arrivé, ça peut quand même vous être utile.
Une question de formats de fin de ligne
Saviez-vous qu’il existe plusieurs formats de fin de ligne ? Bien que ce ne soit pas perceptible visuellement lorsque vous éditez vos fichiers, il est important que vous les connaissiez.
Il existe deux principaux formats de fins de ligne : le format DOS/Windows (CRLF), dont la fin de ligne s’écrit comme \r\n, et le format UNIX/Linux (LF), qui s’écrit tout simplement \n
Que signifie ces codes :
- \r signifie « carriage return », ou autrement dit « retour chariot »
- \n signifie « new line », ou autrement dit « nouvelle ligne »
Vous serez donc sûrement d’accord avec moi que deux codes juste pour une nouvelle ligne, c’est superflu, alors qu’un seul suffirait.
Et puisque pour des raisons historiques, on va préférer les méthodes unixiennes, la convention dans le monde Open source veut donc que les fichiers utilisent le format UNIX (LF) pour les fins de ligne.
Comment passer au format UNIX
Premièrement, la fonction « rechercher/remplacer » de votre éditeur de texte (Notepad++, gedit, kate) permet généralement de remplacer le \r\n par \n dans vos fichiers, même si ces codes sont invisibles. C’est d’ailleurs la solution temporaire que j’ai utilisée en attendant d’avoir la solution qui va suivre.
Deuxièmement, vous pouvez généralement configurer le format de fin de ligne à utiliser à l’enregistrement. Suivant votre éditeur, cela peut se trouver dans vos préférences (ex: Notepad++), mais dans d’autres comme gedit, cette options n’est présente que dans la fenêtre « Enregistrer sous », au moment d'enregistrer votre fichier, donc ne faites pas comme moi : pensez à regarder à cet endroit également !
Et finalement, pour ceux qui utilisent Git, vous devrez configurer Git pour convertir automatiquement les fins de ligne au format UNIX. Pour cela, c'est indiqué dans l'aide en ligne de GitHub : http://help.github.com/line-endings/
Vous devez choisir l'une ou l'autre des commandes en fonction de votre système d'exploitation, ce qui signifie que vous devez prendre la première si vous êtes sous Mac ou Linux, ou la deuxième si vous êtes sous Windows.
Et pour mes fichiers déjà enregistrés ?
Si vous avez déjà enregistrés plusieurs fichiers, ou si vos fichiers ont été originalement créés sous Windows ou sont dérivés de fichiers originalement créés sous cet OS, vous devrez les ouvrir un à un, et les ré-enregistrer en choisissant le format UNIX pour que l'éditeur convertisse les fins de ligne.
À partir de là, vous ne devriez plus avoir ces problèmes.
