🥇बॅश स्क्रिप्ट सर्वोत्तम पद्धती: विश्वासार्ह, परफॉर्मन्स बॅश स्क्रिप्ट्ससाठी एक द्रुत मार्गदर्शक

मनापी द्वारे शेल वॉलपेपर

बॅश स्क्रिप्ट्स डीबग करणे हे गवताच्या गंजीमध्ये सुई शोधण्यासारखे आहे, विशेषत: जेव्हा संरचना, लॉगिंग आणि विश्वासार्हतेच्या मुद्द्यांचा वेळेवर विचार न करता विद्यमान कोडबेसमध्ये नवीन जोडणी दिसून येतात. तुमच्या स्वतःच्या चुकांमुळे किंवा स्क्रिप्टचे जटिल ढिगारे व्यवस्थापित करताना तुम्ही अशा परिस्थितीत स्वतःला शोधू शकता.

संघ Mail.ru क्लाउड सोल्यूशन्स शिफारशींसह एक लेख अनुवादित केला आहे जो तुम्हाला तुमच्या स्क्रिप्ट अधिक चांगल्या प्रकारे लिहिण्यास, डीबग करण्यास आणि राखण्यात मदत करेल. यावर विश्वास ठेवा किंवा नाही, प्रत्येक वेळी कार्य करणारा स्वच्छ, वापरण्यास-तयार बॅश कोड लिहिल्याबद्दल समाधान काहीही नाही.

लेखात, लेखकाने गेल्या काही वर्षांत जे शिकले आहे ते शेअर केले आहे, तसेच काही सामान्य चुका ज्यांनी त्याला सावध केले आहे. हे महत्त्वाचे आहे कारण प्रत्येक सॉफ्टवेअर डेव्हलपर, त्यांच्या कारकिर्दीत कधीतरी, नियमित कामाची कामे स्वयंचलित करण्यासाठी स्क्रिप्टसह कार्य करतो.

ट्रॅप हाताळणारे

स्क्रिप्टच्या अंमलबजावणीदरम्यान काही अनपेक्षित घडते तेव्हा मला आढळलेल्या बहुतेक बॅश स्क्रिप्ट्स कधीही प्रभावी क्लीनअप यंत्रणा वापरत नाहीत.

बाहेरून आश्चर्यचकित होऊ शकतात, जसे की कोरमधून सिग्नल प्राप्त करणे. स्क्रिप्ट्स उत्पादन प्रणालीवर चालण्यासाठी पुरेशा विश्वासार्ह आहेत याची खात्री करण्यासाठी अशी प्रकरणे हाताळणे अत्यंत महत्वाचे आहे. यासारख्या परिस्थितींना प्रतिसाद देण्यासाठी मी बर्‍याचदा एक्झिट हँडलर वापरतो:

function handle_exit() {
  // Add cleanup code here
  // for eg. rm -f "/tmp/${lock_file}.lock"
  // exit with an appropriate status code
}
  
// trap <HANDLER_FXN> <LIST OF SIGNALS TO TRAP>
trap handle_exit 0 SIGHUP SIGINT SIGQUIT SIGABRT SIGTERM

trap एक शेल बिल्ट-इन कमांड आहे जी तुम्हाला क्लीनअप फंक्शनची नोंदणी करण्यास मदत करते जी कोणत्याही सिग्नलच्या बाबतीत कॉल केली जाते. तथापि, हँडलर्ससह विशेष काळजी घेतली पाहिजे जसे की SIGINT, ज्यामुळे स्क्रिप्ट रद्द होते.

याव्यतिरिक्त, बर्याच बाबतीत आपण फक्त पकडले पाहिजे EXIT, परंतु कल्पना अशी आहे की आपण प्रत्येक वैयक्तिक सिग्नलसाठी स्क्रिप्टचे वर्तन प्रत्यक्षात सानुकूलित करू शकता.

बिल्ट-इन सेट फंक्शन्स - त्रुटीवर जलद समाप्ती

त्रुटी आढळल्याबरोबर त्यांना प्रतिसाद देणे आणि त्वरीत अंमलबजावणी थांबवणे खूप महत्वाचे आहे. यासारखी कमांड चालवणे सुरू ठेवण्यापेक्षा वाईट काहीही असू शकत नाही:

rm -rf ${directory_name}/*

कृपया लक्षात घ्या की चल directory_name अनिश्चित.

अशा परिस्थिती हाताळण्यासाठी अंगभूत फंक्शन्स वापरणे महत्त्वाचे आहे setजसे की set -o errexit, set -o pipefail किंवा set -o nounset स्क्रिप्टच्या सुरुवातीला. ही फंक्शन्स खात्री करतात की तुमची स्क्रिप्ट शुन्य नसलेला एक्झिट कोड, अपरिभाषित व्हेरिएबल्सचा वापर, पाईपवर जाणाऱ्या अवैध कमांड इ. समोर येताच बाहेर पडेल:

#!/usr/bin/env bash

set -o errexit
set -o nounset
set -o pipefail

function print_var() {
  echo "${var_value}"
}

print_var

$ ./sample.sh
./sample.sh: line 8: var_value: unbound variable

टीप: अंगभूत फंक्शन्स जसे की set -o errexit, "कच्चा" रिटर्न कोड (शून्य व्यतिरिक्त) येताच स्क्रिप्टमधून बाहेर पडेल. म्हणून सानुकूल त्रुटी हाताळणी सादर करणे चांगले आहे, उदाहरणार्थ:

#!/bin/bash
error_exit() {
  line=$1
  shift 1
  echo "ERROR: non zero return code from line: $line -- $@"
  exit 1
}
a=0
let a++ || error_exit "$LINENO" "let operation returned non 0 code"
echo "you will never see me"
# run it, now we have useful debugging output
$ bash foo.sh
ERROR: non zero return code from line: 9 -- let operation returned non 0 code

अशा प्रकारे स्क्रिप्ट लिहिल्याने तुम्हाला स्क्रिप्टमधील सर्व कमांड्सच्या वर्तनाबद्दल अधिक सावधगिरी बाळगण्यास भाग पाडते आणि तुम्हाला आश्चर्य वाटण्याआधी त्रुटीची शक्यता आहे.

विकासादरम्यान त्रुटी शोधण्यासाठी ShellCheck

असे काहीतरी एकत्रित करणे योग्य आहे शेलचेक सर्वोत्तम पद्धतींविरुद्ध तुमचा बॅश कोड तपासण्यासाठी तुमच्या विकास आणि चाचणी पाइपलाइनमध्ये.

मी ते माझ्या स्थानिक विकास वातावरणात वाक्यरचना, शब्दार्थ आणि कोडमधील काही त्रुटींबद्दल अहवाल मिळविण्यासाठी वापरतो ज्या विकास करताना मी चुकल्या असतील. हे तुमच्या बॅश स्क्रिप्टसाठी एक स्थिर विश्लेषण साधन आहे आणि मी ते वापरण्याची शिफारस करतो.

तुमचे स्वतःचे निर्गमन कोड वापरणे

POSIX मधील रिटर्न कोड हे फक्त शून्य किंवा एक नसून शून्य किंवा शून्य नसलेले मूल्य आहे. विविध त्रुटी प्रकरणांसाठी सानुकूल त्रुटी कोड (२०१-२५४ दरम्यान) परत करण्यासाठी या वैशिष्ट्यांचा वापर करा.

ही माहिती नंतर इतर स्क्रिप्टद्वारे वापरली जाऊ शकते जी तुम्हाला नेमकी कोणत्या प्रकारची त्रुटी आली हे समजून घेण्यासाठी आणि त्यानुसार प्रतिक्रिया देतात:

#!/usr/bin/env bash

SUCCESS=0
FILE_NOT_FOUND=240
DOWNLOAD_FAILED=241

function read_file() {
  if ${file_not_found}; then
    return ${FILE_NOT_FOUND}
  fi
}

टीप: कृपया चुकीने पर्यावरण व्हेरिएबल्स ओव्हरराइड होऊ नये म्हणून तुम्ही परिभाषित केलेल्या व्हेरिएबल नावांबाबत विशेष काळजी घ्या.

लॉगिंग कार्ये

तुमच्या स्क्रिप्टचे परिणाम सहज समजण्यासाठी सुंदर आणि संरचित लॉगिंग महत्त्वाचे आहे. इतर उच्च-स्तरीय प्रोग्रामिंग भाषांप्रमाणे, मी नेहमी माझ्या बॅश स्क्रिप्टमध्ये नेटिव्ह लॉगिंग फंक्शन्स वापरतो, जसे की __msg_info, __msg_error आणि त्यामुळे वर.

हे फक्त एकाच ठिकाणी बदल करून प्रमाणित लॉगिंग संरचना प्रदान करण्यात मदत करते:

#!/usr/bin/env bash

function __msg_error() {
    [[ "${ERROR}" == "1" ]] && echo -e "[ERROR]: $*"
}

function __msg_debug() {
    [[ "${DEBUG}" == "1" ]] && echo -e "[DEBUG]: $*"
}

function __msg_info() {
    [[ "${INFO}" == "1" ]] && echo -e "[INFO]: $*"
}

__msg_error "File could not be found. Cannot proceed"

__msg_debug "Starting script execution with 276MB of available RAM"

मी सहसा माझ्या स्क्रिप्टमध्ये एक प्रकारची यंत्रणा ठेवण्याचा प्रयत्न करतो __init, जेथे अशा लॉगर व्हेरिएबल्स आणि इतर सिस्टम व्हेरिएबल्स इनिशियलाइज केले जातात किंवा डीफॉल्ट व्हॅल्यूवर सेट केले जातात. हे व्हेरिएबल्स स्क्रिप्ट इनव्होकेशन दरम्यान कमांड लाइन पर्यायांमधून देखील सेट केले जाऊ शकतात.

उदाहरणार्थ, असे काहीतरी:

$ ./run-script.sh --debug

जेव्हा अशी स्क्रिप्ट कार्यान्वित केली जाते, तेव्हा ते सुनिश्चित करते की सिस्टम-व्यापी सेटिंग्ज आवश्यक असल्यास ते डीफॉल्ट मूल्यांवर सेट केले जातात किंवा आवश्यक असल्यास योग्य काहीतरी सुरू केले जातात.

मी सामान्यतः वापरकर्ता इंटरफेस आणि वापरकर्त्याने ज्या कॉन्फिगरेशनचा शोध घेतला पाहिजे/त्या कॉन्फिगरेशनच्या तपशीलांमधील ट्रेड-ऑफवर काय सुरू करावे आणि काय करू नये या निवडीचा आधार घेतो.

पुनर्वापर आणि स्वच्छ प्रणाली स्थितीसाठी आर्किटेक्चर

मॉड्यूलर/पुन्हा वापरण्यायोग्य कोड

├── framework
│   ├── common
│   │   ├── loggers.sh
│   │   ├── mail_reports.sh
│   │   └── slack_reports.sh
│   └── daily_database_operation.sh

मी एक वेगळा रेपॉजिटरी ठेवतो जो मी विकसित करू इच्छित नवीन प्रोजेक्ट/बॅश स्क्रिप्ट सुरू करण्यासाठी वापरू शकतो. पुनर्वापर करता येणारी कोणतीही गोष्ट रेपॉजिटरीमध्ये संग्रहित केली जाऊ शकते आणि ती कार्यक्षमता वापरू इच्छित असलेल्या इतर प्रकल्पांद्वारे पुनर्प्राप्त केली जाऊ शकते. अशा प्रकारे प्रकल्प आयोजित केल्याने इतर स्क्रिप्ट्सचा आकार लक्षणीयरीत्या कमी होतो आणि कोड बेस लहान आणि तपासण्यास सोपा आहे याची देखील खात्री होते.

वरील उदाहरणाप्रमाणे, सर्व लॉगिंग फंक्शन्स जसे की __msg_info, __msg_error आणि इतर, जसे की स्लॅक अहवाल, मध्ये स्वतंत्रपणे समाविष्ट आहेत common/* आणि इतर परिस्थितींमध्ये डायनॅमिकली कनेक्ट करा daily_database_operation.sh.

स्वच्छ प्रणाली मागे सोडा

स्क्रिप्ट चालू असताना तुम्ही कोणतीही संसाधने लोड करत असल्यास, असा सर्व डेटा यादृच्छिक नावाने शेअर केलेल्या निर्देशिकेत संग्रहित करण्याची शिफारस केली जाते, उदा. /tmp/AlRhYbD97/*. निर्देशिका नाव निवडण्यासाठी तुम्ही यादृच्छिक मजकूर जनरेटर वापरू शकता:

rand_dir_name="$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 16 | head -n 1)"

काम पूर्ण झाल्यानंतर, वर चर्चा केलेल्या हुक हँडलर्समध्ये अशा डिरेक्टरी साफ केल्या जाऊ शकतात. तात्पुरत्या डिरेक्टरीजची काळजी न घेतल्यास, ते जमा होतात आणि काही टप्प्यावर होस्टवर अनपेक्षित समस्या निर्माण होतात, जसे की पूर्ण डिस्क.

लॉक फाइल्स वापरणे

बऱ्याचदा तुम्हाला हे सुनिश्चित करावे लागते की स्क्रिप्टचा फक्त एकच प्रसंग होस्टवर कोणत्याही वेळी चालू आहे. हे लॉक फाइल्स वापरून केले जाऊ शकते.

मी सहसा लॉक फाइल्स तयार करतो /tmp/project_name/*.lock आणि स्क्रिप्टच्या सुरुवातीला त्यांची उपस्थिती तपासा. हे स्क्रिप्ट सुंदरपणे संपुष्टात आणण्यास मदत करते आणि समांतर चालू असलेल्या दुसर्‍या स्क्रिप्टद्वारे सिस्टम स्थितीत अनपेक्षित बदल टाळण्यास मदत करते. तुम्हाला दिलेल्या होस्टवर समांतरपणे कार्यान्वित करण्यासाठी समान स्क्रिप्टची आवश्यकता असल्यास लॉक फाइल्सची आवश्यकता नाही.

मोजा आणि सुधारा

आम्हाला बऱ्याचदा दैनंदिन डेटाबेस ऑपरेशन्ससारख्या दीर्घकाळ चालणाऱ्या स्क्रिप्ट्ससह कार्य करण्याची आवश्यकता असते. अशा ऑपरेशन्समध्ये सामान्यत: चरणांचा क्रम समाविष्ट असतो: डेटा लोड करणे, विसंगती तपासणे, डेटा आयात करणे, स्थिती अहवाल पाठवणे इ.

अशा प्रकरणांमध्ये, मी नेहमी स्क्रिप्टला वेगळ्या छोट्या स्क्रिप्टमध्ये मोडण्याचा प्रयत्न करतो आणि त्यांची स्थिती आणि अंमलबजावणी वेळ वापरून अहवाल देतो:

time source "${filepath}" "${args}">> "${LOG_DIR}/RUN_LOG" 2>&1

नंतर मी यासह अंमलबजावणीची वेळ पाहू शकतो:

tac "${LOG_DIR}/RUN_LOG.txt" | grep -m1 "real"

हे मला स्क्रिप्टमधील समस्या/मंद क्षेत्रे ओळखण्यात मदत करते ज्यांना ऑप्टिमायझेशनची आवश्यकता आहे.

नशीब!

आणखी काय वाचायचे:

स्त्रोत: www.habr.com

बॅश स्क्रिप्टिंग सर्वोत्तम पद्धती: विश्वासार्ह आणि कार्यक्षम बॅश स्क्रिप्ट्ससाठी एक द्रुत मार्गदर्शक