क्या पर्ल स्क्रिप्ट का वास्तव में कोई विस्तार नहीं होना चाहिए?


12

मैंने ओ'रेली के लर्निंग पर्ल, 6 वें संस्करण को पढ़ना शुरू किया और जब मैं इस अंश पर आया तो आश्चर्यचकित था।

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

आइए कल्पना करें कि आपने अपने पाठ संपादक में टाइप किया है। (भागों के क्या अर्थ हैं और वे कैसे काम करते हैं, इसके बारे में अभी तक चिंता न करें। आप एक पल में उन लोगों के बारे में देखेंगे।) आप आम तौर पर अपनी इच्छा के अनुसार किसी भी नाम से उस कार्यक्रम को सहेज सकते हैं। पर्ल को किसी विशेष प्रकार के फ़ाइल नाम या एक्सटेंशन की आवश्यकता नहीं है, और यह बेहतर है कि एक्सटेंशन का उपयोग न करें।

कोई विस्तार क्यों नहीं करना बेहतर है? कल्पना कीजिए कि आपने गेंदबाजी स्कोर की गणना करने के लिए एक कार्यक्रम लिखा है और आपने अपने सभी दोस्तों से कहा है कि इसे गेंदबाजी कहा जाता है। पीपीएक्स। एक दिन आप इसे सी में फिर से लिखने का फैसला करते हैं। क्या आप अभी भी इसे उसी नाम से पुकारते हैं, जिसका अर्थ है कि यह अभी भी पर्ल में लिखा है? या आप सभी को बताते हैं कि इसका नया नाम है? (और इसे बॉलिंग नहीं कहेंगे। कृपया!) इसका उत्तर यह है कि यह उनके व्यवसाय का कोई भी नहीं है कि यह किस भाषा में लिखा गया है, यदि वे केवल इसका उपयोग कर रहे हैं। इसलिए इसे पहले स्थान पर गेंदबाजी कहा जाना चाहिए था।

यह एकमात्र ऐसा स्रोत है जिसे मैंने इस दृश्य के साथ देखा है, मैंने जो कुछ भी पढ़ा है उसने .pl विस्तार का समर्थन किया है। मैं अभी तक कोई पर्ल प्रोग्रामर नहीं हूं, और मैं जानना चाहता था कि इस आदत के बारे में समुदाय का दृष्टिकोण क्या है।


जैसा कि उत्तर बताते हैं, विस्तार महत्वपूर्ण नहीं है। लिपियों (पर्ल सहित) के लिए, महत्वपूर्ण बात शेबंग लाइन है

1
नहीं सर, सहमत नहीं हैं। फ़ाइल एक्सटेंशन के बिना आईडीई के और प्रोग्रामर के संपादक सिंटैक्स हाइलाइटिंग पर कैसे निर्णय लेते हैं?
ग्रैंडमास्टरबी

3
@GrandmasterB शेबंग लाइन को देखकर, या मॉडलइन पढ़कर। मैं कभी भी .plउन कार्यक्रमों के लिए एक्सटेंशन का उपयोग नहीं करूंगा , जिन्हें मैं वितरित करना चाहता हूं (कि जानकारी शोर है, सिग्नल नहीं), लेकिन यह स्थानीय स्क्रिप्ट के लिए एक उपयोगी अनुस्मारक है। वैसे भी, यह चर्चा> 90% पर्ल कोड के लिए अप्रासंगिक है क्योंकि यह या तो एक मॉड्यूल ( .pmविस्तार आवश्यक) या एक परीक्षण ( .tएक्सटेंशन प्रथागत) में है।
आमोन २

1
@GrandmasterB मैं लिनक्स पर विकसित करता हूं, और विम और केट दोनों एक फाइल की पहचान सही ढंग से #!/usr/bin/env perlएक पर्ल स्क्रिप्ट के रूप में लाइन से शुरू करते हैं यदि फाइल में कोई परस्पर विरोधी एक्सटेंशन (जैसे .cpp) नहीं है। fileकार्यक्रम (किसी दिए गए इनपुट के लिए एक MIME प्रकार अनुमान करते थे) सही ढंग से deduces text/x-perlविस्तार की परवाह किए बिना।
आमोन

3
कहीं न कहीं मुझे लगा कि हमने नोट किया है कि .pl एक्सटेंशन p erl l पुस्तकालयों के लिए था , और किसी तरह कार्यक्रमों के लिए लोगों द्वारा उपयोग किए जाने वाले तरीकों में जोड़ दिया गया।
ब्रायन डी फ़ो

जवाबों:


14

पुस्तक में सलाह पूरी तरह से मान्य है - कम से कम UNIX जैसी प्रणालियों के लिए। स्क्रिप्ट का निष्पादन #!लाइन द्वारा नियंत्रित किया जाता है , फ़ाइल नाम के विस्तार भाग द्वारा नहीं। पर्ल स्क्रिप्ट के लिए एक विशेष एक्सटेंशन का उपयोग उन सूचनाओं को उजागर करता है जो स्क्रिप्ट चलाने वाले किसी के लिए महत्वपूर्ण नहीं होनी चाहिए।

विंडोज एक अलग मामला है। विंडोज #!तंत्र का समर्थन नहीं करता है; इसके बजाय, किसी फ़ाइल को खोलने के लिए उपयोग की जाने वाली विधि एक्सटेंशन पर निर्भर करती है। उदाहरण के लिए, विंडोज शेल को कॉन्फ़िगर किया जा सकता है ताकि किसी .plफ़ाइल पर डबल-क्लिक करना (या इसे शीघ्रता से निष्पादित करना) इसे पर्ल इंटरप्रेटर के तर्क के रूप में पास करेगा। एक पर्ल सिस्टम को स्थापित करना संभवतः आपके लिए स्वचालित रूप से सेट हो जाएगा।

पर्ल स्क्रिप्ट के लिए पोर्टेबल होने का इरादा है, .plविंडोज द्वारा आवश्यक प्रत्यय UNIX जैसी प्रणालियों पर "लीक" हो सकता है। सिस्टम-विशिष्ट इंस्टॉलेशन विधि शायद यह सबसे अच्छा है जो स्क्रिप्ट के लिए उपयुक्त नाम चुनता है क्योंकि यह स्थापित है।

पर यूनिक्स सिस्टम, एक .plविस्तार ज्यादातर हानिरहित है, और आप इसे क्या भाषा एक विशेष स्क्रिप्ट के द्वारा प्रयोग किया जाता है की एक चेतावनी के रूप में उपयोगी पाते हैं, तो (शायद आप का एक संग्रह है .pl, .py, .sh, और .rb, तो आप ऐसा कर सकते हैं स्क्रिप्ट)। लेकिन उस दृष्टिकोण की कमियां हैं, जैसा कि पुस्तक में वर्णित है: यदि आप किसी अन्य भाषा में स्क्रिप्ट को फिर से लागू करते हैं, तो आपको नाम बदलना होगा और उसे कॉल करने वाली किसी भी चीज़ को अपडेट करना होगा।

(पर्ल मॉड्यूल को एक .pmएक्सटेंशन की आवश्यकता है ताकि पर्ल उन्हें मिल सके। उदाहरण के लिए, यह:

use Foo::Bar;

सरणी में सूचीबद्ध निर्देशिकाओं में से एक के तहत Bar.pmनामित निर्देशिका में नाम वाली फ़ाइल की खोज करने के लिए दुभाषिया का कारण होगा । लेकिन फाइलें सीधे निष्पादित नहीं की जाती हैं।Foo@INC.pm

यह एकमात्र स्रोत है जिसे मैंने इस दृश्य के साथ देखा है, मैंने जो कुछ भी पढ़ा है, उसने .plविस्तार का समर्थन किया है।

मुझे वह आश्चर्यचकित करता है। मैंने जो सलाह दी है, उनमें से अधिकांश का कहना है कि निष्पादन योग्य स्क्रिप्ट के लिए एक्सटेंशन का उपयोग नहीं करना .pl


1

कोई बात नहीं

#!/usr/bin/perl

सिस्टम को बताता है कि कोड को चलाने के लिए किस प्रोग्राम का उपयोग करना है।

अगर आपने उसे बदल दिया है

#!/usr/bin/bash

या

#!/usr/bin/python

आप एक अलग दुभाषिया का उपयोग करेंगे।

एक्सटेंशन का होना पूरी तरह से वैकल्पिक है, और उपयोगकर्ता को यह जानने की आवश्यकता नहीं है कि ज्यादातर मामलों में भाषा 100% सही है।

चल रहा है add 2 3और वापस आ रहा है 5 मैं सब के बारे में परवाह है (एक उपयोगकर्ता के रूप में)।

केवल एक बार मैं स्क्रिप्ट में एक एक्सटेंशन जोड़ देता हूं, अगर मुझे किसी कारण के लिए भाषा जानने के लिए अंतिम उपयोगकर्ता (मेरे स्वयं के समय) की आवश्यकता है।

example.sh या example.pl एक ही कार्य को पूरा करने के विभिन्न तरीकों को दिखाने के लिए।

हालांकि, सभी ने कहा कि इसका विस्तार नहीं होना आम है, लेकिन यह सब स्वाद है।


1

अंश वास्तव में एक पूरी तरह से वैध सलाह देता है।

मैं यह भी जोड़ना चाहूंगा कि एक छोटी सी प्रणाली के लिए, कुछ फ़ाइलों और / या तारों का नाम बदलने और क्रियान्वयन के बारे में अपना दिमाग बदलने के मामले में यह काफी तुच्छ है।

दूसरी ओर, लार्गी सिस्टम विकसित करने की एक आधुनिक प्रवृत्ति का अर्थ है बिना किसी विस्तार के मुख्य निष्पादन योग्य फ़ाइल होना, जबकि सभी मॉड्यूल जो अभी भी इस पर निर्भर करते हैं कि उनके पास भाषा-विशिष्ट एक्सटेंशन है।

वास्तव में, पायथन को इसके लिए डिजाइन की आवश्यकता होती है , और आमतौर पर मुख्य पायथन लिपि (नाम में विस्तार के बिना) पूरे ऐप को बूटस्ट्रैपिंग के कुछ ही लाइनें होती है।


0

सभी पुस्तक आपको बता रही है कि यूनिक्स पर, फ़ाइल एक्सटेंशन एक सम्मेलन से ज्यादा कुछ नहीं है। वास्तव में, कई प्रकार की फाइलें इस श्रेणी में आती हैं। रूबी फाइलें एक ही सम्मेलन का उपयोग करती हैं, इसलिए उन्हें .rb एक्सटेंशन की आवश्यकता नहीं होती है। सी कंपाइलरों को केवल वैध सी कोड की आवश्यकता होती है, इसलिए आप उन्हें नाम दे सकते हैं।

जबकि कोई तकनीकी संयम नहीं है, कम से कम आश्चर्य के सिद्धांत का व्यावहारिक अवरोध है । मूल रूप से, .pl फ़ाइल में रूबी कोड देखना बहुत ही आश्चर्यजनक होगा, इसलिए लोग आमतौर पर ऐसा नहीं करते हैं।

नियम का अपवाद

कुछ सर्वर अनुप्रयोगों में, स्टार्ट-अप स्क्रिप्ट एक एक्सटेंशन-कम फ़ाइल में होती है, जिससे एप्लिकेशन को सेवा के रूप में शुरू करना आसान हो जाता है। फ़ाइल उस मामले में सिर्फ किसी अन्य संकलित कमांड की तरह दिखती है। जब तक आपने पर्ल स्थापित किया है, तब तक यह उसी तरह व्यवहार करेगा।


C कंपाइलर्स आमतौर पर एक्सटेंशन के आधार पर अपनी इनपुट फाइलों का अलग तरह से इलाज करते हैं। उदाहरण के लिए, जीसीसी .सी स्रोत कोड के रूप में , सी ++ स्रोत कोड के रूप में व्यवहार करता है .cpp, लिंकर को पारित करने के लिए एक वस्तु फ़ाइल के रूप में, और इसी तरह। आप एक कमांड-लाइन विकल्प के साथ इसे ओवरराइड कर सकते हैं, लेकिन मैंने इसे शायद ही कभी इस्तेमाल किया है कि मुझे याद नहीं है कि यह क्या है। सी स्रोत फ़ाइलों के लिए विस्तार महत्वपूर्ण है। निष्पादन पर्ल स्क्रिप्ट के लिए एक्सटेंशन (कम से कम पर यूनिक्स सिस्टम) नहीं है। .cc.C.o.c.pl
कीथ थॉम्पसन

1
@KeithThompson: वास्तव में, एक SUS- कंप्लेंट यूनिक्स सिस्टम पर, वे फाइल एक्सटेंशन c99कमांड के विनिर्देशन का हिस्सा हैं : pubs.opengroup.org/onlinepubs/9699919799/utilities
Jörg W Mittag

-4

"O'Reilly's Learning Perl, 6th Edition" पुस्तक का अंश कचरा है। सी से पर्ल की तुलना करना समकक्ष नहीं है, शुरुआत के लिए सी एक बाइनरी के लिए संकलित किया जाएगा, जिसका विस्तार नहीं है।

पर्ल को संकलित नहीं किया जाएगा, ताकि कुछ पाठ संपादकों को फ़िलाटाइप की पहचान करने के लिए विस्तार की आवश्यकता होगी।

सबसे अच्छे अभ्यास के अलावा, आपको अपने सिस्टम में कहीं भी विस्तार के साथ पूर्ण स्क्रिप्ट फ़ाइलनाम को हार्डकोड नहीं करना चाहिए, आपको हमेशा एक सिमलिंक का उपयोग करना चाहिए या एक अन्य आपके ऑपरेटिंग सिस्टम पर निर्भर करता है।

भविष्य में यदि आपको मूल फ़ाइल को बदलने की आवश्यकता है, तो आपको केवल अपने नए स्थान को इंगित करने के लिए सिमलिंक को बदलना होगा।


पाठ संपादकों के बारे में बयान मान्य हो सकता है - लेकिन दोनों emacs और विम एक विशेष विस्तार के बिना एक पर्ल स्क्रिप्ट का पता लगाने में सक्षम हैं। "सर्वोत्तम अभ्यास" के बारे में आपका दावा कुछ समर्थन के साथ अधिक आश्वस्त होगा। मैं हर समय एक्सटेंशन के बिना अपने (लिनक्स) सिस्टम पर पर्ल स्क्रिप्ट स्थापित करता हूं, और यह कभी भी समस्या का कारण नहीं बनता है।
कीथ थॉम्पसन

हाँ, निश्चित रूप से आपकी स्क्रिप्ट चलेगी अगर इसमें हैश बैंग ( #!) लाइन में है, तो आप उल्लेख करते हैं कि आप लिनक्स पर काम करते हैं जो बहुत अच्छा है .. अगली बार जब आप एक पैकेज मैनेजर के साथ एक एप्लिकेशन इंस्टॉल करते हैं तो यह भी ध्यान दें कि यह कैसे बनाता है आप सीधे binनिर्देशिका में फ़ाइल लिखने के बजाय आप बिन निर्देशिका के लिए एक सहानुभूति .. हर आश्चर्य क्यों।
आरोन गोशाइन

शायद यह पैकेज मैनेजर पर निर्भर करता है? मेरे उबंटू 14.04 सिस्टम पर, मेरे पास 325 पर्ल स्क्रिप्ट हैं /usr/bin, जो सीधे सिम्बलिंक के रूप में नहीं हैं; वे सभी सिस्टम के पैकेज मैनेजर द्वारा स्थापित किए गए थे। पैकेज मैनेजर का अपना डेटाबेस होता है जो प्रत्येक पैकेज के लिए सभी फाइलों के स्थानों पर नज़र रखता है। (सॉफ़्टवेयर के लिए जो मैं स्रोत से बनाता हूं, मैं सीमलिंक का उपयोग करता हूं।) लेकिन मुझे यकीन नहीं है कि पर्ल स्क्रिप्ट का .plविस्तार होना चाहिए या नहीं ।
कीथ थॉम्पसन

मुझे लगता है कि मैं यहां से ऊपर चला गया हूं, जिस बिंदु को मैं बनाने की कोशिश कर रहा था।
एरोन गोशिन

1
क्या उस टिप्पणी पर अधिक विचार किया जाना था?
कीथ थॉम्पसन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.