Kabuk Betiği Güvenliği: Sessizce Başarısız Olan Otomasyonlar
Yedekleme betiğiniz her gece çalışıyor ve hata vermiyor. Altı ay sonra bir geri yükleme gerektiğinde fark ediyorsunuz: yedek dosyaları boş. Betik bir adımda başarısız olmuş ama devam etmiş ve başarıyla bittiğini bildirmiş.
Bu yazı, kabuk betiklerini güvenilir yazmayı ele alıyor.
Varsayılan Davranış Tehlikelidir
Kabuk, hata durumunda beklediğiniz gibi davranmaz:
- Bir komut başarısız olsa da devam eder.
- Tanımsız değişken boş kabul edilir.
- Boru hattında yalnızca son komut sayılır.
Birinci madde başta anlatılan felaketi üretir: bir betikte veritabanı dökümü başarısız olsa bile sonraki satırlar çalışmaya devam eder — boş dosya sıkıştırılır, uzağa kopyalanır ve betik başarıyla bitmiş görünür.
Hiçbir aşamada hata bildirilmez.
İkinci madde ise daha yıkıcı sonuçlar doğurabilir ve sonraki bölümde ele alınıyor.
Üçüncü madde ise boru hattı kullanan betiklerde hatayı tamamen gizler.
Katı Mod
| Ayar | Etkisi |
|---|---|
| Hatada dur | İlk başarısızlıkta çıkar |
| Tanımsız değişkeni hata say | Yazım hatasını yakalar |
| Boru hattı hatasını yay | Ara komutlar da sayılır |
İkinci satır çok ciddi bir kazayı önler: bir dizin değişkeninin adını yanlış yazdığınızda kabuk onu boş kabul eder ve silme komutu kök dizinden başlayarak çalışır — tanımsız değişken kontrolü bu felaketi baştan durdurur.
Bu, gerçekte yaşanmış bir hata türüdür.
Birinci satır ise başta anlatılan sessiz başarısızlığı ortadan kaldırır ve her betiğin ilk satırlarında bulunmalıdır.
Üçüncü satır ise boru hattı kullanan işlemlerde gereklidir.
Tırnak Kullanımı
En sık yapılan ve en çok soruna yol açan hatadır:
- Değişkenler tırnak içinde kullanılmalı.
- Boşluklu yollar bölünmemeli.
- Joker karakterler beklenmedik genişlememeli.
İkinci madde Türkçe dosya adlarında ve kullanıcı yüklemelerinde sık yaşanır: tırnaksız kullanılan bir değişken, içinde boşluk olduğunda birden fazla argümana bölünür — "Aylık Rapor.pdf" adlı bir dosya iki ayrı dosya adı gibi işlenir ve işlem başarısız olur.
Bu hata, test ortamındaki boşluksuz adlarla fark edilmez.
Üçüncü madde ise daha tehlikelidir. Yıldız içeren bir değer, tırnaksız kullanıldığında dizindeki tüm dosyalara genişler.
Kural basittir: her değişken kullanımı tırnak içinde olmalıdır.
Girdi Doğrulama
- Zorunlu argümanları kontrol edin.
- Dizin varlığını doğrulayın.
- Kullanıcı girdisini komuta gömmeyin.
Üçüncü madde güvenlik açısından kritiktir: bir betiğe dışarıdan gelen değeri doğrudan komut satırına yerleştirmek, o değere komut ekleyen birinin sunucunuzda istediğini çalıştırmasına izin verir.
Bu, web formundan tetiklenen betiklerde gerçek bir açıktır.
Değerler argüman olarak geçirilmeli, komut metnine birleştirilmemelidir.
İkinci madde ise silme ve taşıma işlemlerinde zorunludur; olmayan bir dizinde çalışmak beklenmedik sonuç üretir.
Çıkışta Temizlik
| Durum | Sorun |
|---|---|
| Normal bitiş | Temizlik yapılır |
| Hata ile çıkış | Temizlik atlanabilir |
| Kesme sinyali | Temizlik atlanır |
İkinci ve üçüncü satırlar birikim üretir: hata veya kesinti nedeniyle yarıda kalan bir betiğin bıraktığı geçici dosyalar ve kilit dosyaları temizlenmez — zamanla diski doldurur ve sonraki çalışmaları engeller.
Kabuk, çıkış anında çalışacak bir temizlik fonksiyonu tanımlamaya izin verir.
Bu fonksiyon hem normal hem hatalı çıkışta devreye girer ve sorunu tamamen çözer.
Kilit dosyası kullanan betiklerde bu tanım zorunludur; aksi hâlde ortada kalan kilit görevi kalıcı olarak durdurur.
Çıktı ve Kayıt
- Ne yaptığını yazsın.
- Hataları ayrı akışa yazsın.
- Çıkış kodunu doğru döndürsün.
- Sessiz başarı da bildirilsin.
Üçüncü madde otomasyon zincirinin temelidir: bir betik hata olsa bile sıfır çıkış kodu döndürüyorsa, onu çağıran zamanlanmış görev veya izleme sistemi başarılı sandığı için hiç uyarı üretmez.
Bu, sorunun aylarca fark edilmemesinin teknik nedenidir.
Dördüncü madde ise izlemeyi mümkün kılar. Başarılı bir çalışmanın da kaydı olmalıdır ki çalışmadığı fark edilebilsin.
İkinci madde ise hataların günlükte kaybolmasını önler ve ayrı toplanmalarını sağlar.
Betiği Test Etmek
- Boşluklu dosya adlarıyla deneyin.
- Eksik argümanla çalıştırın.
- Bir adımı kasıtlı bozun.
- Çıkış kodunu kontrol edin.
Üçüncü madde en değerli testtir: yedekleme betiğinde veritabanı şifresini kasıtlı yanlış yaparak çalıştırmak, betiğin gerçekten hata verip vermediğini kanıtlar — sessizce devam ediyorsa büyük bir sorun bulunmuş demektir.
Bu test, üretimde bir felaket yaşamadan yapılmalıdır.
Dördüncü madde ise çağıran tarafın davranışını doğrular ve tek komutla kontrol edilir.
Birinci madde ise tırnak hatalarını yakalar ve gerçek dosya adlarıyla yapılmalıdır.
Statik Kontrol
| Kontrol | Yakaladığı |
|---|---|
| Tırnaksız değişken | Bölünme riski |
| Kontrol edilmeyen çıkış kodu | Sessiz hata |
| Yanlış karşılaştırma sözdizimi | Mantık hatası |
| Taşınabilirlik sorunları | Farklı kabukta bozulma |
Bu tür kontroller otomatikleştirilebilir ve büyük değer üretir: kabuk betikleri için bir statik analiz aracı çalıştırmak, gözle fark edilmesi çok zor olan tırnak ve karşılaştırma hatalarını saniyeler içinde listeler.
Bu araçlar ücretsizdir ve mevcut betiklere hemen uygulanabilir.
Dördüncü satır ise farklı sistemlerde çalışacak betiklerde önemlidir; bir kabukta çalışan sözdizimi diğerinde hata verebilir.
Bu fark, geliştirme ile üretim arasında sorun üretir.
Ne Zaman Kabuk Kullanmamalı?
- Karmaşık veri işleme.
- Yapılandırılmış veri ayrıştırma.
- Uzun ve dallanmalı mantık.
Üçüncü madde pratik bir sınır belirler: bir kabuk betiği yüz satırı ve birkaç iç içe koşulu aştığında, aynı işi gerçek bir programlama diliyle yazmak hem daha okunabilir hem daha az hatalı olur.
Kabuk, komutları birbirine bağlamakta güçlüdür; iş mantığı yazmakta değildir.
İkinci madde ise yaygın bir tuzaktır. Yapılandırılmış çıktıyı metin araçlarıyla ayrıştırmak kırılgan sonuçlar üretir.
Bunun için tasarlanmış araçlar kullanılmalıdır.
Otomasyon betiklerinizi test edebileceğiniz bir ortama ihtiyacınız olur; sanal sunucu hizmetleri üzerinde ayrı bir test kullanıcısı ile bu denemeleri güvenle yapabilirsiniz.
Sonuç
Kabuk betiklerinin en tehlikeli yanı varsayılan davranışıdır: bir komut başarısız olsa bile sonraki satırlar çalışır — boş dosya sıkıştırılır, uzağa kopyalanır ve betik başarıyla bitmiş görünür. Katı modu her betiğin başına ekleyin; özellikle tanımsız değişken kontrolü, yanlış yazılmış bir dizin adının silme komutunu kök dizinden başlatmasını önler. Ve bir adımı kasıtlı bozup betiğin gerçekten hata verdiğini kanıtlayın.
Sıkça Sorulan Sorular (SSS)
Betiğim hata vermiyor ama iş yapmıyor?
Kabuk varsayılan olarak bir komut başarısız olsa bile devam eder. Yedekleme betiğinizde döküm başarısız olsa bile sonraki satırlar çalışır: boş dosya sıkıştırılır, kopyalanır ve betik başarıyla bitmiş görünür. Katı modda hatada durma ayarını ekleyin.
Değişkenleri neden tırnak içine almalıyım?
Tırnaksız bir değişken, içinde boşluk olduğunda birden fazla argümana bölünür — "Aylık Rapor.pdf" iki ayrı dosya adı gibi işlenir. Daha tehlikelisi, yıldız içeren bir değer dizindeki tüm dosyalara genişler. Kural basittir: her değişken kullanımı tırnak içinde olmalıdır.
Tanımsız değişken kontrolü neden önemli?
Bir dizin değişkeninin adını yanlış yazdığınızda kabuk onu boş kabul eder ve silme komutu kök dizinden başlayarak çalışır. Bu gerçekte yaşanmış bir hata türüdür ve tanımsız değişken kontrolü onu baştan durdurur.
Çıkış kodu neden kritik?
Bir betik hata olsa bile sıfır döndürüyorsa, onu çağıran zamanlanmış görev veya izleme sistemi başarılı sandığı için hiç uyarı üretmez. Sorunun aylarca fark edilmemesinin teknik nedeni budur. Ayrıca başarılı çalışmayı da kaydedin ki çalışmadığında fark edilsin.
