बिल्डिंग कमांड लाइन एप्लिकेशन (सीएलआई)

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

शुरू करने के लिए, मैं एक सवाल पूछूंगा। यदि आप IT-shnikov के समुदाय को देखते हैं, तो आप देख सकते हैं कि एक सुंदर चित्रमय इंटरफ़ेस के साथ कार्यक्रमों की प्रचुरता के बावजूद, कमांड-लाइन एप्लिकेशन बहुत लोकप्रिय हैं। क्यों?
कई उत्तर हैं। सबसे पहले, यह सुंदर रूप से सुविधाजनक है - यदि आप कमांड लाइन पर एक कमांड के साथ किसी कार्य का वर्णन कर सकते हैं, तो यह आसान है कि अगर आपको माउस आंदोलनों और विभिन्न मेनू आइटमों पर क्लिक का विश्लेषण करना है तो इससे अधिक आसान है। दूसरे, यह अविश्वसनीय तरीके से कार्यक्रमों को संयोजित करना संभव बनाता है, जो कि ग्राफिकल इंटरफेस का उपयोग करके हासिल करना मुश्किल है।
बहुत हद तक, यूनिक्स दर्शन इस सिद्धांत पर आधारित है कि कई छोटी उपयोगिताएँ, जिनमें से प्रत्येक अपना विशिष्ट कार्य कर सकती हैं, एक बहुक्रियाशील सार्वभौमिक कार्यक्रम से बेहतर हैं। और यह आईटी-शिकोव की दुनिया में यूनिक्स-सिस्टम की सफलता का एक कारण है।
शायद, हर कोई समझता है कि यह संभावना नहीं है कि वे GUI से CLI तक एक साधारण उपयोगकर्ता को लुभाने में सक्षम होंगे, आइए हम पर ध्यान केंद्रित करें, "कंप्यूटर वैज्ञानिक" और CLI अनुप्रयोगों के लिए हमारी इच्छाओं को निर्दिष्ट करें।

सामान्य आवश्यकताओं

संक्षेप में, हम चाहते हैं कि उनका उपयोग सरलता से किया जाए, लेकिन कुशलता से। डेविड कोपलैंड ने इसे प्राप्त करने के लिए आवेदन आवश्यकताओं की एक विस्तृत सूची लिखी है:

• उपयोग करने में आसान - इसका उपयोग करना आसान होना चाहिए और इसका एक स्पष्ट उद्देश्य होना चाहिए। अधिमानतः एक। तुला, जिसे हर कोई जानता है कि स्विस चाकू का उपयोग कैसे किया जाता है, आमतौर पर उपयोग करना मुश्किल होता है और कोई भी उनकी सभी क्षमताओं को नहीं जानता है। हालाँकि, हम इस बारे में भी बात करेंगे कि विविध अनुप्रयोगों को कैसे डिज़ाइन किया जाए ताकि उनका उपयोग और समर्थन करना आसान हो सके।
  न्यूनतम आप अपने कार्यक्रम के साथ काम को सरल बनाने के लिए कर सकते हैं विकल्पों के प्रारूप पर सम्मेलनों का पालन कर रहा है। अपने उपयोगकर्ताओं को स्थानांतरित करने के लिए मजबूर न करें! मैं इस बारे में विस्तार से लिखूंगा कि यह विकल्प निर्दिष्ट करने के लिए प्रथागत कैसे है, और उन्हें कैसे नाम दिया जाए।
• मददगार - इसका मतलब है कि उपयोगकर्ता को इस बात पर मदद की आसान पहुंच होनी चाहिए कि आवेदन कैसे करता है, इसे कैसे लॉन्च किया जाए और इसे कैसे कॉन्फ़िगर किया जाए। यह सलाह दी जाती है कि एप्लिकेशन अपने पेज को आदमी से जोड़े। इसके अलावा, टीम के पूरा होने के स्तर पर शेल के साथ एकीकरण को चोट नहीं पहुंचेगी।
• दूसरों के साथ अच्छा खेलता है - आवेदन अन्य अनुप्रयोगों के साथ बातचीत करने में सक्षम होना चाहिए। इसका अर्थ है अनुप्रयोगों की प्रतिरूपकता, जैसा कि यूनिक्स में प्रथागत है। आपको रिटर्न कोड की उपेक्षा नहीं करनी चाहिए, इनपुट-आउटपुट धाराओं के साथ विचारशील कार्य और न केवल।
• समझदार चूक है लेकिन विन्यास योग्य है - एक हजार विकल्प निर्दिष्ट किए बिना मानक उपयोग परिदृश्य उपलब्ध होना चाहिए। कस्टम परिदृश्यों का उपयोग करना आसान नहीं है, लेकिन वे अभी भी सस्ती होनी चाहिए। इसके अलावा, विकल्पों का डिफ़ॉल्ट सेट अनुकूलन योग्य होना चाहिए।
• दर्द रहित रूप से स्थापित करता है - आसानी से सभी निर्भरता के साथ स्थापित करता है, आसान स्टार्टअप के लिए पर्यावरण चर के लिए आवेदन पथ सेट करता है। अपडेट आसानी से ही होने चाहिए।
• इनायत से विफल होता है - आवेदन को कॉल करने में त्रुटि के मामले में, यह रिपोर्ट करना चाहिए कि त्रुटि क्या थी और इसे कैसे ठीक किया जाए। इसके अलावा, आवेदन गैर-विनाशकारी होना चाहिए, अर्थात्। यदि कोई त्रुटि तर्कों में की जाती है (और आदर्श रूप से, अगर वह बिना किसी पुष्टि के खतरनाक कार्रवाई नहीं करेगी) तो फाइलों को अधिलेखित या मिटा नहीं करना चाहिए।
• नई सुविधाओं और बग को आसानी से ठीक करता है - आवेदन का समर्थन किया जाना चाहिए। मॉड्यूल में एप्लिकेशन को विभाजित करें और उन्हें विभिन्न फ़ाइलों में बिखेर दें। परीक्षण लिखिए। सिमेंटिक वर्जनिंग का उपयोग करें। एक संस्करण नियंत्रण प्रणाली का उपयोग करें।
• प्रसन्न उपयोगकर्ता - एप्लिकेशन का आउटपुट आंख को भाता है। अपने निपटान के रंगों में, स्वरूपण (उदाहरण के लिए, सारणीबद्ध या html)। इसमें इंटरएक्टिव यूजर इंटरैक्शन भी शामिल है।

अब मैं इन बिंदुओं पर अधिक विस्तार से जाऊंगा।

उपयोग में आसान

उपयोगिताएँ और सॉफ्टवेयर पैकेज। कौन सा अधिक सुविधाजनक है?

इसलिए, सभी एप्लिकेशन सशर्त रूप से दो प्रकारों में विभाजित किए जा सकते हैं: उपयोगिताओं और सॉफ्टवेयर पैकेज (मूल, कमांड सूट में)।

पहला प्रकार अनुप्रयोग है जिसमें एक लक्ष्य, एक मोड ऑपरेशन है। इस प्रकार के कार्यक्रम के अनगिनत उदाहरण हैं, लगभग सभी यूनिक्स कमांड हैं: ls, grep, diff, ... (रूबिस्ट याद कर सकते हैं, उदाहरण के लिए, rspec कमांड) इन कार्यक्रमों की सुविधा यह है कि उनकी क्षमताओं को याद रखना आसान है और भ्रमित होने में अधिक मुश्किल है। इसके अलावा, वे अनुक्रमिक प्रसंस्करण के लिए जंजीरों में गोंद करना आसान है। निम्नलिखित सादृश्य यहाँ प्रासंगिक होगा। कल्पना करें कि आप एक घर बना रहे हैं, इसके अलावा, घर एक मानक मॉडल नहीं है। ईंटों से इसे बनाना बहुत अधिक सुविधाजनक है, और अखंड ब्लॉकों से नहीं, क्योंकि कुछ जगहों पर आपको इन ब्लॉकों को दर्ज करना होगा, और कहीं न कहीं आपको पत्थरों के साथ जोड़ों को बंद करना होगा। हां, और ब्लॉकों को केवल एक क्रेन द्वारा खींचा जा सकता है, जबकि ईंटों को हाथ से रखा जा सकता है।

दूसरे प्रकार के कार्यक्रम की तुलना स्विस चाकू या फूड प्रोसेसर से की जा सकती है। कभी-कभी वे बेहद सुविधाजनक होते हैं। गिट को देखें (माणिक की दुनिया में, मणि, रेल, बंडल को तुरंत याद किया जाता है) - एक कार्यक्रम, लेकिन कितने इसे कर सकते हैं। और वह जांच कर सकती है / कर सकती है, और वह खुद इतिहास में खोजती है, और फाइलों के बीच के बदलावों पर विचार करती है। तो grep, diff, आदि को इसमें बनाया गया है, आपको किसी भी चीज के साथ संयोजन करने की आवश्यकता नहीं है, वह जानता है कि यह कैसे करना है। यदि आप घर के साथ समानता पर वापस जाते हैं, तो गीता के पास हर अवसर के लिए एक मानक परियोजना है (और उन सभी को याद करने की कोशिश करें)।
और फिर भी, सभी कार्यक्रमों को बहुक्रियाशील नहीं होना चाहिए: सभी समान, आप सभी उपयोग के मामलों से नहीं गुजरेंगे। इस थीसिस के समर्थन में, मेरा सुझाव है कि आप एक "मल्टीटूल" की कल्पना करें जो एक कमांड के साथ cd, ls, pwd, diff, df और उपयोगी ऑपरेशंस का एक गुच्छा कर सकता है, केवल विकल्पों को थोड़ा बदलना होगा (उदाहरण के लिए, फाइलसिस्टम परिवर्तन, फाइलसिस्टम शो, फाइलसिस्टम जहां, आदि)। )। क्या आप इसका उपयोग करेंगे? मुझे लगता है कि आप अत्यधिक भारीपन के लिए बाहर फेंक देंगे। हालाँकि सॉफ्टवेयर पैकेज बेहद सुविधाजनक होते हैं, फिर भी यह आपके ध्यान में रखने के लिए आठ सेंटीमीटर के साथ लिखने से पहले समझ में आता है।

वैसे, यदि आपने एक दर्जन उपयोगिताओं को लिखा, और तब महसूस किया कि आप इसे एक सॉफ्टवेयर पैकेज बनाना चाहते हैं, तो इसे ठीक करना इतना मुश्किल नहीं है। बस एक रैपर लिखें जो कमांड को रूट करेगा। आप नहीं जानते होंगे, लेकिन git में git-प्रतिबद्ध, git-show, git-hash-object, git-cat-file, git-update-index इत्यादि जैसी दर्जनों उपयोगिताओं हैं, जिनमें से git कमांड ट्रांसफर कंट्रोल को कमांड के प्रकार के आधार पर नियंत्रित करता है। और विकल्प (बेशक, यूटिलिटी कॉल की एक श्रृंखला एक कमांड के पीछे हो सकती है)। इसलिए छोटे कार्यक्रमों के एक सेट के साथ बड़ी परियोजनाओं को शुरू करना बेहतर है, जिसे आप भविष्य में संयोजित करेंगे। उन्हें लिखना, डिबग करना, बनाए रखना और उपयोग करना आसान है।

कमांड लाइन तर्कों के लिए वाक्यविन्यास या "इस घर की अपनी परंपराएं हैं।"

मैं शब्दावली के साथ शुरू करूँगा। जब आप कमांड लाइन आवेदन शुरू करते हैं, तो आप मापदंडों के कुछ सेट को निर्दिष्ट करते हैं। उन्हें निम्नलिखित प्रकारों में विभाजित किया गया है: विकल्प और तर्क। डेविड कोपलैंड आगे के विकल्पों को दो उपप्रकारों में विभाजित करता है: झंडे और स्विच।
योजनाबद्ध रूप से, आप इसे executable [options] <arguments> रूप में दर्शा सकते हैं executable [options] <arguments> । मुझे लगता है कि सब कुछ अद्यतित है, लेकिन सिर्फ मामले में, मैं समझाऊंगा कि वर्ग कोष्ठक में पैरामीटर वैकल्पिक हैं, और कोण कोष्ठक में अनिवार्य हैं।

तर्क (या स्थिति संबंधी तर्क) ऐसे पैरामीटर हैं जो कार्यक्रम के काम करने के लिए निर्दिष्ट होने चाहिए। उनके आदेश को कड़ाई से परिभाषित किया गया है।
विकल्प वैकल्पिक पैरामीटर हैं। उन्हें किसी भी क्रम में निर्दिष्ट किया जा सकता है।
स्विच प्रकार विकल्प बूलियन विकल्प हैं, कार्यक्रम उनकी उपस्थिति या अनुपस्थिति के लिए जांच करता है। उदाहरण: --ignore-case (या, कभी --no-ignore-case कभी, --no-ignore-case )।
ध्वज प्रकार विकल्प एक पैरामीटर के साथ विकल्प हैं। इस पैरामीटर में एक डिफ़ॉल्ट मान हो सकता है। उदाहरण के लिए, grep -C ... और grep -C 2 ... मेरे संस्करण में, grep उपयोगिताओं के बराबर हैं।
तर्क और विकल्प दोनों में डिफ़ॉल्ट मान हो सकते हैं, लेकिन वे नहीं हो सकते।

एक उदाहरण के रूप में, grep --ignore-case -r - 4 "some string" /tmp तर्क "some string" /tmp , और विकल्प --ignore-case -r - 4 । उसी समय --ignore-case और -r स्विच हैं, और -C 4 एक ध्वज है।

विकल्प कन्वेंशन

विकल्प लघु -i और लंबे समय के --ignore-case रूपों में निर्दिष्ट किए जा सकते हैं। सिद्धांत रूप में, कुछ भी आपको विकल्प प्रारूप के साथ मज़ेदार होने से नहीं रोकता है, क्योंकि आप स्क्रिप्ट में कमांड लाइन विकल्पों को सीधे कैप्चर कर सकते हैं। लेकिन यूनिक्स समुदाय द्वारा विकसित नियमों का पालन करना बेहतर है, क्योंकि वे समय के अनुसार सम्मानित होते हैं, और ज्यादातर लोग उनके लिए उपयोग किए जाते हैं। इसके अलावा, ऐसे तैयार पुस्तकालय हैं जो आपको इन विकल्पों के साथ आसानी से काम करने की अनुमति देते हैं।
ये नियम इस प्रकार हैं:

• एक लंबा विकल्प ( --long-option लंबा विकल्प) दो हाइफ़न के साथ शुरू होता है। विकल्प के नाम में कोई स्थान नहीं हो सकता है, लेकिन एकल हाइफ़न स्वीकार्य हैं।
• लघु विकल्प ( -l ) में एक अक्षर (एक नियम के रूप में, मामला महत्वपूर्ण है) और पूर्ववर्ती हाइफ़न - एक होते हैं। यह सुविधाजनक है जब एक छोटा विकल्प एक लंबे एनालॉग का पहला अक्षर होता है, तो इसका अर्थ याद रखना आसान होता है।
• कुछ छोटे विकल्पों को एक साथ जोड़ा जा सकता है: ls -a -l ls -al बराबर है। एक एकल हाइफ़न के बाद, बिना तर्क के जितने विकल्प चाहिए
• यदि एक छोटे विकल्प में एक पैरामीटर है, तो यह आमतौर पर विकल्प के तुरंत बाद जा सकता है या किसी स्थान से इसे अलग किया जा सकता है। -C 4 या -C 4 । यह कोई संयोग नहीं था कि मैंने कहा "आमतौर पर।" इसलिए, उदाहरण के लिए, मानक ऑप्टपर्स रूबी लाइब्रेरी इन दोनों मामलों को उसी तरह से संभालती है। Ls यूटिलिटी उसी तरह के विकल्पों को संभालती है। लेकिन grep उपयोगिता, उदाहरण के लिए, मानता है कि -C अलग है, और 4 अलग है। शायद यह एक बग है। मैं यह उल्लेख करने में विफल नहीं हो सकता कि अपवाद हैं, लेकिन यदि आपका कार्यक्रम एक और अपवाद बन जाता है, तो उपयोगकर्ता आपके आभारी होने की संभावना नहीं रखते हैं।
  मुझे नहीं पता कि वे आमतौर पर कैसे करते हैं जब एक छोटे विकल्प में एक डिफ़ॉल्ट मान ( -c [param] ) के साथ एक गैर-संख्यात्मक पैरामीटर होता है, क्योंकि -cxyz को - xyz और as -c -x -y -z दोनों के रूप में व्याख्या किया जा सकता है । यदि विकल्प में वैकल्पिक पैरामीटर है तो उपयोगकर्ता के लिए हमेशा स्पेस लिखना बेहतर होता है। प्रोग्रामर के लिए पहले से सोचना बेहतर है कि कैसे एक साथ लेखन विकल्पों से जुड़ी समस्याओं को कम से कम किया जाए।
• एक लंबे विकल्प के मामले में, आमतौर पर पैरामीटर से पहले एक स्थान की अनुमति दी जाती है, लेकिन समान चिह्न का उपयोग करना उचित है। ls --width=10 या ls --width 10
  एक विभाजक के बिना, एक लंबे विकल्प के बाद, पैरामीटर को संकेत नहीं दिया जाता है (अपने लिए जज करें कि भ्रम क्या निकलेगा, खासकर यदि पैरामीटर संख्यात्मक नहीं है)।
• प्रत्येक विकल्प छोटा या लंबा हो सकता है। या यह हो सकता है कि केवल छोटा या केवल लंबा हो। हालांकि, प्रत्येक विकल्प के लिए एक लंबे फॉर्म की उपस्थिति अत्यधिक वांछनीय है।
• बूलियन विकल्पों के लिए, आप वैकल्पिक no- उपसर्ग निर्दिष्ट कर सकते हैं, उदाहरण के लिए: --[no-]pager । --[no-]pager । --no-pager विकल्प पेजेशन सेट करता है, --no-pager इंगित करता है कि पेजिंग नहीं होना चाहिए, और विकल्प की अनुपस्थिति डिफ़ॉल्ट मान को संरक्षित करती है। यह विशेष रूप से महत्वपूर्ण है जब विकल्प डिफ़ॉल्ट रूप से कॉन्फ़िगर करने योग्य होते हैं। एक उपसर्ग के बिना, उदाहरण के लिए, एक विकल्प के डिफ़ॉल्ट मूल्य को ओवरराइड करना असंभव होगा।

हमेशा एक लंबा विकल्प रखना क्यों उचित है

विकल्पों का लंबा रूप आमतौर पर आपके एप्लिकेशन का उपयोग करके स्क्रिप्ट लिखने में उपयोग किया जाता है। लंबे विकल्प को स्व-दस्तावेजीकरण किया जाना चाहिए। कल्पना कीजिए कि sysadmin क्रोन में दिखता है और डेटाबेस बैकअप कार्य को -zsf -m 100 विकल्प -zsf -m 100 साथ लॉन्च करता है। यदि वह स्क्रिप्ट का लेखक नहीं है, तो उसे समझने के लिए मदद में क्रॉल करना होगा कि इसका क्या मतलब है। सहमत --scheme --max-size 100 --gzip --force , विकल्प का सेट --scheme --max-size 100 --gzip --force उसे बहुत अधिक बताएगा और उसे बहुत अधिक समय बर्बाद नहीं करेगा।
इसके अलावा, शायद ही कभी इस्तेमाल किए गए विकल्पों के लिए छोटे विकल्प बनाने की सिफारिश नहीं की जाती है। सबसे पहले, वर्णमाला विकल्प में उन्हें हर चीज पर खर्च करने के लिए वर्णमाला में इतने सारे अक्षर नहीं हैं। दूसरे, और इससे भी महत्वपूर्ण बात, एक छोटे विकल्प की अनुपस्थिति उपयोगकर्ता को बताती है कि यह विकल्प सामान्य ऑपरेशन के दौरान द्वितीयक या अवांछनीय है, और यह कि आपको इसे बिना सोचे-समझे उपयोग नहीं करना चाहिए, बस इसलिए कि आप कर सकते हैं।
तो, अक्सर उपयोग किए जाने वाले विकल्प छोटे और लंबे दोनों होते हैं, और शायद ही कभी इस्तेमाल किए जाने वाले विकल्प केवल लंबे होते हैं।

एकल-फ़ंक्शन और बहु-फ़ंक्शन अनुप्रयोगों के लिए कमांड-लाइन विकल्पों में अंतर

इन दो प्रकार के अनुप्रयोगों में तर्कों का एक अलग क्रम होता है जब बुलाया जाता है।
पहले प्रकार के आवेदन के लिए, कॉल आमतौर पर इस तरह दिखता है: executable [options] <arguments>
सॉफ़्टवेयर पैकेज के लिए, प्रारूप कुछ अधिक जटिल है: executable [global options] <command> [command options] <arguments>
यहाँ पुस्तक का एक उदाहरण दिया गया है: git --no-pager push -v origin_master --no-pager एक विकल्प है जिसे किसी भी git कमांड पर लागू किया जा सकता है, और -v पुश कमांड के लिए विशिष्ट विकल्प है। यह ध्यान दिया जाना चाहिए कि एक आदेश के लिए विशिष्ट वैश्विक विकल्प और विकल्प एक ही नाम हो सकते हैं। लेकिन इस मामले में, सभी उपकरण उन्हें संसाधित करने के लिए उपयुक्त नहीं हैं, उदाहरण के लिए, मानक OptionParser माणिक पुस्तकालय इस कार्य के साथ सामना नहीं करेगा, क्योंकि यह इस बात में अंतर नहीं करता है कि विकल्प किस स्थान पर मिला। यदि आप एक सॉफ्टवेयर पैकेज बना रहे हैं, तो GLI लाइब्रेरी का बेहतर उपयोग करें।

बस मामले में, मैं पाठक को याद दिलाता हूं कि तकनीकी रूप से इनपुट कार्यक्रमों को मापदंडों का एक स्ट्रिंग नहीं मिलता है, लेकिन पहले से ही तत्वों में विभाजित मापदंडों का एक सरणी। माणिक्य में, इस सरणी को ARGV कहा जाता है। यह उसके साथ है कि हम काम करते हैं, सीधे या विशेष पुस्तकालयों की मदद से। यह ध्यान दिया जाना चाहिए कि यह तत्वों द्वारा रिक्त स्थान में विभाजित नहीं है (अन्यथा यह नहीं हो सकता है, उदाहरण के लिए, रिक्त स्थान के साथ फ़ाइल नाम), शेल में थोड़ा अधिक जटिल नियम हैं। इसमें पात्रों से बचना और समूहन के लिए उद्धरण चिह्नों का उपयोग करना भी शामिल है। यदि आपको ऐरे में स्क्रीन, ग्लू या कट के पैरामीटर स्ट्रिंग्स की जरूरत है और इसके विपरीत - मानक शेलवर्ड्स लाइब्रेरी देखें। इसमें इन उद्देश्यों के लिए सिर्फ तीन विधियाँ शामिल हैं: String#shellsplit , String#shellescape और Array#shelljoin ।

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

उपयोगी

आप पहली बार जब आप उपयोग करने जा रहे हैं, तो उस भयानक_प्रोग्राम कार्यक्रम को देखें। एक अनुभवी उपयोगकर्ता के रूप में, आप शायद तर्कों के क्रम, विकल्पों का एक सेट और उपयोग के उदाहरणों को देखने की उम्मीद में awesome_program --help टाइप करेंगे। जब आप अपना कार्यक्रम जारी करते हैं, तो याद रखें कि जिस उपयोगकर्ता ने पहली बार देखा था, वह संभवतः वही पहला काम करेगा, इसलिए आपके पास -h , --help विकल्प तैयार हैं। यदि आप एक प्रकार की OptionParser की लाइब्रेरी का उपयोग करते हैं, तो सभी विकल्पों की एक सूची जो प्रोग्राम आपके द्वारा दिए गए विवरणों के साथ पहचानता है, स्वचालित रूप से प्रॉम्प्ट लाइन में जोड़ दी जाएगी।

हेल्प लाइन के अलावा, यह मनुष्य में विस्तारित मदद लिखने के लिए समझ में आता है। हालाँकि, जहाँ तक मुझे पता है, रूबाइम्स स्वचालित रूप से आदमी में पेज सेट नहीं करती हैं। हालांकि, एक मणि-मणि मणि है जो आपको सिस्टम में स्थापित रत्नों के लिए मैन डॉक्यूमेंटेशन पेज प्रदर्शित करने की अनुमति देता है।
मैन-डॉक्यूमेंटेशन बनाने के लिए एक मुश्किल nroff प्रारूप में एक फ़ाइल बनाना आवश्यक है। कार्य को सरल बनाने के लिए, ronn कनवर्टर लाइब्रेरी का उपयोग करें, जो आपको सरल प्रारूप में प्रलेखन पृष्ठ लिखने की अनुमति देता है। जब सब कुछ तैयार हो जाता है, तो आप gem man awesome_gem उपयोग कर सकते हैं gem man awesome_gem - और हेल्प लाइन देखें वैकल्पिक रूप से, आप alias gem='gem man -s' लिख सकते हैं। इस मामले में, मैन कमांड को मणि मैन कमांड द्वारा बदल दिया जाता है, जो मनुष्य को रत्नों की मदद लेने की अनुमति देता है। उन अनुरोधों के लिए जो मणि-आदमी प्रक्रिया नहीं कर सकता था, एक नियमित आदमी के संबंधित पृष्ठ पर एक स्वचालित पुनर्निर्देशन होता है।
यदि आप अपने स्वयं के मैन-टिप्स बनाने की योजना बना रहे हैं, तो पुस्तक को देखें, इस पर बहुत अधिक ध्यान दिया जाता है।

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

टैब को पूरा करने के लिए और प्रोग्राम के अंदर कमांड्स के इतिहास को स्टोर करने के लिए (आईआरबी जैसे कार्यक्रमों में इंटरैक्टिव मोड में), यह माणिक में निर्मित रीडलाइन लाइब्रेरी का उपयोग करने के लिए पर्याप्त है। यह आपको स्वचालित रूप से सभी दर्ज किए गए आदेशों के इतिहास को सहेजने की अनुमति देता है - प्राप्त करने के बजाय Readline.readline कमांड का उपयोग करके।

टैब-समापन इस प्रकार किया जाता है: Readline.completion_proc=(block) पद्धति से एक Readline.completion_proc=(block) लौटाया जाता है, जो पहले से ही दर्ज किए गए पाठ की एक पंक्ति में संभावित जोड़ की एक सरणी लौटाता है, वह पूरा काम है। उदाहरण के लिए:

 Readline.completion_proc = proc { |input| allowed_commands.grep /^#{input}/ } 

यदि आपको पहले से चल रहे कार्यक्रम के स्तर पर नहीं, बल्कि शेल के स्तर पर टैब-समापन की आवश्यकता है, तो यह कुछ अधिक जटिल है। आपको .bashrc साथ टिंकर करना होगा।
सबसे पहले, लाइन को complete -F get_my_app_completions my_app
अब हर बार जब आप my_app()[- ] टाइप my_app()[- ] , और तब टैब कुंजी, get_my_app_completions फ़ंक्शन को बुलाया जाएगा। इस फ़ंक्शन को COMPREPLY वैरिएबल के लिए संभावित ऑटो-पूर्ण विकल्प वापस करना चाहिए, जो शेल उपयोगकर्ता को परिवर्धन के लिए संभावित विकल्प प्रदान करने के लिए उपयोग करेगा। .bashrc आपको इस फ़ंक्शन को परिभाषित करने की आवश्यकता है। मैं todo आवेदन के लिए एक पुस्तक से एक उदाहरण दूंगा:

 function get_todo_completions() { if [ -z $2 ] ; then #    COMPREPLY=(`todo help -c`) else #      ,   $2 COMPREPLY=(`todo help -c $2`) fi } complete -F get_todo_completions todo 

अब कार्यक्रम में आपको निम्नलिखित व्यवहार को लागू करने की आवश्यकता है (चलो इसे एक आसान अभ्यास के रूप में छोड़ दें):
1) यदि आप कमांड लाइन पर todo help -c टाइप करते हैं, तो आपको एप्लिकेशन कमांड्स की एक सूची todo help -c चाहिए: सूची, ऐड, कम्प्लीट, हेल्प (प्रत्येक अपनी लाइन पर)
2) यदि आप todo help -c complete , तो आपको उन सभी कार्यों की सूची todo help -c complete चाहिए जो शुरू हो चुके हैं, लेकिन अभी तक पूरे नहीं हुए हैं (जिन्हें आप पूरा कमांड लागू कर सकते हैं)।

help -c [...] एक सेवा कमांड है, इसकी उपस्थिति को संक्षिप्त मदद में छोड़ा जा सकता है। यह माना जाता है कि यह उपयोगकर्ता द्वारा उपयोग नहीं किया जाएगा, लेकिन उस स्क्रिप्ट को .bashrc ।
इस स्क्रिप्ट में, फ़ंक्शन स्वयं उस एप्लिकेशन से पूछता है कि जो पहले से टाइप किया गया है, उसके आधार पर प्रतिस्थापित किया जा सकता है (यह help - विकल्प के बाद पास किया गया है)। कार्यक्रम उस स्थिति की निगरानी करता है जब एप्लिकेशन को ऐसे विशेष मापदंडों का सेट दिया जाता है, और मानक आउटपुट में सभी विकल्पों की सूची प्रदर्शित करता है (जैसा कि आप पहले ही देख चुके हैं), जहां से उन्हें सीधे शेल स्क्रिप्ट COMPREPLY भेजा जाता है।
पुस्तक में लेखक अपनी स्वयं की GLI लाइब्रेरी का उपयोग करता है, जो स्वचालित रूप से इस तरह के विकल्पों को ट्रैक करता है। आप जीएलआई की मदद के बिना इस सुविधा को आसानी से लागू कर सकते हैं। जैसा कि आप देख सकते हैं, यहां कोई जादू नहीं है।

दूसरों के साथ अच्छा खेलता है

हम कार्यक्रमों के बीच सुविधाजनक बातचीत की आवश्यकता के मुद्दे पर चर्चा नहीं करेंगे, हर कोई जो यूनिक्स पर काम करता है, वह मूल्यांकन कर सकता है कि यह कितना महत्वपूर्ण है। मुख्य प्रश्न यह है कि इसे कैसे प्राप्त किया जाए।

कोड वापस करें

सबसे पहले, रिटर्न कोड का उपयोग करें। कार्यक्रम के सफल समापन के मामले में - 0, एक त्रुटि के मामले में - विभिन्न गैर-शून्य रिटर्न कोड। यह महत्वपूर्ण है क्योंकि शेल स्क्रिप्ट यह निर्धारित कर सकती है कि क्या किसी प्रोग्राम ने $? चर से अंतिम पूर्ण प्रोग्राम की स्थिति का अनुरोध करके ठीक काम किया है $? । वापसी की स्थिति वापस करने के लिए, माणिक exit(exit_status) विधि का उपयोग करता है।
यदि आप अलग-अलग त्रुटियों के लिए अलग-अलग रिटर्न कोड असाइन करते हैं, तो एक मौका है कि आपका उपयोग करने वाला एक अन्य कार्यक्रम यह तय करने में सक्षम होगा कि क्या समस्या को ठीक किया जा सकता है, और क्या यह बिल्कुल भी ध्यान देने योग्य है। कार्यक्रम के बाहर, यह देखना बेहतर है कि यह डरावना है कि कार्यक्रम "दुर्घटनाग्रस्त" हुआ या नहीं। अलग-अलग रिटर्न कोड अलग-अलग अपवाद वर्गों की तरह हैं, हो सकता है कि आपके पास इस तथ्य में त्रुटि हो कि कोई रैम नहीं है, या शायद केवल नेटवर्क एक सेकंड के लिए गायब हो गया और यह फिर से कोशिश करने लायक है। कुछ प्रोग्राम कई त्रुटियों से एक साथ दुर्घटनाग्रस्त हो सकते हैं। यदि आपको एक साथ कई समस्याओं की रिपोर्ट करने की आवश्यकता है, तो बिट मास्क का उपयोग करें। नेटवर्क में सिफारिशें होती हैं कि कौन से रिटर्न कोड्स का उपयोग करना है, किन त्रुटियों के लिए, आप इसके बारे में GNU (बहुत सामान्य) और FreeBSD (बहुत विशिष्ट) साइटों पर पढ़ सकते हैं। यदि आप त्रुटि कोड से परेशान नहीं होना चाहते हैं, तो कम से कम न्यूनतम प्रयास करें - त्रुटि के मामले में कम से कम कुछ गैर-शून्य मान लौटाएं। अन्यथा, अन्य प्रोग्राम भी पता नहीं लगा पाएंगे कि क्या आपका प्रोग्राम सामान्य रूप से काम करता है।

वैसे, आप न केवल शेल स्क्रिप्ट से, बल्कि रूबी स्क्रिप्ट से भी प्रोग्राम चला सकते हैं। ऐसा करने के लिए कई विकल्प हैं, उदाहरण के लिए Kernel.system या IO.popen प्रलेखन में उनके बारे में और पढ़ें। यदि आप system का उपयोग करके किसी अन्य प्रोग्राम को कॉल करते system , तो क्या आप एक समान शेल वैरिएबल $? में इसके रिटर्न कोड का पता लगा सकते हैं $? ।

I / O स्ट्रीम और एरर स्ट्रीम। Pipi

कमांड लाइन से लॉन्च किए गए कार्यक्रमों की बातचीत का मुख्य तरीका पाइप है। एक पाइप एक प्रोग्राम के आउटपुट को दूसरे के इनपुट पर पुनर्निर्देशित करने का एक तरीका है। एक ऊर्ध्वाधर पट्टी के साथ चिह्नित पाइप | । उदाहरण के लिए, ls | sort ls | sort , पहला भाग - ls स्क्रीन पर कुछ भी प्रदर्शित नहीं करता है, बल्कि इसके आउटपुट को सॉर्ट प्रोग्राम के इनपुट पर पुनर्निर्देशित करता है। और सॉर्ट प्रोग्राम इनपुट स्ट्रीम लाइन से टेक्स्ट को लाइन में लेता है और स्क्रीन पर पहले से सॉर्ट की गई सूची प्रदर्शित करता है। एक ओर, ls स्वयं ही फ़ाइलों को सॉर्ट कर सकता है, लेकिन यह इसके लिए अभिप्रेत नहीं है। उसी समय, इस उद्देश्य के लिए सॉर्ट की आवश्यकता होती है और इसके कई विकल्प होते हैं। उदाहरण के लिए, आप पंक्तियों को क्रमबद्ध नहीं कर सकते हैं यदि नाम एक संख्या से शुरू होता है (अन्यथा आदेश निम्नानुसार होगा: 1.jpg, 10.jpg, 100.jpg, 2.jpg, ...)। या रिवर्स ऑर्डर में सॉर्ट करें। इसके अलावा, विशेष कार्यक्रमों (जैसे कि awk, sed) की मदद से, स्ट्रिंग को छांटने से पहले, आप इसे सही कर सकते हैं (उदाहरण के लिए, उपसर्ग मिटाएं)। यह ध्यान दिया जाना चाहिए कि पाइप एक अनियंत्रित कार्यक्रमों से बना हो सकता है। तो ls | sort -n | tail ls | sort -n | tail ls | sort -n | tail संख्या द्वारा क्रमबद्ध फाइलों की सूची की अंतिम दस पंक्तियों को प्रदर्शित करेगी।

इस बारे में सोचें कि आपको अपने कार्यक्रम में इनपुट और आउटपुट स्ट्रीम की आवश्यकता क्यों हो सकती है। आप आउटपुट स्ट्रीम में क्या लिखते हैं, और एरर स्ट्रीम क्या है। हम पहले दूसरे प्रश्न से निपटेंगे: आउटपुट स्ट्रीम (स्टडआउट) और एरर्स (स्टडर) में क्या अंतर है? तथ्य यह है कि एक धागा पाइप में जाता है, और दूसरा नहीं करता है। Stderr स्ट्रीम का उपयोग न केवल त्रुटियों के उत्पादन के लिए किया जाता है, बल्कि कार्य प्रक्रिया के बारे में किसी भी जानकारी को आउटपुट करने के लिए भी किया जाता है, जैसे कि प्रोग्राम निष्पादन का चरण, डिबगिंग की जानकारी आदि। यह जानकारी किसी अन्य प्रोग्राम के इनपुट को नहीं मिलनी चाहिए, यह केवल उपयोगकर्ता की सुविधा के लिए आवश्यक है। स्टडआउट स्ट्रीम का उपयोग अन्य सभी जानकारी के लिए किया जाता है, जैसे कि किसी प्रोग्राम का परिणाम।

आपको आउटपुट प्रारूप के बारे में सोचने की ज़रूरत है, क्योंकि न केवल एक व्यक्ति, बल्कि एक मशीन को भी आपके प्रोग्राम के आउटपुट के साथ काम करना होगा। यह विकल्प बनाने के लिए समझ में आता है --format=<plain|csv|pretty|html|table|...> । मानव-पठनीय प्रारूप (सुंदर / html / तालिका) निर्दिष्ट करते समय, आप जानकारी को इस तरह से प्रदर्शित कर सकते हैं जो पार्सिंग आउटपुट की सुविधा के बारे में सोचे बिना आंख को प्रसन्न करती है। जब आप एक मशीन-पठनीय प्रारूप (सादे / सीएसवी) निर्दिष्ट करते हैं, तो यह आपके लिए महत्वपूर्ण नहीं है कि परिणाम सुंदर दिखता है या नहीं - मुख्य बात यह है कि इसे पार्स करना आसान है। पार्सिंग सुविधा के लिए, टैब-सीमांकित मान या अल्पविराम से अलग किए गए मान (सीएसवी) का उपयोग करें, या प्रारूप एक पंक्ति है - एक मान, या एक और प्रारूप जो आपको सबसे अच्छा लगता है। हम इस बारे में भी बात करेंगे कि निष्कर्ष कैसे बनाया जाए जो डिलाइट यूजर्स सेक्शन में किसी व्यक्ति के लिए जितना संभव हो उतना सुखद हो।
उपयोगकर्ता प्रोग्राम लॉन्च होने पर हर बार आउटपुट प्रारूप को इंगित नहीं करना चाहता है, और सभी अवसरों के लिए एक चुनना भी हमेशा संभव नहीं होता है। क्या कोई चाल है जो स्वचालित रूप से निर्धारित करेगी कि आउटपुट किसी व्यक्ति या मशीन की आंखों के लिए है, अर्थात् IO#tty? विधि IO#tty? । $stdout.tty? कॉल करें $stdout.tty? आपको बताएगा कि आपका आउटपुट टर्मिनल को निर्देशित किया गया है या नहीं। यदि नहीं, तो आपके प्रोग्राम का आउटपुट पाइप पर निर्देशित है या फ़ाइल पर पुनर्निर्देशित किया गया है (निम्नानुसार: ls > output.txt )। टर्मिनल के लिए निर्देशित आउटपुट के लिए और आउटपुट के लिए पुनर्निर्देशित स्ट्रीम के लिए, आप विभिन्न डिफ़ॉल्ट स्वरूपण options[:format] = $stderr.tty? ? 'table' : 'csv' चुन सकते हैं: options[:format] = $stderr.tty? ? 'table' : 'csv' options[:format] = $stderr.tty? ? 'table' : 'csv'
और यदि आप चाहते हैं, उदाहरण के लिए, किसी व्यक्ति के लिए आउटपुट आउटपुट स्वरूप में फ़ाइल में परिणाम के लिए, बस प्रारूप को स्पष्ट रूप से निर्दिष्ट करें।

अब बात करते हैं इनपुट स्ट्रीम की। इनपुट स्ट्रीम से प्रोग्राम को क्या डेटा स्वीकार करना चाहिए? यह, निश्चित रूप से, कार्यक्रम की बारीकियों पर निर्भर करता है। आइए सोचते हैं, इनपुट स्ट्रीम में कौन सा डेटा आ सकता है? स्पष्ट उत्तर वह है जो अन्य प्रोग्राम के आउटपुट पर है। उदाहरण के लिए, मेरे पास एक प्रोग्राम है जो एक मैट्रिक्स फाइल को एक अलग प्रारूप में परिवर्तित करता है और एक फाइल को एक अलग एक्सटेंशन के साथ लिखता है। क्या यह इनपुट स्ट्रीम से मैट्रिसेस को स्वीकार करने का कोई मतलब है? मेरी राय में, यह नहीं है: यह मैट्रिक्स इनपुट स्ट्रीम में कैसे और क्यों मिलता है? एक बार में बहुत सारी फ़ाइलों को संसाधित करने के लिए फ़ाइल नामों का एक गुच्छा स्वीकार करना अधिक सुविधाजनक होगा। यह वह डेटा है जो ls कमांड दे सकता है, उदाहरण के लिए।
आप इस दृष्टिकोण के साथ बहस कर सकते हैं, क्योंकि आप एक स्क्रिप्ट लिख सकते हैं जो फ़ाइलों की सूची पर पुनरावृत्ति करेगा और कई बार कार्यक्रम चलाएगा। लेकिन फिर आप इसे कमांड लाइन से एक I / O रीडायरेक्ट के साथ सीधे करने का अवसर खो देते हैं, आपको एक लूप लिखना होगा। इसके अलावा, कुछ कार्यक्रम लंबे समय तक शुरू होते हैं और जल्दी से काम करते हैं, इसलिए आप एक सेकंड नहीं, बल्कि एक सौ एक सौ मैट्रिसेस खर्च कर सकते हैं (अफसोस, यह एक बहुत ही वास्तविक है - और यहां तक ​​कि आशावादी - समय स्केल जब एक विंडोज सिस्टम पर मणि से कई स्क्रिप्ट का उपयोग शुरू होता है) । लेकिन, किसी भी मामले में, चुनाव आपका है। जो उचित है उसे करो और मैनुअल में इसका वर्णन करना मत भूलना।
वैसे, क्या यह एक अन्य प्रोग्राम के लिए संभव है जो हम पहले से ही ज्ञात विधि को कॉल करके अपनी स्क्रिप्ट के इनपुट में डेटा स्थानांतरित कर सकें$stdin.tty?

संकेत

अंत में, एक और तरीका है कि कार्यक्रम संचार कर सकते हैं (बिना खाते में सॉकेट और उनसे जुड़ी सब कुछ) संकेत के लायक है - संकेत। मान लीजिए कि आपके पास एक लंबी चलने वाली प्रक्रिया है, उदाहरण के लिए, एक वेब सर्वर, और आपको उसे रिबूट किए बिना नए कॉन्फ़िगरेशन को पढ़ने के लिए कहने की आवश्यकता है। आप उसे एक संकेत (आमतौर पर SIGHUP) भेज सकते हैं, और वह, उसे रोकते हुए, वही करेगा जो वे उससे पूछते हैं। या हैंडलर को SIGINT सिग्नल पर लटकाएं, जो Ctrl + C दबाकर प्रोग्राम को सटीक रूप से समाप्त कर देगा। यह सब विधि द्वारा हासिल किया जाता हैSignal.trap। यह विधि संकेत के नाम के रूप में लेती है और उस ब्लॉक को निष्पादित किया जाता है जब निर्दिष्ट संकेत कार्यक्रम में आता है। यह काम करता है (साथ ही साथ थ्रेड पुनर्निर्देशन, वैसे) सभी POSIX सिस्टम में, अर्थात। यूनिक्स और विंडोज दोनों पर। हालांकि, यह संभव है कि विंडोज में समर्थित संकेतों का सेट यूनिक्स की तुलना में छोटा होगा, इसलिए यदि आप एक क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन की तलाश कर रहे हैं, तो सिग्नल पूरी तरह से परीक्षण करने के लिए एक जगह है।
यहां यह सुनिश्चित करने का एक उदाहरण है कि कैसे Ctrl + C दबाकर प्रोग्राम पहले अधूरी फ़ाइलों को साफ करता है, और फिर यह बंद हो जाता है, त्रुटि कोड लौटाता है:

 Signal.trap("SIGINT") do FileUtils.rm output_file exit 1 end 

समझदार चूक है लेकिन विन्यास योग्य है

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

मानक स्क्रिप्ट के बारे में, सब कुछ स्पष्ट है। यह सोचने की आवश्यकता है कि कार्यक्रम का उपयोग क्यों किया जाएगा और डिफ़ॉल्ट रूप से सबसे लोकप्रिय मापदंडों का चयन करें।
सभी उपयोगकर्ताओं की ज़रूरतें थोड़ी अलग हैं, इसलिए अपनी स्क्रिप्ट का यथासंभव उपयोग करने के लिए अधिक विकल्पों के बारे में सोचें। यदि आपका आवेदन एक कार्य करेगा, लेकिन लचीले ढंग से कॉन्फ़िगर किया जाएगा (उचित सीमा के भीतर), तो उपयोगकर्ता आपको धन्यवाद देंगे। यदि लागू हो तो गैर-मानक स्क्रिप्ट होनी चाहिए। यह डरावना नहीं है यदि आपको उन्हें निष्पादित करने के लिए बहुत सारे विकल्प निर्दिष्ट करने हैं - उपयोगकर्ता दो बार सोचेंगे कि क्या आपकी स्क्रिप्ट का इरादा है। मुझे आपको दुर्लभ विकल्पों को लंबा करने और इस तरह के विकल्पों ( --use-nonstandard-modeबजाय -u) के लिए एक छोटा संस्करण प्रदान करने की सिफारिश की याद दिलाता है ।

मैं अंतिम बिंदु पर अधिक विस्तार से ध्यान केन्द्रित करूंगा। "विकल्पों का डिफ़ॉल्ट-सेट अनुकूलन योग्य होना चाहिए" क्या है? कल्पना करें कि कई लोग आपके कार्यक्रम का उपयोग करते हैं और अक्सर करते हैं। उदाहरण के लिए, आपने डेटाबेस बैकअप के लिए उपयोगिता लिखी है। आपका सिस्टम प्रशासक हर दिन उपयोगिता का उपयोग करता है और डिफ़ॉल्ट रूप से (उदाहरण के लिए --no-scheme --gzip) विकल्प का एक सेट टाइप करके उपयोग करता है db_backup my_db।
लेकिन व्यवस्थापक कार्यक्रम के अलावा, आपके सहयोगियों का उपयोग डेवलपर्स द्वारा किया जाता है, जिनके डेटाबेस स्कीमा हर दिन बदलते हैं। और उन्हें हर दिन लिखने के लिए मजबूर किया जाता है db_backup --scheme my_db, उन्हें इस कुंजी को नहीं भूलना चाहिए। आप सही हो सकता है, आप कहते हैं कि sisadminskie सेटिंग्स और महत्वपूर्ण सेटिंग्स डिफ़ॉल्ट रहे हैं ... लेकिन वास्तविकता में वहाँ और अधिक विकल्प हो सकता है और होगा अगर --login, --password, --host,--force, और ऐसे मापदंडों का एक सेट पहले से ही त्रुटियों के बिना पुन: पेश करना मुश्किल है, यहां तक ​​कि एक सिस्टम प्रशासक भी जिसकी अन्य सेटिंग्स डिफ़ॉल्ट रूप से जाती हैं। सिस्टम प्रशासक या प्रोग्रामर को इन सभी मापदंडों को दर्ज करने और हर बार सेटिंग्स के बारे में सोचने के लिए मजबूर न करें, क्योंकि आप डिफ़ॉल्ट मान को कॉन्फ़िगर करने योग्य बना सकते हैं।

इसके लिए व्यू फाइल्स का उपयोग किया जाता है ~/.myapp.rc। फ़ाइल में कोई जादू नहीं है, यह सिर्फ एक समझौता है। अपने होम डायरेक्टरी में प्रत्येक उपयोगकर्ता अपनी पसंदीदा डिफ़ॉल्ट सेटिंग्स के साथ एक फ़ाइल बना सकता है। होम निर्देशिका में - ताकि विभिन्न उपयोगकर्ता अलग-अलग चूक सेट कर सकें। फ़ाइल की शुरुआत में बिंदु इसे छिपाना है। .Rc विस्तार परंपरा के लिए एक श्रद्धांजलि है।
इस फ़ाइल में क्या संग्रहीत किया जाना चाहिए? बस उन विकल्पों को सूचीबद्ध करना जो डिफ़ॉल्ट चूक से अलग हैं। इस कॉन्फ़िगरेशन फ़ाइल के लिए YAML प्रारूप का उपयोग करना बेहद सुविधाजनक है। मैं एक उदाहरण दूंगा:

 --- :gzip: false :force: true :user: "Bob" :password: "Secr3t!" 

विचार करें कि इन विकल्पों को कैसे डाउनलोड किया जाए।

 require 'yaml' require 'optparse' #  - options = { :gzip => true, :force => false } #     # (     ,    HOME) CONFIG_FILE = File.join(ENV['HOME'],'.db_backup.rc.yaml') if File.exists? CONFIG_FILE #     config_options = YAML.load_file(CONFIG_FILE) #     -     options.merge!(config_options) end #       #       ,    option_parser = OptionParser.new do |opts| #    . #__FILE__    ,        opts.banner = "Usage: #{__FILE__} [options] <db_name>" #   -u  --username   ,     opts.on("-u USER", "--username", "Database username, in first.last format") do |user| options[:user] = user end #     ,      opts.on("-p PASSWORD", "--password", "Database password") do |password| options[:password] = password end #     ,     .   ,   . #   --gzip      true. #      ,     - #     false     --no-gzip opts.on("--[no-]gzip", "Compress or not the backup file") do |gzip| options[:gzip] = gzip end end #       ,    option_parser. #    ARGV    , #        options # (     ) option_parser.parse!(ARGV) #    db_name = ARGV.shift 

यदि आपके पास सॉफ़्टवेयर पैकेज को कॉन्फ़िगर करने का कार्य है - यह उसी कॉन्फ़िगरेशन फ़ाइल में किया जाता है। केवल हैश में इस समय वैश्विक विकल्प और नेस्टेड हैश में प्रत्येक कमांड के विकल्प दोनों होने चाहिए।

 --- :filename: ~/.todo.txt :url: http://jira.example.com :username: davec :password: S3cr3tP@ss :commands: :new: :f: true :group: Analytics Database :list: :format: pretty :done: {} 

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

दर्द रहित रूप से स्थापित करता है

स्थापना प्रक्रिया बहुत जटिल होने पर कोई भी बहुत अच्छे एप्लिकेशन का उपयोग नहीं करेगा। सौभाग्य से, माणिक की दुनिया में, माणिक्य है - एक पैकेज प्रबंधक जो आपको एक पंक्ति में प्रोग्राम स्थापित करने और अपडेट करने की अनुमति देता है: एक
gem install/update gemname

रत्न एक पैकेज होता है जिसमें स्रोत कोड होते हैं, साथ ही संस्करण संख्या और लेखक, पैकेज का विवरण, साथ ही साथ निर्भरता का एक सेट (जिसके बारे में जानकारी होती है) कौन से रत्न आपके पुस्तकालय या आपके अनुप्रयोग द्वारा उपयोग किए जाते हैं)। डिफ़ॉल्ट रूप से, सभी रत्न rubygems.org सर्वर पर प्रकाशित होते हैं। इसके लिए धन्यवाद, रत्नों को स्थापित करते समय, आपको यह नहीं देखना होगा कि पैकेज को कहाँ से डाउनलोड करना है, यह सभी के लिए सामान्य रूप से सर्वर पर स्थित है (बेशक, आप कॉरपोरेट रत्नों के सर्वर को अलग से कॉन्फ़िगर कर सकते हैं ताकि अपने रत्नों को बाहरी लोगों को न दें) और मणि प्रोग्राम स्वचालित रूप से रत्नों को डाउनलोड करने के लिए उपयोग करता है।
जब आप कमांड निष्पादित करते हैंgem install, पैकेज प्रबंधक रूबीगैम सर्वर पर दिए गए नाम के साथ एक पैकेज की तलाश करता है और यह पता करता है कि अन्य रत्नों (और कौन से विशिष्ट संस्करणों) को काम करने की आवश्यकता है। फिर वह सभी आवश्यक पैकेजों को डाउनलोड करता है और उन्हें स्थापित करता है, मूल कोड को संकलित करता है, जो निष्पादन योग्य के रूप में निर्दिष्ट फ़ाइलों को चलाने के लिए संभव बनाता है (ये माणिक स्क्रिप्ट हो सकते हैं, न कि केवल बायनेरिज़)। प्रणाली में, एक मणि किसी भी संख्या में संस्करणों में खड़ा हो सकता है, प्रत्येक संस्करण की निर्भरता संस्करणों का अपना सेट हो सकता है और संघर्ष का कारण नहीं हो सकता है। उदाहरण के लिए, यदि आपके पास 2.3.8 और रेल 3.2 हैं, तो उनमें से प्रत्येक एक्टिवासुपोर्ट के अपने संस्करण को संदर्भित करेगा, जिसके साथ यह सुसंगत है।

मैंने रत्नों को बनाने के बारे में नहीं लिखा, यह पहले से ही हैबे पर एक उत्कृष्ट लेख थायदि आप अभी भी यह नहीं जानते हैं कि यह कैसे करना है - तो अभी अपने आप को मेरे लेख से दूर कर दो और अपना आधा घंटा इस मुद्दे पर बिताओ। यह बहुत सरल, बहुत सुविधाजनक और महत्वपूर्ण है यदि आप रूबी जारी रखने का इरादा रखते हैं।
जब आप अपना रत्न बनाते हैं, तो आपको संस्करण संख्या को इंगित करना होगा। सिमेंटिक वर्जनिंग नामक एक बहुत सुसंगत समझौता है। संस्करण प्रारूप में तीन नंबर होते हैं: मेजर.माइनर.पच। सबसे कम संख्या - पैच स्तर बग फिक्स के लिए केवल जिम्मेदार है। जब एपीआई परिवर्तन पिछड़े संगत होते हैं तो औसत परिवर्तन होता है। और पुरानी संख्या बदल जाती है जब परिवर्तन होता है जो पिछड़े संगतता को बर्बाद कर देता है। सूचना, संख्या नहीं, बल्कि एक संख्या है, इसलिए संस्करण संख्या आसानी से इस तरह हो सकती है: 1.13.2।
सिमेंटिक संस्करण उपयोगी है क्योंकि निर्भरता में आप मणि के सटीक संस्करण को निर्दिष्ट नहीं कर सकते हैं, लेकिन पैच स्तर या लघु संस्करण के लिए सटीक संस्करण। इस तरह से आपको अवसर मिलता है, बिना अपने पैकेज के साथ कुछ किए बिना, फिक्सेस जो कि निर्भरता पैकेज में बग को ठीक करता है। लेकिन साथ ही, आपके पास निर्भरता के संस्करणों को बहुत अधिक बदलने से रोकने का अवसर होता है ताकि अगले अपडेट के साथ आपके पैकेज के साथ एपीआई परिवर्तन असंगत न हो।

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

निष्पादन योग्य फ़ाइल में क्या होना चाहिए?
सबसे पहले, हालांकि यह एक रूबी स्क्रिप्ट है, आपको .rb एक्सटेंशन को निर्दिष्ट करने के लिए इसे बताने की आवश्यकता नहीं है। न तो यूनिक्स पर, न ही विंडोज पर। यह केवल उपयोगकर्ता को भ्रमित करेगा, और एक सफल स्क्रिप्ट को चलाने के लिए, यह पूरी तरह से वैकल्पिक है।
दूसरी बात, पहली पंक्ति को यह कहना चाहिए: #!/usr/bin/env ruby
कृपया ध्यान दें कि इस रेखा का मार्ग नहीं है /usr/bin/ruby । envइसका उपयोग करने से आपको माणिक का पता लगाने की अनुमति मिलती है, भले ही यह एक अलग फ़ोल्डर में स्थित हो, जो कि आरवीएम स्थापित होने पर बस आवश्यक है।
तीसरा, सभी स्क्रिप्ट तर्क को एक अलग फ़ाइल में डालना बेहतर है, उदाहरण के लिए, lib / my_exec.rb, और इसे आवश्यक का उपयोग करके निष्पादन योग्य फ़ाइल से प्राप्त करें। रत्न बनाने के बारे में इस लेख में इसके बारे में और पढ़ें, जिसका मैंने ऊपर उल्लेख किया है। परिणामस्वरूप, निष्पादन योग्य फ़ाइल इस तरह दिखाई देती है:

 #!/usr/bin/env ruby require 'rubygems' #    ruby 1.9   require 'your-gem' require 'your-gem/my_exec' 

यदि आप अपने रत्न पैकेज को इकट्ठा नहीं करने का निर्णय लेते हैं तो आपको किन परेशानियों का इंतजार है? खैर, निर्भरता नियंत्रण के लिए स्पष्ट सतही सिरदर्द के अलावा, आपको एक और अप्रिय आश्चर्य मिलेगा। कल्पना कीजिए कि आपने एक स्क्रिप्ट लिखी है और कमांड लाइन पर लिख रहे हैं my_app value1 value2। आप किस तर्क की उम्मीद करते हैं? शायद ['value1', 'value2']। आपके पास वास्तव में क्या है? यूनिक्स पर, सब कुछ वैसा ही होगा जैसा आप उम्मीद करते हैं। और जब आप विंडोज पर स्क्रिप्ट चलाते हैं, तो आपके पास एक खाली तर्क सूची होती है, क्योंकि my_appयह विंडोज में एक प्रोग्राम के रूप में नहीं माना जाता है जो तर्कों को प्राप्त कर सकता है (इसके बजाय, रूबी। exe प्रोग्राम आमतौर पर तर्क प्राप्त करता है)। स्क्रिप्ट के लिए तर्कों को पारित करने के लिए, स्क्रिप्ट को चलाने के लिए आवश्यक है, शुरुआत में शब्द रूबी। यानीकार्यक्रम का प्रत्येक लॉन्च इस तरह दिखाई देगा: ruby my_app value1 value2और यदि आप माणिक शब्द को भूल जाते हैं, तो आपके पास यह समझने का मौका नहीं है कि कुछ भी क्यों काम नहीं करता है।

याद रखें, मैंने उल्लेख किया है कि माणिक एक बैट रैपर बनाता है? यह आवश्यक है क्योंकि बैट फाइल कमांड लाइन के तर्कों को समझती है और स्क्रिप्ट को ठीक से कॉल करके उन्हें स्क्रिप्ट में पास कर सकती है। इस प्रकार माणिक इस समस्या का हल करता है। लेकिन मरहम में एक मक्खी होती है: कॉल का ऐसा झरना आवेदन की शुरुआत को धीमा कर देता है। कभी-कभी हैलो वर्ल्ड पांच सेकंड के लिए शुरू होता है। एप्लिकेशन लॉन्च होने के बाद, सब कुछ सामान्य गति से काम करता है, लेकिन एप्लिकेशन लॉन्च करने की प्रक्रिया अप्रिय रूप से लंबी है (जहां तक ​​मैं समझता हूं, विंडोज प्रक्रियाएं आमतौर पर यूनिक्स प्रक्रियाओं की तुलना में अधिक भारी हैं)। जब आप दौड़ते हैं तो यह कष्टप्रद हो सकता है, उदाहरण के लिए, प्रत्येक कोड परिवर्तन के बाद rspec। या हर पांच मिनट में, git response के लिए पांच सेकंड का समय व्यतीत करें (जो इस समस्या से ग्रस्त है, हालाँकि यह माणिक में नहीं लिखा गया है)। लेकिन यह कीमत हैजो आपको विंडोज के साथ कार्यक्रमों की संगतता के लिए भुगतान करना होगा, दूसरे तरीके से - कुछ भी नहीं।

इनायत करता है

यह सब बहुत सरल है।
आपकी स्क्रिप्ट क्रैश हो गई। Stderr में एक त्रुटि संदेश प्रदर्शित करें, संभव समाधान सुझाएं (उदाहरण के लिए, मुझे बताएं कि कौन सा तर्क गायब है या कौन से विकल्प संघर्ष)। यदि आवश्यक हो, तो उपयोग का वर्णन करने वाली एक हेल्प लाइन प्रदर्शित करें। और निश्चित रूप से कार्यक्रम को किसी भी कार्य को करने की कोशिश नहीं करनी चाहिए अगर उन्हें निष्पादित करने के लिए पर्याप्त तर्क नहीं हैं।
क्या आपकी स्क्रिप्ट फ़ाइलों के लिए कुछ लिखती है या शायद यह फ़ाइलों को मिटा देती है? यदि हां, तो सुनिश्चित करें कि यह मौजूदा फ़ाइलों को अधिलेखित नहीं करता है। यदि फ़ाइल मौजूद है, तो स्क्रिप्ट को यह कहना चाहिए और फ़ाइल संशोधन की पुष्टि के लिए पूछना चाहिए, या कुंजी का उपयोग करने की पेशकश करनी चाहिए --force। खैर, प्रोग्राम को एक संदेश प्रदर्शित करने दें कि वह किस फ़ाइल को अधिलेखित या हटा दिया गया है।
क्या उपयोगकर्ता ने अजीब विकल्प निर्दिष्ट किए? उससे पुष्टि करने के लिए कहें कि उसका वास्तव में क्या मतलब है। एक कमांड की कल्पना करें। rm -rf * .logयह यादृच्छिक स्थान आपको बहुत खर्च करेगा, इसलिए उपयोगकर्ता से फिर से पूछें कि क्या आपको संदेह है कि कार्यक्रम अनावश्यक रूप से विनाशकारी व्यवहार कर सकता है।

नई सुविधाओं और बग को आसानी से ठीक करता है

पूरी तरह से वर्णन करने के लिए कोड समर्थन बहुत व्यापक है। संक्षेप में, एप्लिकेशन को मॉड्यूलर बनाएं, इसे अलग-अलग फ़ाइलों में तोड़ दें। यदि आवश्यक हो तो इसे कई अलग-अलग रत्नों में तोड़ दें। बग को ठीक करने और नए लोगों को रोकने के लिए, आपको परीक्षण लिखने की आवश्यकता है। और यहां समस्याएं हो सकती हैं ...
तथ्य यह है कि परीक्षण में आमतौर पर परीक्षणों का अलगाव शामिल होता है, और जब फाइल सिस्टम (जो अक्सर उपयोगिताओं का उद्देश्य होता है) के साथ काम करना आसान होता है। आपको फ़ाइलों को बनाने, हटाने और अधिलेखित करने की आवश्यकता हो सकती है, साथ ही प्रत्येक परीक्षण के बाद फ़ाइल सिस्टम की स्थिति को पुनर्स्थापित करना होगा। यह सब बेहद अप्रिय और समय लेने वाला काम हो सकता है (एचडीडी के साथ काम करना कोई त्वरित बात नहीं है)। समस्या के कम से कम दो समाधान हैं।
पहला उपाय है अरुबा रत्नसीएलआई के परीक्षण के लिए विशिष्ट ककड़ी स्क्रिप्ट प्रदान करना। सामग्री के साथ फाइल भरने के लिए दृश्य, सफाई के लिए, फ़ाइल के अस्तित्व की जांच के लिए, साथ ही कुछ तर्कों के साथ एक एप्लिकेशन लॉन्च करने के लिए स्क्रिप्ट, रिटर्न कोड की जांच, इनपुट / आउटपुट स्ट्रीम की सामग्री आदि।
दूसरा समाधान (जो मुझे व्यक्तिगत रूप से बहुत पसंद है) नकली रत्न के साथ-साथ सामान्य टेस्टयूनिट या आरएसईपीई परीक्षण है । यह मणि उन कक्षाओं को प्रतिस्थापित करता है जो फ़ाइल सिस्टम के साथ काम करते हैं और रैम में एक वर्चुअल फ़ाइल सिस्टम बनाते हैं - अपनी स्वयं की फ़ोल्डर संरचना के साथ, अपनी खुद की फाइलों को उस सामग्री के साथ जो आप वहां रखना चाहते हैं। आपको कोई भी नकली, पूरी कक्षा बनाने की आवश्यकता नहीं है File,Dir(और इसमें शामिल लोग) थोड़ी देर के लिए एक बड़े नकली में बदल जाते हैं, इसलिए व्यवहार का परीक्षण करने के लिए प्रोग्राम कोड को बिल्कुल भी बदलने की आवश्यकता नहीं है। काम के बाद फाइल सिस्टम में कोई निशान नहीं हैं। ब्यूटी!हम नकली फ़ाइल सिस्टम मोड को चालू करते हैं, डाउनलोड करते हैं (हमारे डाउनलोड करने के लिए Kernel.system, अर्थात्, डाउनलोड का उपयोग करके एप्लिकेशन शुरू नहीं करते हैं ) लिब / my_exec फ़ाइल से स्क्रिप्ट और परिणामों की जांच करें।

यह देखने के लिए कि प्रोग्राम को स्क्रीन पर प्रदर्शित करने के लिए, अरूबा का उपयोग किए बिना कैसे? ऐसा करने के लिए, क्लास ऑब्जेक्ट्स के साथ स्टडआउट और स्टेडर धाराओं को बदलें StringIO। फिर कार्यक्रम चलने के बाद, इन "धाराओं" की सामग्री की जांच करना संभव होगा। आप तैयार किए गए समाधान का उपयोग कर सकते हैं: out, err = MiniTest::Assertions.capture_io{ ... }मानक परीक्षण पुस्तकालय से, या आप स्ट्रीम की सामग्री को इंटरसेप्ट करने के लिए खुद को कोड लिखने की कोशिश कर सकते हैं, यह बिल्कुल भी जटिल नहीं है।
महत्वपूर्ण सूचना! रूबी में, इनपुट / आउटपुट स्ट्रीम के लिए दो चर हैं: स्थिर STDOUTऔर वैश्विक चर$stdout। जब आप स्ट्रींगियो के साथ थ्रेड्स को प्रतिस्थापित करेंगे, तो एक वैश्विक चर का उपयोग करें, स्थिर को बदलने की कोशिश न करें। यह डरावना नहीं है कि आप एक चेतावनी देखेंगे, लेकिन यह अपेक्षित प्रभाव नहीं देगा। संभवतः, प्रकार के आदेश putsडिफ़ॉल्ट रूप से एक वैश्विक चर से बंधे हैं, और एक निरंतर केवल इसे संदर्भित करता है।
बेशक, यह टिप्पणी एक धारा ( STDOUT.puts 'smth') को स्पष्ट रूप से निर्दिष्ट करने के मामलों पर लागू नहीं होती है , और यह, वैसे, एक बहाना है जो निरंतर का उपयोग नहीं करता है STDOUT, STDINऔर STDERR।

एक और बात है। हम चाहते हैं कि परीक्षण कोड यथासंभव वास्तविकता के करीब हो। स्क्रिप्ट इन चर को एक सरणी के रूप में प्राप्त करती हैARGV। और हम एक स्ट्रिंग के रूप में आवेदन के लिए तर्क पारित करते हैं, न कि एक सरणी, सही? हम इस सवाल का सामना कर रहे हैं: तर्कों की एक स्ट्रिंग से एक सरणी कैसे प्राप्त करें। ऊपर उल्लिखित शेल्वर्स लाइब्रेरी के बारे में सोचें और विधि का उपयोग करके तत्वों में स्ट्रिंग को तोड़ दें String#shellsplit।
अब जब हम आदेश पंक्ति तर्क की एक सरणी है, हम, उदाहरण के लिए, की सामग्री को बदल सकते हैं ARGVइस सरणी: ARGV.replace(new_array)।
लेकिन विधि में पारित सरणी को बदलने के लिए बेहतर होगाOptionParser#parse! ।इसके बजाय, ARGVयह हमारे नए सरणी को पारित करने के लिए पर्याप्त है OptionParser#parse!(new_array), और यह इससे विकल्पों को अलग करेगा, और इससे नहीं ARGV। यह मत भूलो कि विकल्पों को अलग करने के बाद स्थिति संबंधी तर्कों को नए सरणी से भी चुना जाना चाहिए।

एक अलग सवाल यह है कि कॉन्फ़िगरेशन फ़ाइलों के साथ सही संचालन का परीक्षण कैसे करें। लेखक पर्यावरण चर के माध्यम से इन फ़ाइलों की सेटिंग को ओवरराइड करना संभव बनाता है। मैं व्यक्तिगत रूप से इस अपात्र पर विचार करता हूं और जिज्ञासु पाठक को पुस्तक में शामिल होने और स्वतंत्र रूप से इससे जुड़ी सिफारिशों को देखने का अवसर छोड़ता हूं।

उपयोगकर्ताओं को प्रसन्न करता है

आउटपुट स्वरूप में पूर्वता के बारे में कुछ टिप्पणियां।

टेबल

मान लीजिए कि आपकी उपयोगिता सबसे लोकप्रिय ब्लॉगर्स को सूचीबद्ध करती है: नाम, पदों की संख्या, टिप्पणियां, मित्र। स्पष्ट आउटपुट स्वरूप भीख माँगता है: एक प्लेट खींचें। समाधान बस उतना ही सीधा है - टर्मिनल-टेबल रत्न का उपयोग करें ।

रंग

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

डेविड कोपलैंड याद करते हैं कि लगभग 10% लोग कलर ब्लाइंड हैं। यह इस प्रकार है कि रंग केवल कार्यक्रम के आउटपुट को नेविगेट करने में मदद करना चाहिए, और एकल डेटा चैनल के कार्य पर नहीं लेना चाहिए। यदि आप अलग-अलग उपयोगिता में प्लसस और मिनस को निकालते हैं, तो लोगों का एक महत्वपूर्ण हिस्सा काम के परिणामों का लाभ उठाने का अवसर खो देगा। इसलिए, रंगीन आउटपुट में रंग और अन्य डेटा दोनों होने चाहिए, जिसके होने पर रंग आवश्यक हो जाते हैं।
महत्वपूर्ण सूचना! जब आपकी उपयोगिता मशीन-पठनीय प्रारूप में पाठ प्रदर्शित करती है, तो यह सलाह दी जाती है कि स्वरूपण रंगों को बंद कर दिया जाए। अन्यथा, इनपुट स्वीकार करने वाली पार्टी के पास लाइन में विशेष पात्रों से "अपच" अर्जित करने का मौका है।

इंटरैक्टिव उपयोगकर्ता संचार

एक अन्य पुस्तकालय को अन्तरक्रियाशीलता प्रदान करने के लिए डिज़ाइन किया गया है। रीडलाइन, जिसके बारे में मैंने पहले ही बोल दिया था। इसलिए, आपकी सेवा में: उपयोगकर्ता की प्रतिक्रियाओं और ऑटो-पूरा करने के इतिहास को याद रखना। रूबीगैम और थोर में भी उपयोगकर्ता बातचीत और कहने और पूछने के लिए तरीके प्रदान करने के लिए जिम्मेदार विशेष मॉड्यूल हैं।
किस प्रकार के इंटरैक्टिव अनुप्रयोग हैं? आईआरबी और रेल कंसोल के बारे में सोचो। पुस्तक के लेखक ने एक और उदाहरण दिया: मान लीजिए कि आपको एक बड़ी JSON वस्तु मिलती है और यह पता लगाना चाहते हैं कि इसमें क्या है। ऐसा करने के लिए, आप एक इंटरैक्टिव JSON दर्शक लिख सकते हैं जो आपको सीडी, ls कमांड के साथ पदानुक्रम को घूमने और rm और mknode कमांड के साथ इसे बदलने की अनुमति देता है। एक उदाहरण पूरी तरह से आपकी कल्पना को जगाने के लिए प्रदान किया जाता है। आप इंटरैक्टिव अनुप्रयोगों के लिए सौ से अधिक अनुप्रयोगों के साथ आ सकते हैं।

उपयोगकर्ता की नसों को सुरक्षित रखें

एक मोबाइल कनेक्शन के माध्यम से एक बड़ी फ़ाइल डाउनलोड करने वाले उपयोगकर्ता के स्थान पर स्वयं की कल्पना करें और यह नहीं जानता कि कितने पहले ही डाउनलोड किए जा चुके हैं। पहले दस मिनट, उपयोगकर्ता इंतजार करता है, यह जानकर कि फ़ाइल बड़ी है। और फिर उसकी कोहनी को काटना शुरू कर देता है: क्या होगा अगर कोई संबंध नहीं है? या शायद कार्यक्रम जमा देता है? या शायद फ़ाइल इतनी बड़ी है कि उपयोगकर्ता महीने के अंत में एक बार और सभी के लिए डिस्कनेक्ट हो जाएगा? यदि प्रोग्राम लंबे समय तक चल सकता है, तो यह स्टेट बार को स्टोडर या लॉग फ़ाइल में आउटपुट करने के लिए चोट नहीं पहुंचाएगा (और यह मत भूलो कि फ़ाइल ऑपरेशन बफ़र किए गए हैं, इसलिए इसे समय-समय पर करें flush, अन्यथा आपके पास लॉग फ़ाइल में परिणाम देखने का मौका है कार्यक्रम पूरा होने के बाद ही)।
नई लाइन पर लोड के हर प्रतिशत को गिनना हास्यास्पद होगा! इसके बजाय, आइए प्रत्येक बार संख्याओं को बदलते हुए, एक पंक्ति को फिर से लिखें। यह हमें एक विशेष प्रतीक \r- गाड़ी वापसी के साथ मदद करेगा । जब यह एक पंक्ति में दिखाई देता है \r, तो टर्मिनल कर्सर लाइन की शुरुआत में चला जाता है और पुराने लोगों पर वर्णों को प्रिंट करना शुरू कर देता है (ध्यान से, पुरानी लाइन की "पूंछ" स्वचालित रूप से अधिलेखित नहीं होती है)। हालांकि, सावधान रहें, विधि putsहमारे लिए काम नहीं करेगी, क्योंकि यह स्वचालित रूप से कर्सर को एक नई रेखा पर ले जाता है। हमें एक विधि की आवश्यकता है print, और यहाँ इसके उपयोग का एक उदाहरण है:

 (0..100).each do |i| $stderr.print("\r#{i}% done") sleep(0.1) end 

सच है, यह आपको थोड़ा सावधान करने के लायक है: टर्मिनल विंडो में, stderr और stdout स्ट्रीम मिश्रित होती हैं, इसलिए आप गलत डेटा को अधिलेखित करना शुरू कर सकते हैं।

अंत में, मैं मदद नहीं कर सकता लेकिन कई लोकप्रिय पुस्तकालयों के बारे में बात कर रहा हूं।

यदि आपने कम से कम कुछ समय के लिए रूबी परियोजनाओं के साथ काम किया है, तो आप शायद पहले से ही रेक टीम से मिले , और शायद थोर कमांड । ये विशेष पुस्तकालय हैं जो स्वचालन कार्यों के एक सेट के रूप में उपयोगिताओं के एक सेट का वर्णन करने के लिए एक विशेष डीएसएल का उपयोग करने की अनुमति देते हैं।

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

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

ज्यादातर कहानी मैं रूबी मानक पुस्तकालय से OptionParser विकल्प पार्स करने के लिए इस्तेमाल किया। यह एक बहुत ही सुविधाजनक पुस्तकालय है, हालांकि, कुछ इसे भारी मानते हैं और आवरण लिखते हैं। कुछ रैपर विकल्पों को सरल बनाने पर ध्यान केंद्रित करते हैं, कुछ विकल्प वैश्विक स्तर पर उपलब्ध हैश आदि बनाने पर। यदि यह आपको लगता है कि OptionParser आपको धीमा कर रहा है, तो आप तैयार किए गए रैपर में से एक चुन सकते हैं (सूची पुस्तक की वेबसाइट पर पाई जा सकती है - लेख की शुरुआत देखें) या अपना खुद का बना लें।
OptionParser में अन्य कमियां भी हैं: यह सॉफ्टवेयर पैकेज में वैश्विक और स्थानीय विकल्पों के बीच अंतर करने में सक्षम नहीं है (हमने इस अलगाव को खुद किया था; आम तौर पर बोलना, यह कहीं से भी पालन नहीं करता है, कुछ बड़ी परियोजनाओं में अवधारणा के सफल अनुप्रयोग को छोड़कर)। OptionParser की एक और विशेषता (यह विनिर्देश में निर्दिष्ट नहीं है और मेरा मानना ​​है कि यह एक बग है) यह है कि यह विकल्पों के रूप में तर्कों में नकारात्मक संख्याओं को समझता है। मेरा मानना ​​है कि जितनी जल्दी या बाद में यह बग ठीक हो जाएगा, लेकिन अगर आपका कार्यक्रम संख्यात्मक तर्क स्वीकार करता है, तो सावधान रहें और कार्यक्रम का पूरी तरह से परीक्षण करें।

सॉफ्टवेयर पैकेज बनाने के लिए, पुस्तक के लेखक, डेविड कोपलैंड ने बहुत अच्छा जीएलआई रत्न बनाया । यह वैश्विक विकल्पों, कमांड विकल्पों के बीच अंतर करता है और कमांड को ही पहचानता है। परियोजना जीवंत है और समय-समय पर अद्यतन प्राप्त करती है।

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

PS इसके अलावा जो मैंने लेख में वर्णित किया था, कमांड लाइन अनुप्रयोगों के साथ काम करने वाला हैक, यह एक विशेष चर के बारे में पढ़ने के लिए समझ में आता है ARGF। यदि आपकी स्क्रिप्ट के सभी तर्क फ़ाइल नाम हैं, तो यह ARGFसभी फ़ाइलों की सामग्री का एक संयोजन है।