macOS ve Linux arasında çalışacak kabuk betiği yazarken en çok nerede hata yapılır?

macOS üzerinde terminal kullanmak ile Linux üzerinde terminal kullanmak çoğu zaman benzer görünür; ancak betik yazarken küçük farklar yüzünden komutlar sessizce farklı sonuç verebilir. En sık sorun, tek bir makinede sorunsuz çalışan bir betiğin başka bir sistemde çalışmaması ya da beklenenden farklı davranmasıdır. Apple’ın dokümanları da bu ayrımı açıkça vurgular: macOS’un komut satırı araçları bazı durumlarda GNU eşdeğerlerinden ve Linux’taki yaygın davranışlardan farklı olabilir.

Uyumluluk için önce kabuğu netleştirin​

Birçok sorun “hangi shell ile çalıştığı” belli olmayan betiklerden çıkar. macOS’ta Terminal bir shell süreci açar; aynı betik farklı bir shell altında çalıştırılırsa sözdizimi değişebilir. Bu yüzden ilk satırdaki shebang satırı önemlidir. Betik gerçekten Bash’e ihtiyaç duyuyorsa bunu açıkça belirtmek gerekir; yoksa mümkün olduğunca POSIX uyumlu yazmak daha güvenlidir. Apple, Bash’e özgü uzantılardan kaçınmayı ve taşınabilirlik için dikkatli olunmasını önerir.

Pratik yaklaşım:

• Betikte #!/bin/sh kullanıyorsanız, Bash’e özgü özellikler eklemeyin.
• Bash özellikleri gerekiyorsa bunu bilinçli seçin ve hedef sistemde Bash’in mevcut olduğunu doğrulayın.
• Zsh, Bash ve sh arasında aynı kodun birebir aynı davranacağını varsaymayın.

Komut isimleri aynı olsa bile çıktı biçimi değişebilir​

En çok şaşırtan farklardan biri, aynı komutun macOS ve Linux’ta farklı varsayılan seçeneklerle gelmesidir. Apple’ın dokümanlarında, bazı komut satırı yardımcı programlarının BSD semantiğiyle, bazı durumlarda GNU semantiğiyle ya da tarihsel uyumluluk davranışıyla çalışabildiği belirtilir. Bu yüzden sed, grep, find, tar, xargs, date gibi araçlarda, kısayol diye ezberlenen seçenekler yerine ilgili sistemin man sayfasına bakmak gerekir.

Buradaki temel kural şudur: Komut adı aynıysa bile davranış aynı olmak zorunda değildir. Özellikle betiklerde, kısa seçeneklerin ve varsayılan çıktı formatlarının sistemler arasında değişebileceğini kabul etmek gerekir. GNU Coreutils belgeleri de çıktı biçimi ve alıntılama davranışının seçeneklere göre değişebildiğini gösterir; bu, bir betiğin çıktı ayrıştırma mantığını doğrudan etkileyebilir.

En güvenli çözüm: varsayımı azaltın, açık davranış yazın​

Taşınabilir bir betik için amaç, “benim sistemimde çalışıyor” seviyesinden çıkmaktır. Bunun için birkaç basit alışkanlık yeterlidir:

• Komutlara açık seçenekler verin; varsayılan davranışa güvenmeyin.
• Çıktıyı metin olarak ayrıştıracaksanız, biçimin sabit olduğundan emin olun.
• Dosya yolu, boşluk ve özel karakter içerebilecek girdiler için tırnak kullanın.
• Bir komutun BSD/GNU farkı olabileceğini düşünüyorsanız, alternatifini değil hedef davranışı yazın.
• Betiği hem macOS hem Linux üzerinde küçük test girdileriyle deneyin.

Örneğin, bir komuttan gelen satırları for döngüsüyle doğrudan dolaşmak yerine, satır sonları ve boşluklara duyarlı bir yöntem kullanmak daha güvenlidir. Aynı şekilde, “bu makinede echo şöyle çalışıyor” diye varsaymak yerine, taşınabilir olan biçimleri tercih etmek gerekir. Apple’ın porting rehberi tam olarak bu tür ince farkların betik başarısızlığına yol açabileceğini söylüyor.

Sorun çıktığında ilk bakılacak yerler​

Bir betik macOS’ta çalışıp Linux’ta bozuluyorsa, önce şu sırayı izlemek zaman kazandırır:

• Shebang doğru mu?
• Kullandığınız shell iki sistemde de aynı mı?
• Komutun GNU mu BSD mi olduğuna bakıldı mı?
• Çıktı ayrıştırma kısmı boşluk, satır sonu veya yerel ayarlardan etkileniyor mu?
• Script içinde bash-özgü sözdizimi yanlışlıkla kullanılmış mı?

Bu yaklaşım, hatayı “genel terminal sorunu” gibi görmek yerine, sistemler arası uyumsuzluğu tek tek ayıklamayı sağlar. Apple’ın belgeleri macOS’un BSD kökenli bileşenler taşıdığını ve bazı komutların Linux/GNU dünyasından farklı davranabileceğini açıkça belirtir; bu nedenle çözüm çoğu zaman komutu değiştirmekten çok, betiği daha açık ve taşınabilir yazmaktır.

Ne zaman ayrı araç kullanmak daha doğru olur?​

Eğer betik belirli bir GNU davranışına dayanıyorsa, macOS üzerinde aynı sonucu beklemek yerine o davranışı sağlayan aracı bilinçli seçmek daha doğrudur. Buna karşılık, hedefiniz iki sistemde de rahatça çalışacak bir yardımcı betik yazmaksa, POSIX uyumluluğu ve sade komut kullanımı genelde daha iyi sonuç verir. Apple’ın belgelerinde de çapraz platform betik yazımında bu tercihlerin özellikle önemli olduğu vurgulanır.

Kısacası, macOS ile Linux arasındaki fark çoğu zaman “terminal kötü” olduğu için değil, komut satırı ekosisteminin tarihsel olarak farklı geleneğe sahip olması yüzündendir. Bunu baştan kabul edip açık, taşınabilir ve kontrol edilebilir betikler yazmak, en az hata veren yoldur.