सिस्टम एडमिनिस्ट्रेटर्स के लिए एक मजबूत बैश स्क्रिप्ट टेम्पलेट बनाना

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

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

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

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

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

आवश्यकताएं

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

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

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

बुनियादी संरचना

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

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

बस इतना ही है—किसी भी बैश प्रोग्राम की संरचना में केवल तीन सेक्शन होते हैं।

लीडिंग कमेंट्स

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

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

दूसरा कमेंट सेक्शन एक कॉपीराइट और लाइसेंस स्टेटमेंट है। मैं 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 का उपयोग करके मुझे मिले नमूना टेस्ट प्लान डॉक्यूमेंट्स जटिल थे और बहुत औपचारिक विकास और टेस्ट प्रक्रियाओं वाले बड़े संगठनों के लिए अभिप्रेत थे। हालांकि वे टेस्ट प्लान "टेस्ट" को अपने जॉब टाइटल में रखने वाले लोगों के लिए अच्छे होंगे, वे सिसएडमिन्स की अधिक अराजक और समय-निर्भर कार्य स्थितियों पर अच्छी तरह से लागू नहीं होते। अधिकांश अन्य नौकरी पहलुओं की तरह, सिसएडमिन्स को रचनात्मक होने की आवश्यकता है। तो यहां आपके टेस्ट प्लान में शामिल करने पर विचार करने के लिए चीजों की एक छोटी सूची है। इसे अपनी आवश्यकताओं के अनुरूप संशोधित करें:

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

यह सूची आपको अपने टेस्ट प्लान बनाने के लिए कुछ विचार देनी चाहिए। अधिकांश सिसएडमिन्स को इसे सरल और काफी अनौपचारिक रखना चाहिए।

जल्दी टेस्ट करें—अक्सर टेस्ट करें

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

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

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

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

अंतिम टेस्टिंग

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

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

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

प्रोडक्शन में टेस्टिंग

हुह—क्या?

"कम से कम छह महीने तक प्रोग्राम प्रोडक्शन में रहने तक सबसे हानिकारक त्रुटि खोजी नहीं जाएगी।"

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

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

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

कथित रूप से प्रोडक्शन में टेस्टिंग की नई प्रथा केवल उसी की मान्यता है जो सिसएडमिन्स हमेशा से जानते हैं। सबसे अच्छा टेस्ट प्रोडक्शन है—जब तक यह एकमात्र टेस्ट नहीं है।

फज़ी टेस्टिंग

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

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

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

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

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

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

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

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

संसाधन

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

यह लेख श्रृंखला डेविड बोथ के तीन-भाग वाले लिनक्स सेल्फ-स्टडी कोर्स, Using and Administering Linux—Zero to SysAdmin के वॉल्यूम 2, अध्याय 10 पर आंशिक रूप से आधारित है।