Gönderen Shell Komut Dili POSIX şartnamenin sayfa:

Kabuk komutları dosyasının ilk satırı "#!" Karakterleriyle başlarsa, sonuçlar belirtilmez.

POSIX'in davranışı neden #!belirtilmedi? Bu kadar taşınabilir ve yaygın olarak kullanılan bir şeyin belirtilmemiş bir davranışa sahip olacağını şaşırtıcı buluyorum.

Öncelikle düşünüyorum çünkü:

• davranış uygulama arasında büyük farklılıklar gösterir. Tüm ayrıntılar için https://www.in-ulm.de/~mascheck/various/shebang/ adresine bakın .

  Ancak şimdi, en çok Unix benzeri uygulamaların minimum alt kümesini belirtebilir: #! *[^ ]+( +[^ ]+)?\nilk sözcüğün yerel bir yürütülebilir dosya için mutlak bir yol olduğu gibi (yalnızca bir veya iki kelimede taşınabilir dosya adı karakter kümesindeki karakterler ile) yürütülebilir dosya setuid / setgid ise belirtilmeyen çok uzun ve davranış belirtilmez ve uygulama, yorumlayıcı yolunun veya komut dosyası yolunun argv[0]yorumlayıcıya aktarılıp aktarılmadığını tanımlar .

• POSIX, yürütülebilir dosyaların yolunu zaten belirtmiyor. Birçok sistem /bin/ içinde POSIX öncesi yardımcı programlara /usr/binsahiptir ve başka bir yerde POSIX yardımcı programlarına sahiptir ( /bin/shBourne kabuğunun olduğu ve POSIX'in bulunduğu Solaris 10'da olduğu gibi /usr/xpg4/bin; Solaris 11, daha POSIX uyumlu olan ksh93 ile değiştirdi, ancak çoğu araçlar /binhala eski POSIX olmayan araçlar ). Bazı sistemler POSIX sistemleri değildir, ancak POSIX modu / öykünmesi vardır. Tüm POSIX için gereken, bir sistemin POSIXly olarak davrandığı belgelenmiş bir ortam olmasıdır.

  Örneğin Windows + Cygwin'e bakın. Aslında, Windows + Cygwin ile, bir komut dosyası bir cygwin uygulaması tarafından çağrıldığında ancak yerel bir Windows uygulaması tarafından çağrılmadığında onurlandırılır.

  POSIX, shebang mekanizmasını belirtmiş olsa bile, POSIX sh/ sed/ awk... komut dosyaları yazmak için kullanılamaz (ayrıca, shebang mekanizmasının bir seçenek sonu geçmesine izin vermediği için güvenilir sed/ awkkomut dosyası yazmak için kullanılamayacağını unutmayın. işaretleyici).

Şimdi belirtilmemiş olması, onu kullanamayacağınız anlamına gelmez (iyi, #!sadece sıradan bir yorum olmasını ve bir patlama olmamasını beklerseniz ilk satırın başlamaması gerektiğini söylüyor ), ancak bu POSIX size garanti vermez.

Deneyimlerime göre, shebangs kullanmak, POSIX'in kabuk komut dosyaları yazma yöntemini kullanmaktan daha fazla taşınabilirlik garantisi verir: she-bang'ı bırakın, komut dosyasını POSIX shsözdiziminde yazın ve komut dosyasını her ne çağırırsa shüzerine POSIX uyumlu bir çağrı çağırmasını umuyoruz. betiğin doğru araçla doğru ortamda çağırılacağını biliyorsanız, aksi halde değil.

Bunun gibi şeyler yapmanız gerekebilir:

#! /bin/sh -
if : ^ false; then : fine, POSIX system by default
else
  # cover Solaris 10 or older. ": ^ false" returns false
  # in the Bourne shell as ^ is an alias for | there for
  # compatibility with the Thomson shell.
  PATH=`getconf PATH`:$PATH; export PATH
  exec /usr/xpg4/bin/sh - "$0" ${1+"$@"}
fi
# rest of script

Windows + Cygwin'e taşınabilir olmak istiyorsanız, dosyanızı bir .batveya .ps1uzantıyla adlandırmanız ve aynı dosya üzerinde cygwin'i çağırmak cmd.exeveya powershell.exeçağırmak için benzer bir numara kullanmanız gerekebilir sh.

[POS] davranışı tüm POSIX şikayet mermileri arasında tutarlı görünüyor. Burada kıpır kıpır oda ihtiyacını görmüyorum.

Yeterince derin görünmüyorsun.

1980'lerde bu mekanizma fiilen standardize edilmedi . Dennis Ritchie bunu uygulamasına rağmen, bu uygulama evrenin AT&T tarafında halka ulaşmamıştı. Etkin bir şekilde sadece halka açıktı ve BSD'de biliniyordu; çalıştırılabilir kabuk komut dosyalarıyla AT&T Unix'te bulunmaz. Dolayısıyla standardize etmek makul değildi. İşlerin durumu, bu çağdaş doco ile örneklenmiştir:

BSD ile başlayan dosyaların #! interpreterdoğrudan yürütülmesine izin verirken, SysV yalnızca a.out dosyalarının doğrudan yürütülmesine izin verir. Bu exec…(), bir BSD programındaki rutinlerden birinin bir örneğinin SysV altında /bin/shbu program için yorumlayıcıyı (tipik olarak ) yürütmek için değiştirilmesi gerekebileceği anlamına gelir .

Burada önemli bir nokta, kabuklara bakarken, yürütülebilir kabuk komut dosyalarının varlığı aslında exec…()fonksiyonlar için bir konudur . Kabuklar , bugün bile bazı kabuklarda bulunan (ve günümüzde fonksiyonların alt kümesi için zorunlu olan) yürütülebilir kod mekanizmasının öncüllerini içerir exec…p()ve biraz yanıltıcıdır. Bu bağlamda standardın ele alması gereken şey exec…(), yorumlanmış bir komut dosyasında nasıl çalıştığıdır ve POSIX'in ilk oluşturulduğu sırada, hedef işletim sistemleri spektrumunun büyük bir kısmında ilk etapta işe yaramadı .

Betik sözlü sihirli sayı mekanizması özellikle bu yana standardize edilmemiştir neden bir alt soru vardı evrenin AT & T tarafında kamuoyuna ulaştı ve dokümante edilmiş exec…()yılında Sistem 5 Arayüzü Tanımı ile açmak 1990'larda, :

Bir tercüman dosyası formun bir satırıyla başlar

#! yol adı [arg]

burada pathname yorumlayıcının yoludur ve arg isteğe bağlı bir argümandır. Bir execyorumlayıcı dosyası oluşturduğunuzda, sistem execbelirtilen yorumlayıcıdır.

Ne yazık ki, davranış bugün 1980'lerde olduğu gibi neredeyse tamamen farklıdır ve standartlaşmak için gerçekten yaygın bir davranış yoktur. Bazı Unices (örneğin, ünlü HP-UX ve FreeBSD) komut dosyalarını komut dosyaları için yorumlayıcı olarak desteklemez. İlk satırın boşlukla ayrılmış bir, iki veya birçok öğe olup olmadığı MacOS (ve 2005'ten önceki FreeBSD sürümleri) ve diğerleri arasında değişir. Desteklenen maksimum yol uzunluğu değişir. ␀ve POSIX taşınabilir dosya adı karakter kümesinin dışındaki karakterler, baştaki ve sondaki boşluk gibi zor. 0., 1. ve 2. argümanların ortaya çıktığı şey de karmaşıktır ve sistemler arasında önemli farklılıklar vardır. Bazı anda POSIX conformant ama olmayan-Uixix sistemleri hala bu tür bir mekanizmayı desteklememektedir ve zorunlu kılmak, onları artık POSIX uyumlu olmaya dönüştürecektir.

daha fazla okuma

• Hangi kabuk yorumlayıcısı hiç betiği olmayan bir senaryo çalıştırır?
• Bu durumda neden / usr / bin / env'ye argüman iletebilirim?
• script. NetBSD Çeşitli Bilgi Kılavuzu . 2005-05-06.

Diğer cevapların bazılarında belirtildiği gibi uygulamalar farklıdır. Bu, mevcut komut dosyalarıyla geriye dönük uyumluluğu standartlaştırmayı ve korumayı zorlaştırır . Bu, modern POSIX sistemleri için bile geçerlidir. Örneğin, Linux, mekik çizgisini boşluklarla tam olarak tokenleştirmez. macOS kod yorumlayıcısının başka bir kod olmasına izin vermez.

Ayrıca bkz. Http://en.wikipedia.org/wiki/Shebang_(Unix)#Taşınabilirlik