बैश स्क्रिप्ट टेम्पलेट बनाना

इस श्रृंखला के पहले लेख में, आपने एक बहुत छोटी, एक-पंक्ति वाली बैश स्क्रिप्ट बनाई और शेल स्क्रिप्ट बनाने के कारणों का पता लगाया और यह भी पता लगाया कि वे संकलित प्रोग्राम के बजाय सिस्टम व्यवस्थापक के लिए सबसे कुशल विकल्प क्यों हैं।

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

टेम्पलेट क्यों बनाएं?

सामान्य रूप से स्वचालन की तरह, टेम्पलेट बनाने के पीछे का विचार "आलसी sysadmin" होना है। टेम्प्लेट में वे मूल घटक होते हैं जो आप अपनी सभी स्क्रिप्ट में चाहते हैं। यह हर नई स्क्रिप्ट में उन घटकों को जोड़ने की तुलना में समय बचाता है और नई स्क्रिप्ट शुरू करना आसान बनाता है।

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

आवश्यकताएं

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

इस बैश टेम्पलेट के लिए आवश्यकताएं बहुत सरल हैं:

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

मूल संरचना

एक बेसिक बैश स्क्रिप्ट में तीन सेक्शन होते हैं। बैश के पास वर्गों को चित्रित करने का कोई तरीका नहीं है, लेकिन वर्गों के बीच की सीमाएँ निहित हैं।

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

बस इतना ही है—किसी भी बैश कार्यक्रम की संरचना में केवल तीन खंड हैं।

अग्रणी टिप्पणियां

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

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

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

तो अब स्क्रिप्ट इस तरह दिखती है:

#!/bin/bash

################################################################################

#                              scriptTemplate                                  #

#                                                                              #

# Use this template as the beginning of a new program. Place a short           #

# description of the script here.                                              #

#                                                                              #

# Change History                                                               #

# 11/11/2019  David Both    Original code. This is a template for creating     #

#                           new Bash shell scripts.                            #

#                           Add new history entries as needed.                 #

#                                                                              #

#                                                                              #

################################################################################

################################################################################

################################################################################

#                                                                              #

#  Copyright (C) 2007, 2019 David Both                                         #

#  LinuxGeek46@both.org                                                        #

#                                                                              #

#  This program is free software; you can redistribute it and/or modify        #

#  it under the terms of the GNU General Public License as published by        #

#  the Free Software Foundation; either version 2 of the License, or           #

#  (at your option) any later version.                                         #

#                                                                              #

#  This program is distributed in the hope that it will be useful,             #

#  but WITHOUT ANY WARRANTY; without even the implied warranty of              #

#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the               #

#  GNU General Public License for more details.                                #

#                                                                              #

#  You should have received a copy of the GNU General Public License           #

#  along with this program; if not, write to the Free Software                 #

#  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA   #

#                                                                              #

################################################################################

################################################################################

################################################################################



echo "hello world!"

यह सत्यापित करने के लिए संशोधित कार्यक्रम चलाएँ कि यह अभी भी अपेक्षा के अनुरूप काम कर रहा है।

परीक्षण के बारे में

अब परीक्षण के बारे में बात करने का अच्छा समय है।

<ब्लॉककोट>

"हमेशा एक और बग होता है।"

— लुबार्स्की का साइबरनेटिक कीटविज्ञान का नियम

लुबार्स्की - जो भी हो - सही है। आप अपने कोड में सभी बग कभी नहीं ढूंढ सकते हैं। मेरे द्वारा खोजे गए प्रत्येक बग के लिए, हमेशा ऐसा लगता है कि एक और बग सामने आता है, आमतौर पर बहुत ही अनुपयुक्त समय पर।

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

शेल स्क्रिप्ट लिखते और परीक्षण करते समय एक अच्छी तरह से परिभाषित प्रक्रिया का पालन करना सुसंगत और उच्च-गुणवत्ता वाले परिणामों में योगदान कर सकता है। मेरी प्रक्रिया सरल है:

एक साधारण परीक्षण योजना बनाएं।
विकास की शुरुआत में ही परीक्षण शुरू करें।
कोड पूरा होने पर अंतिम परीक्षण करें।
उत्पादन पर जाएं और अधिक परीक्षण करें।

परीक्षा योजना

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

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

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

परीक्षण किए जा रहे सॉफ़्टवेयर का नाम और संक्षिप्त विवरण
परीक्षण की जाने वाली सॉफ़्टवेयर सुविधाओं का विवरण
प्रत्येक परीक्षण के लिए प्रारंभिक शर्तें
प्रत्येक परीक्षण के लिए अनुसरण किए जाने वाले कार्य
प्रत्येक परीक्षण के लिए वांछित परिणाम का विवरण
नकारात्मक परिणामों के परीक्षण के लिए डिज़ाइन किए गए विशिष्ट परीक्षण
जांचें कि प्रोग्राम अनपेक्षित इनपुट को कैसे संभालता है
प्रत्येक परीक्षा में उत्तीर्ण या अनुत्तीर्ण होने का स्पष्ट विवरण
अस्पष्ट परीक्षण, जिसका वर्णन नीचे किया गया है

यह सूची आपको अपनी परीक्षण योजनाएँ बनाने के लिए कुछ विचार प्रदान करेगी। अधिकांश sysadmins को इसे सरल और काफी अनौपचारिक रखना चाहिए।

जल्दी परीक्षण करें—अक्सर परीक्षण करें

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

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

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

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

अंतिम परीक्षण

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

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

यदि आप स्क्रिप्ट का परीक्षण कर रहे हैं क्योंकि आप इसमें नया कोड जोड़ते हैं, तो आप सोच सकते हैं कि अंतिम परीक्षण के दौरान कोई आश्चर्य नहीं होना चाहिए। गलत! अंतिम परीक्षण के दौरान हमेशा आश्चर्य होता है। हमेशा। उन आश्चर्यों की अपेक्षा करें, और उन्हें ठीक करने में समय बिताने के लिए तैयार रहें। अगर अंतिम परीक्षण के दौरान कभी कोई बग नहीं खोजा गया, तो अंतिम परीक्षण करने का कोई मतलब नहीं होगा, है ना?

उत्पादन में परीक्षण

हुह—क्या?

<ब्लॉककोट>

"जब तक कोई प्रोग्राम कम से कम छह महीने तक उत्पादन में रहा है, तब तक सबसे हानिकारक त्रुटि का पता नहीं चलेगा।"

— ट्राउटमैन की प्रोग्रामिंग पोस्टुलेट्स

हां, उत्पादन में परीक्षण अब सामान्य और वांछनीय माना जाता है। खुद एक परीक्षक होने के नाते, यह उचित लगता है। "लेकिन रुको! यह खतरनाक है," आप कहते हैं। मेरा अनुभव यह है कि यह एक समर्पित परीक्षण वातावरण में व्यापक और कठोर परीक्षण से अधिक खतरनाक नहीं है। कुछ मामलों में, कोई विकल्प नहीं है क्योंकि कोई परीक्षण वातावरण नहीं है - केवल उत्पादन।

Sysadmins उत्पादन में नई या संशोधित स्क्रिप्ट का परीक्षण करने की आवश्यकता के लिए अजनबी नहीं हैं। जब भी किसी स्क्रिप्ट को प्रोडक्शन में ले जाया जाता है, तो वह अंतिम परीक्षा बन जाती है। उत्पादन वातावरण उस परीक्षण का सबसे महत्वपूर्ण हिस्सा है। परीक्षण वातावरण में परीक्षक जो कुछ भी सपना नहीं देख सकते हैं, वह वास्तविक उत्पादन वातावरण को पूरी तरह से दोहरा सकता है।

उत्पादन में परीक्षण का कथित रूप से नया अभ्यास सिर्फ इस बात की मान्यता है कि sysadmins सभी के साथ क्या जानते हैं। सबसे अच्छा परीक्षण उत्पादन है—जब तक कि यह एकमात्र परीक्षण न हो।

फजी टेस्टिंग

यह उन buzzwords में से एक और है जिसने शुरू में मुझे अपनी आँखें घुमाने के लिए प्रेरित किया। इसका आवश्यक अर्थ सरल है:किसी को कुछ होने तक चाबियों पर धमाका करना है, और देखें कि प्रोग्राम इसे कितनी अच्छी तरह से संभालता है। लेकिन वास्तव में इसके अलावा और भी बहुत कुछ है।

फ़ज़ी टेस्टिंग उस समय की तरह है जब मेरे बेटे ने यादृच्छिक इनपुट के साथ एक मिनट से भी कम समय में गेम के लिए कोड तोड़ दिया। इसने उसके लिए खेल लिखने के मेरे प्रयासों को काफी हद तक समाप्त कर दिया।

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

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

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

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

आने वाले आकर्षणों के पूर्वावलोकन

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

संसाधन

बैश के साथ प्रोग्राम कैसे करें:सिंटेक्स और टूल्स
बैश के साथ प्रोग्राम कैसे करें:लॉजिकल ऑपरेटर्स और शेल एक्सपेंशन
बैश के साथ प्रोग्राम कैसे करें:लूप्स

लेखों की यह श्रृंखला आंशिक रूप से डेविड दोनों के तीन-भाग वाले लिनक्स स्व-अध्ययन पाठ्यक्रम के खंड 2, अध्याय 10 पर आधारित है, लिनक्स का उपयोग और व्यवस्थापन—जीरो टू SysAdmin।