في الفرق العربية التي تتوزع بين مطورين يستخدمون ويندوز محليًا وخوادم لينكس للنشر، لا تظهر مشكلة CRLF مقابل LF كخلل نظري، بل كسبب فعلي لفشل نشر ملف على الخادم يعمل تمامًا على جهاز المطوّر.
من أين جاء هذا الفرق
يستخدم يونكس وmacOS حرفًا واحدًا — LF (تغذية سطر، \n). ورث ويندوز من آلات التلغراف القديمة زوجًا من الأحرف — CRLF (إرجاع الحاملة + تغذية السطر، \r\n): أحدهما يعيد الحاملة إلى بداية السطر، والآخر ينقلها إلى السطر التالي — محاكاة حرفية للآلة الكاتبة.
لماذا لا يزال هذا مهمًا
- Git. إذا دخل ملف بنهايات CRLF إلى مستودع تستخدم فيه ملفات أخرى LF، قد يُظهر git "تغيّر الملف بأكمله" رغم تعديل سطر واحد فقط — لأن نهايات كل الأسطر تغيّرت تقنيًا.
- سطور shebang. سكربتات شِل يونكس المحفوظة بنهايات CRLF قد تفشل في التشغيل على خادم لينكس، لأن المفسّر يرى حرف
\rإضافيًا في السطر الأول. - مقارنة السلاسل في الكود. الأسطر المقروءة من ملف CRLF قد لا تطابق عند مقارنتها بسلسلة LF متوقعة، رغم أن النص الظاهر يبدو متطابقًا.
كيف يُعالَج هذا
يملك git إعدادًا (core.autocrlf) يحوّل نهايات الأسطر تلقائيًا عند السحب/الإيداع، لكن الاعتماد على إعداد كل مطوّر محليًا حل هش. الأضمن هو تثبيت النمط في ملف .gitattributes داخل المستودع نفسه، بحيث لا تعتمد النتيجة على إعدادات جهاز أي شخص.
لماذا نحتاج التحويل اليدوي
- إصلاح ملف دخل إلى مستودع بنمط نهاية سطر خاطئ.
- تحضير سكربت حُرِّر في محرر ويندوز قبل رفعه إلى خادم لينكس.
- تشخيص سبب ظهور فرق في مقارنة نصية بين ملفين يبدوان متطابقين.
نهايات مختلطة في ملف واحد
قد يحتوي الملف الذي حُرِّر في عدة محررات أو على أنظمة تشغيل مختلفة على CRLF وLF معًا في آن واحد — بعض الأسطر بنمط، وبعضها الآخر بنمط مختلف. هذه هي الحالة الأكثر تعقيدًا: التحويل "إلى LF" قد لا يبدو أنه يغيّر شيئًا للأسطر التي كانت بالفعل بنمط LF، لكن من المهم تطبيق التحويل على الملف بأكمله، وليس فقط على الأسطر التي تبدو "مشبوهة"، وإلا ستبقى المشكلة خفية.