बैश में महारत: सिसएडमिन के लिए परम गाइड

प्रत्येक ट्रेड का एक उपकरण होता है जिसे उस ट्रेड के मास्टर सबसे अधिक उपयोग करते हैं। कई सिसएडमिन के लिए, वह उपकरण उनका शेल है। अधिकांश लिनक्स और अन्य यूनिक्स-जैसे सिस्टम पर, डिफ़ॉल्ट शेल बैश है।

बैश एक काफी पुराना प्रोग्राम है—यह 1980 के दशक के अंत में उत्पन्न हुआ—लेकिन यह बहुत पुराने शेल पर बनाता है, जैसे C शेल (csh), जो आसानी से इसका 10 साल सीनियर है। क्योंकि शेल की अवधारणा इतनी पुरानी है, वहां गूढ़ ज्ञान की एक विशाल मात्रा मौजूद है जो किसी भी सिसएडमिन के जीवन को बहुत आसान बनाने की प्रतीक्षा कर रही है।

आइए कुछ बुनियादी बातों पर नज़र डालते हैं।

एलियास का उपयोग करें

सबसे पहले, mv और rm जैसे कमांड के लिए एलियास सेट करें जो mv -i और rm -i की ओर इंगित करते हैं। यह सुनिश्चित करेगा कि rm -f /boot चलाने पर कम से कम आपसे पुष्टि मांगी जाए। रेड हैट एंटरप्राइज लिनक्स में, यदि आप रूट खाते का उपयोग करते हैं तो ये एलियास डिफ़ॉल्ट रूप से सेट होते हैं।

यदि आप अपने सामान्य उपयोगकर्ता खाते के लिए भी उन एलियास को सेट करना चाहते हैं, तो बस इन दो लाइनों को अपने होम डायरेक्टरी में .bashrc नामक फाइल में डालें (ये sudo के साथ भी काम करेंगे):

alias mv='mv -i'
alias rm='rm -i'

अपने रूट प्रॉम्प्ट को अलग बनाएं

गलतियों को रोकने के लिए आप एक और चीज कर सकते हैं वह है यह सुनिश्चित करना कि आप जानते हैं कि आप कब रूट खाते का उपयोग कर रहे हैं। मैं आमतौर पर ऐसा रूट प्रॉम्प्ट को अपने सामान्य, रोजमर्रा के काम के लिए उपयोग किए जाने वाले प्रॉम्प्ट से वास्तव में अच्छी तरह से अलग करके करता हूं।

यदि आप रूट के होम डायरेक्टरी में .bashrc फाइल में निम्नलिखित डालते हैं, तो आपके पास एक रूट प्रॉम्प्ट होगा जो काले पर लाल है, जिससे यह स्पष्ट हो जाता है कि आपको (या किसी और को) सावधानी से चलना चाहिए।

export PS1="\[$(tput bold)$(tput setab 0)$(tput setaf 1)\]\u@\h:\w # \[$(tput sgr0)\]"

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

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

अपने इतिहास को नियंत्रित करें

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

सबसे पहले, आप history टाइप करके अपने संपूर्ण हालिया कमांड इतिहास को देख सकते हैं, या history 30 टाइप करके इसे अपने अंतिम 30 कमांड तक सीमित कर सकते हैं। लेकिन यह बहुत साधारण है। आपके पास इस पर अधिक नियंत्रण है कि बैश क्या सेव करता है और कैसे सेव करता है।

उदाहरण के लिए, यदि आप निम्नलिखित को अपने .bashrc में जोड़ते हैं, तो स्पेस से शुरू होने वाले किसी भी कमांड को हिस्ट्री लिस्ट में सेव नहीं किया जाएगा:

HISTCONTROL=ignorespace

यह उपयोगी हो सकता है यदि आपको किसी कमांड को प्लेनटेक्स्ट में पासवर्ड पास करने की आवश्यकता है। (हां, यह भयानक है, लेकिन यह अभी भी होता है।)

यदि आप नहीं चाहते कि बार-बार निष्पादित कमांड आपके इतिहास में दिखाई दे, तो उपयोग करें:

HISTCONTROL=ignorespace:erasedups

इसके साथ, हर बार जब आप किसी कमांड का उपयोग करते हैं, तो उसके पिछले सभी घटनाओं को हिस्ट्री फाइल से हटा दिया जाता है, और केवल अंतिम आह्वान आपकी हिस्ट्री लिस्ट में सेव होता है।

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

HISTTIMEFORMAT="%F %T "

जब मैं history 5 टाइप करता हूं, तो मुझे अच्छी, पूरी जानकारी मिलती है, जैसे:

1009 2018-06-11 22:34:38 cat /etc/hosts
1010 2018-06-11 22:34:40 echo $foo
1011 2018-06-11 22:34:42 echo $bar
1012 2018-06-11 22:34:44 ssh myhost
1013 2018-06-11 22:34:55 vim .bashrc

इससे मेरे कमांड इतिहास को ब्राउज़ करना और दो दिन पहले उपयोग किए गए उस कमांड को ढूंढना बहुत आसान हो जाता है जिसका उपयोग मैंने अपने होम लैब में SSH टनल सेट करने के लिए किया था (जिसे मैं बार-बार भूल जाता हूं...)।

सर्वश्रेष्ठ बैश प्रैक्टिस

मैं बैश स्क्रिप्ट लिखते समय सर्वोत्तम (या कम से कम अच्छी) प्रथाओं की अपनी शीर्ष 11 सूची के साथ इसे समाप्त करूंगा।

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

10. अपने सभी वेरिएबल नामों को कर्ली ब्रेसिज़ में लपेटें, जैसे ${myvariable}। इसे एक आदत बनाने से ${variable}_suffix जैसी चीजें संभव होती हैं और आपके स्क्रिप्ट में निरंतरता में सुधार होता है।

9. किसी एक्सप्रेशन का मूल्यांकन करते समय बैकटिक्स का उपयोग न करें; इसके बजाय $() सिंटैक्स का उपयोग करें। इसलिए उपयोग करें:
   

   for file in $(ls); do

   नहीं

   for file in `ls`; do

   पहला विकल्प नेस्टेबल है, अधिक आसानी से पढ़ा जा सकता है, और सामान्य सिसएडमिन आबादी को खुश रखता है। बैकटिक्स का उपयोग न करें।

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

7. बैश स्क्रिप्ट के लिए उचित शेबैंग का उपयोग करें। चूंकि मैं बैश स्क्रिप्ट केवल बैश के साथ निष्पादित करने के इरादे से लिखता हूं, इसलिए मैं अक्सर अपने शेबैंग के रूप में #!/usr/bin/bash का उपयोग करता हूं। #!/bin/sh या #!/usr/bin/sh का उपयोग न करें। आपका स्क्रिप्ट निष्पादित होगा, लेकिन यह कम्पैटिबिलिटी मोड में चलेगा—संभावित रूप से बहुत सारे अनपेक्षित साइड इफेक्ट के साथ। (जब तक, निश्चित रूप से, कम्पैटिबिलिटी मोड वही है जो आप चाहते हैं।)

6. स्ट्रिंग्स की तुलना करते समय, अपने वेरिएबल को if-स्टेटमेंट में कोट करना एक अच्छा विचार है, क्योंकि यदि आपका वेरिएबल खाली है, तो बैश इन जैसी लाइनों के लिए एक त्रुटि फेंक देगा:
   

   if [ ${myvar} == "foo" ]; then
   echo "bar"
   fi

   और इस तरह की लाइन के लिए false मूल्यांकन करेगा:

   if [ "${myvar}" == "foo" ]; then
   echo "bar"
   fi

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

5. यह स्वाद की बात है, मुझे लगता है, लेकिन मैं बैश में स्ट्रिंग्स की तुलना करते समय भी डबल इक्वल साइन (==) का उपयोग करना पसंद करता हूं। यह निरंतरता की बात है, और भले ही—केवल स्ट्रिंग तुलना के लिए—एक सिंगल इक्वल साइन काम करेगा, मेरा दिमाग तुरंत "सिंगल इक्वल एक असाइनमेंट ऑपरेटर है!" सोचता है।

4. उचित एग्जिट कोड का उपयोग करें। सुनिश्चित करें कि यदि आपका स्क्रिप्ट कुछ करने में विफल रहता है, तो आप उपयोगकर्ता को एक लिखित विफलता संदेश (अधिमानतः समस्या को ठीक करने के तरीके के साथ) प्रस्तुत करते हैं और एक नॉन-ज़ीरो एग्जिट कोड भेजते हैं:
   

   # we have failed
   echo "Process has failed to complete, you need to manually restart the whatchamacallit"
   exit 1

   यह आपके स्क्रिप्ट को प्रोग्रामेटिक रूप से किसी अन्य स्क्रिप्ट से कॉल करना और इसके सफल समापन को सत्यापित करना आसान बनाता है।

3. बैश के अंतर्निहित तंत्र का उपयोग अपने वेरिएबल के लिए समझदार डिफ़ॉल्ट प्रदान करने या त्रुटियां फेंकने के लिए करें यदि वे वेरिएबल जिन्हें आप परिभाषित होने की अपेक्षा करते हैं, परिभाषित नहीं हैं:
   

   # यह $myvar का मान redhat पर सेट करता है, और 'redhat' प्रिंट करता है
   echo ${myvar:=redhat}

   # यदि $myvar अपरिभाषित है तो 'The variable myvar is undefined, dear reader' पढ़ते हुए एक त्रुटि फेंकता है
   ${myvar:?The variable myvar is undefined, dear reader}

2. विशेष रूप से यदि आप एक बड़ा स्क्रिप्ट लिख रहे हैं, और विशेष रूप से यदि आप उस बड़े स्क्रिप्ट पर दूसरों के साथ काम करते हैं, तो फंक्शन के अंदर वेरिएबल को परिभाषित करते समय local कीवर्ड का उपयोग करने पर विचार करें। local कीवर्ड एक लोकल वेरिएबल बनाएगा, यानी वह जो केवल उस फंक्शन के भीतर दृश्यमान है। यह टकराने वाले वेरिएबल की संभावना को सीमित करता है।

1. हर सिसएडमिन को कभी-कभी करना पड़ता है: कंसोल पर कुछ डीबग करना, या तो डेटा सेंटर में एक वास्तविक या वर्चुअलाइजेशन प्लेटफॉर्म के माध्यम से एक वर्चुअल। यदि आपको उस तरह से एक स्क्रिप्ट डीबग करनी है, तो आप इस बात को याद रखने के लिए खुद को धन्यवाद देंगे: अपने स्क्रिप्ट में लाइन्स को बहुत लंबा न बनाएं!
   
   
   कई सिस्टम पर, कंसोल की डिफ़ॉल्ट चौड़ाई अभी भी 80 कैरेक्टर है। यदि आपको कंसोल पर एक स्क्रिप्ट डीबग करने की आवश्यकता है और उस स्क्रिप्ट में बहुत लंबी लाइनें हैं, तो आप एक दुखी पांडा होंगे। इसके अलावा, छोटी लाइनों वाला स्क्रिप्ट—डिफ़ॉल्ट अभी भी 80 कैरेक्टर है—एक सामान्य एडिटर में पढ़ने और समझने में बहुत आसान है!

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