Perl betiklerinin gerçekten bir uzantısı olmamalı mı?

O'Reilly'nin 6. Sürümü Öğrenme Perl'i okumaya yeni başladım ve bu alıntıyla karşılaştığımda şaşırdım.

#!/usr/bin/perl
print "Hello, world!\n";

Bunu metin düzenleyicinize yazdığınızı düşünelim. (Parçaların ne anlama geldiği ve nasıl çalıştıkları hakkında henüz endişelenmeyin. Bir anda bunları göreceksiniz.) Bu programı genellikle istediğiniz herhangi bir adla kaydedebilirsiniz. Perl herhangi bir özel dosya adı veya uzantısı gerektirmez ve hiçbir uzantı kullanmamak daha iyidir.

Uzantının olmaması neden daha iyi? Bowling puanlarını hesaplamak için bir program yazdığınızı ve tüm arkadaşlarınıza bowling.plx olarak adlandırıldığını söylediğinizi düşünün. Bir gün C'de yeniden yazmaya karar verdiniz. Hala aynı isimle mi diyorsunuz, hala Perl'de yazılmış olduğunu ima ediyor musunuz? Yoksa herkese yeni bir ismi olduğunu mu söylüyorsun? (Ve bunu bowling olarak adlandırmayın. C, lütfen!) Cevap, eğer sadece kullanıyorlarsa, hangi dilde yazıldığı iş değildir. Bu yüzden ilk etapta bowling denirdi.

Bu görünümde gördüğüm tek kaynak bu, okuduğum diğer her şey .pl uzantısını destekledi. Henüz Perl programcısı değilim ve bir alışkanlığa girmeden önce topluluğun bu konudaki görüşünün ne olduğunu bilmek istedim.

Kitaptaki tavsiye tamamen geçerlidir - en azından UNIX benzeri sistemler için. Komut dosyasının yürütülmesi #!, dosya adının uzantı kısmı tarafından değil , satır tarafından denetlenir . Perl komut dosyaları için özel bir uzantı kullanmak, komut dosyasını çalıştıran kişiler için önemli olmaması gereken bilgileri ortaya koyar.

Windows farklı bir konudur. Windows #!mekanizmayı desteklemez ; bunun yerine, bir dosyayı açmak için kullanılan yöntem uzantıya bağlıdır. Örneğin, Windows kabuğu bir .pldosyayı çift ​​tıklatmak (veya bir istemden yürütmek) dosyayı Perl yorumlayıcısına argüman olarak iletecek şekilde yapılandırılabilir . Bir Perl sistemi kurmak muhtemelen sizin için otomatik olarak ayarlayacaktır.

Taşınabilir olması istenen Perl betikleri için, .plWindows'un gerektirdiği sonek UNIX benzeri sistemlere "sızabilir". Yüklendiğinde komut dosyası için uygun bir ad seçen sisteme özgü bir yükleme yöntemine sahip olmak en iyisidir.

On UNIX benzeri sistemlerde, bir .pluzantısı çoğunlukla zararsızdır ve dil belirli bir komut dosyası tarafından kullanılan şeyin bir hatırlatma olarak yararlı bulursanız (belki bir koleksiyonu var .pl, .py, .shve .rb, o zaman bunu yapabilir komut dosyaları). Ancak kitapta açıklandığı gibi bu yaklaşımın dezavantajları vardır: bir komut dosyasını farklı bir dilde yeniden uygularsanız, adı değiştirmeniz ve onu çağıran her şeyi güncellemeniz gerekir.

(Perl modüllerinin.pm Perl'in bulabilmesi için bir uzantıya sahip olması gerekir. Örneğin, bu:

use Foo::Bar;

yorumlayıcının dizide listelenen dizinlerden birinin altındaki bir Bar.pmdizinde adında bir dosyayı aramasına neden olur . Ancak dosyaların doğrudan yürütülmesi gerekmez.)Foo@INC.pm

Bu görünümde gördüğüm tek kaynak bu, okuduğum diğer her şey .pluzantıyı destekledi .

Bunu şaşırtıcı buluyorum. Gördüğüm tavsiye çoğu diyor değil kullanmak .plyürütülebilir komut dosyaları için uzantı.

Önemli değil

#!/usr/bin/perl

sisteme kodu çalıştırmak için hangi programı kullanacağını söyler.

eğer bunu

#!/usr/bin/bash

veya

#!/usr/bin/python

farklı bir tercüman kullanırsınız.

Uzantıya sahip olmak tamamen isteğe bağlıdır ve kullanıcının dili bilmesi gerekmeyen nokta çoğu durumda% 100 doğrudur.

add 2 35 çalışan ve geri almak tüm umurumda (bir kullanıcı olarak).

Komut dosyalarına bir uzantı eklediğim tek zaman, bir nedenden dolayı dili bilmek için son kullanıcıya (bazen kendi kendime) ihtiyaç duymam.

aynı görevi gerçekleştirmenin farklı yollarını göstermek için example.sh veya example.pl.

Bununla birlikte, tüm bunlar, bir uzantıya sahip olmamak daha yaygındır, ancak hepsi tadıdır.

Alıntı gerçekten mükemmel bir tavsiyede bulunuyor.

Ayrıca, daha küçük bir sistem için, uygulama hakkında fikrinizi değiştirmek durumunda, burada ve orada birkaç dosya ve / veya dizeyi yeniden adlandırmanın oldukça önemsiz olduğunu da ekleyeceğim.

Öte yandan, gelişmekte olan modern bir eğilim büyücek o kadar bağlıdır tüm modüller hala dile özgü uzantısına sahip iken sistemleri herhangi uzantısı olmadan ana yürütülebilir dosya olan ifade eder.

Aslında, Python bunu tasarım gereği gerektirir ve genellikle ana Python betiği (adında uzantı içermeyen) tüm uygulamayı önyükleyen birkaç satırdır.

Tüm kitap size Unix'te dosya uzantısının bir konvansiyondan başka bir şey olmadığını söylüyor. Gerçekte, birçok dosya türü bu kategoriye girer. Ruby dosyaları aynı kuralı kullanır, böylece .rb uzantısına ihtiyaç duymazlar. C derleyicileri sadece geçerli C koduna ihtiyaç duyarlar, böylece onları .watoozy olarak adlandırabilirsiniz.

Teknik bir kısıtlama olmasa da, en az sürpriz ilkesinin pratik kısıtlaması vardır . Temel olarak, yakut kodunu bir .pl dosyasında görmek çok şaşırtıcı olurdu, bu yüzden insanlar genellikle bunu yapmazlar.

Kuralın tek istisnası

Bazı sunucu uygulamalarında, başlatma komut dosyası, uygulamayı bir hizmet olarak başlatmayı kolaylaştırmak için uzantısız bir dosyada bulunur. Dosya bu durumda derlenmiş herhangi bir komut gibi görünür. Perl kurulduğu sürece, bu şekilde de davranacaktır.

"O'Reilly's Learning Perl, 6. Baskı" kitabından alıntı çöptür. C'nin perl ile karşılaştırılması eşdeğer değildir, çünkü başlangıçlar C bir uzantısı olmayan bir ikili dosyaya derlenecektir.

Perl derlenmeyeceğinden, bazı metin editörlerinin dosya türünü tanımlamak için uzantıya ihtiyacı olacaktır.

En iyi uygulama dışında, sisteminizin herhangi bir yerinde tam komut dosyası dosya adını sabit kodlamamalısınız, her zaman bir symlink kullanmalısınız veya işletim sisteminize bağlı bir takma ad kullanmalısınız.

Gelecekte, orijinal dosyayı değiştirmeniz gerekirse, yalnızca yeni konumunuzu gösterecek şekilde symlink'i değiştirmeniz gerekir.