macOS, Linux ve gnu araçları arasında betik yazarken neden "/bin/sh" yerine doğru kabuğu seçmek gerekir?

macOS ile Linux arasında çalışan bir terminal betiği yazarken en sık yapılan hata, betiği tek bir kabukta denemiş gibi düşünmektir. Oysa aynı komut satırı, farklı sistemlerde farklı kabuklarla çalışabilir; bu da özellikle sh, bash ve zsh arasındaki davranış farklarında sorun çıkarır. Apple’ın portlama rehberi, POSIX uyumluluğunu vurgular; GNU Bash belgeleri de Bash’in POSIX’ten farklı davrandığı noktalar olduğunu açıkça belirtir. Bu yüzden “çalışıyor gibi görünen” bir betik, başka bir sistemde veya başka bir oturum türünde bozulabilir.

Sorun genelde nerede ortaya çıkar?

En yaygın kırılma noktası, betiğin hangi kabukla yorumlanacağını varsaymaktır. Örneğin #!/bin/sh yazmak, betiğin mutlaka Bash ile çalışacağı anlamına gelmez; sistemdeki sh farklı bir kabuk olabilir ve Bash’e özgü sözdizimi desteklenmeyebilir. Buna karşılık #!/usr/bin/env bash kullanmak, Bash’i PATH üzerinden bulmaya yarar; ama bunun da amacı taşınabilirlikten çok açıkça Bash istemektir. GNU Bash belgeleri, shebang satırının interpreter seçimi için nasıl çalıştığını anlatır.

Bir başka sık hata da, etkileşimli kabuk ayarlarını betiğe taşımaktır. Giriş dosyalarında tanımlı takma adlar, fonksiyonlar veya profil ayarları her betikte yüklenmez. Bash, etkileşimli olmayan çalıştırmada farklı başlangıç dosyaları kullanabilir; POSIX modunda ise startup dosyaları da değişir. Bu yüzden terminalde çalışan bir satırın aynı şekilde script içinde çalışacağını varsaymak güvenli değildir.

Taşınabilir bir betikte neye öncelik vermeli?

İlk tercih, Bash’e özgü özelliklere ihtiyaç yoksa POSIX uyumlu yazmaktır. Bu yaklaşım, macOS ve Linux’ta daha az sürpriz çıkarır. Özellikle diziler, gelişmiş dizi genişletmeleri, Bash’e özgü bazı test biçimleri veya kabuğa bağlı ayarlar yerine, standart araçlar ve basit sözdizimi daha güvenlidir. GNU Bash’in kendisi de POSIX standardıyla uyum hedeflediğini, ancak varsayılan davranışın her zaman tam aynı olmadığını söyler.

Bash’e özel bir özellik gerçekten gerekiyorsa bunu açıkça belirtmek daha doğrudur. Böyle durumlarda betik başına uygun shebang koymak, kullanıcıya ve sisteme beklentiyi net anlatır. Apple’ın eski ama pratik rehberi de, Bash uzantılarından kaçınmanın mümkün olmadığı durumlarda kabuğu açıkça seçmeyi önerir. Yani sorun "hangi komutu yazdım" değil, "bu komut hangi kabukta garantiyle çalışır" sorusudur.

Kısa karar kuralı

• Betik her yerde çalışsın istiyorsanız: POSIX uyumlu yazın.
• Bash özelliği kullanıyorsanız: shebang ile Bash’i açıkça isteyin.
• Sadece terminalde denediğiniz komutu betiğe koymayın; etkileşimli kabuk ayarlarına güvenmeyin.
• macOS ve Linux arasında test ederken sh, bash ve gerekiyorsa zsh farkını ayrı ayrı düşünün.

En pratik özet şu: Betiğin hedefi taşınabilirlikse kabuğu sade tutun; hedefi Bash ise bunu saklamayın. Böylece GNU araçları, macOS ve Linux arasında aynı komutun farklı davranma riskini ciddi biçimde azaltırsınız.