shebang ve yol

Bir shebang neden bir yola ihtiyaç duyar?

Yanlış

#!ruby

Doğru

#!/usr/local/bin/ruby

#!/usr/bin/env ruby

İşletim sistemi, kayıtlı bir komutun yoluyla ilgili bilgiye sahip olmalı ve neden hala verilmesini bekliyor?

Muhtemelen çekirdeği daha basit tutmak için. Çekirdeğin çalıştırılabilir bir dosya bulmak için yolunu aradığını sanmıyorum. Bu C kütüphanesi tarafından yönetiliyor. #!Standart C kütüphanesini kullanmayan çekirdekte işlem yapılır.

Ayrıca, çekirdeğin yolunun ne olduğuna dair bir fikri olmadığını sanmıyorum. $PATHbir ortam değişkenidir ve yalnızca işlemlerin bir ortamı vardır. Çekirdek değil. Sanırım yürütmeyi yapan sürecin ortamına erişebiliyordu, ancak şu anda çekirdeğin içindeki hiçbir şeyin böyle ortam değişkenlerine erişebileceğini sanmıyorum.

PATHAşağıdakileri kullanarak -saraştırma semantiği alabilirsiniz env:

#!/usr/bin/env ruby  

istediğin anlambilim var

#!ruby

Buna bağlı olarak PATH, iyi uygulama olarak kabul edilmemesinin nedeni , senaryonun PATH ortam değişkeninin içeriği hakkında hiçbir varsayım yapamaması ve ikili dosyaların "sıralı bağımlılık modelini" kırmasıdır.

1. /bin önyükleme zamanında gereken çalıştırılabilir dosyaları içerir;
2. /usr/bin OS kurulumu tarafından kullanılan diğer çalıştırılabilir dosyaları içerir;
3. /usr/local/bin temel işletim sisteminin bir parçası olmayan, sistem yöneticisi tarafından yüklenen yürütülebilir dosyaları içerir.
4. ~/bin kullanıcının kendi çalıştırılabilir dosyalarını içerir.

Her seviye, daha sonra "uygulama" olan, ancak daha önce "temel" olan ikili dosyalara dayanabilecek olan ikilinin varlığını üstlenmemelidir. Ve PATH değişkeni, yukarıdaki doğal bağımlılığın tersi olan uygulamadan esasa doğru çalışma eğilimindedir.

Sorunu göstermek için, içindeki ~/binbir komut dosyası /usr/local/binRuby'yi çağıran bir komut dosyasını çağırırsa ne olacağını kendinize sorun. Bu komut dosyası işletim sistemi yüklü sürümüne mi /usr/bin/ruby, yoksa kullanıcının sahip olduğu kişisel kopyaya ~/bin/rubymı bağlı olmalı ? PATHarama, ikincisiyle ilişkili olarak öngörülemeyen anlambilim verir (belki ~/bin/rubyde bozuk bir sembolik bağlantıdır), #!birincisine verme yolunda pişirme yapar .

Gerçekten platformdan bağımsız "işletim sistemi ... kayıtlı bir komutun yolu ile ilgili bilgi" yok, bu yüzden en basit şey, içinde sağlanan yolda ısrar etmektir #!.

Buna ihtiyacın ya da istersen alternatif bir tercüman belirleyebileceğine inanıyorum. Örneğin:

#!/home/user/myrubyinterpreter

Daha çok kabuk betiklerinde görülür:

#!/bin/bash
#!/bin/sh
#!/bin/dash
#!/bin/csh

Gönderen Klasik Shell Scripting kitabında:

Kabuk komut dosyaları genellikle #! /bin/sh . /bin/shPOSIX uyumlu değilseniz POSIX uyumlu bir kabuğun yolunu kullanın . Dikkat etmeniz gereken bazı düşük seviyeli "gotchas" lar da var:

• Çalıştırılacak tercümanın tam yol adını bilmeniz gerekir. Bu, farklı satıcılar farklı yerlere (örneğin, /bin/awkkarşı /usr/bin/awk) şeyler koyduğundan, satıcılar arası taşınabilirliği önleyebilir .

Başka nedenler var, ancak güvenlik açısından asla bir betiğin doğru yol hakkında varsayımlarda bulunmasını istemem. Ya yanlışsa ve yanlış kabuk veya tercüman kullanıyorsa? Kötü niyetli bir kullanıcı tarafından eklenen bir tanesi? Ya da belirli bir kabuğa dayanıyorsa ve yanlış kabuğun kullanılması durumunda çökerse?

Kullanıcılar kendi yollarıyla uğraşabilir ve eşyalarını kırabilirler - kullanıcıya güvenmeyin :-) Kullanıcıya yolunda yanlış olan bir şeyi yapan çok sayıda saldırı yaptım - genellikle yanlış sırada olan şeyleri alıyorum - böylece bozulabilirim normal bir komut dosyası çağrısı.

Evet, senaryonuzu kendiniz yazdıysanız, kendi yolunuzu belirlediğinizi haklı olarak iddia edebileceğinizi biliyorum, ancak bir tercüman bu kararları veremez.