बाश के लिए एक सिसडमिन की मार्गदर्शिका

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

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

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

किसने, किसी बिंदु पर, अनजाने में एक आदेश को जड़ के रूप में चलाया और किसी प्रकार की समस्या का कारण बना? हाथ उठाता है

मुझे पूरा यकीन है कि हम में से बहुत से लोग एक समय में वह लड़का या लड़की रहे होंगे। बहुत दर्दनाक। यहां कुछ बहुत ही सरल तरकीबें दी गई हैं, जिससे आप उस पत्थर को दूसरी बार मारने से बच सकते हैं।

उपनाम का प्रयोग करें

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

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

alias mv='mv -i'

alias rm='rm -i'

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

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

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

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

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

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

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

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

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

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

HISTCONTROL=ignorespace

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

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

HISTCONTROL=ignorespace:erasedups

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

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

HISTTIMEFORMAT="%F %T  "

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

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

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

सर्वश्रेष्ठ बैश अभ्यास

बैश स्क्रिप्ट लिखते समय मैं इसे सर्वश्रेष्ठ (या अच्छा, कम से कम; मैं सर्वज्ञता का दावा नहीं करता) की अपनी शीर्ष 11 सूची के साथ लपेटूंगा।

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

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

किसी व्यंजक का मूल्यांकन करते समय बैकटिक्स का प्रयोग न करें; $() का उपयोग करें इसके बजाय वाक्यविन्यास। तो उपयोग करें:
```
for  file in $(ls); do
```
नहीं
```
for  file in `ls`; do
```
पूर्व विकल्प नेस्टेबल है, अधिक आसानी से पठनीय है, और सामान्य sysadmin आबादी को खुश रखता है। बैकटिक्स का प्रयोग न करें।

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

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

स्ट्रिंग्स की तुलना करते समय, अपने वेरिएबल को if-statement में उद्धृत करना एक अच्छा विचार है, क्योंकि यदि आपका वेरिएबल खाली है, तो बैश इस तरह की पंक्तियों के लिए एक त्रुटि देगा:
```
if [ ${myvar} == "foo" ]; then

  echo "bar"

fi
```
और इस तरह की लाइन के लिए असत्य का मूल्यांकन करेंगे:
```
if [ "${myvar}" == "foo" ]; then

  echo "bar"

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

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

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

echo "Process has failed to complete, you need to manually restart the whatchamacallit"

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

बैश के अंतर्निहित तंत्र का उपयोग अपने वेरिएबल्स के लिए समझदार डिफ़ॉल्ट प्रदान करने के लिए करें या त्रुटियों को फेंकने के लिए यदि वेरिएबल परिभाषित किए जाने की अपेक्षा करते हैं तो परिभाषित नहीं हैं:
```
# this sets the value of $myvar to redhat, and prints 'redhat'

echo ${myvar:=redhat}
```
```
# this throws an error reading 'The variable myvar is undefined, dear reader' if $myvar is undefined

${myvar:?The variable myvar is undefined, dear reader}
```

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

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

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

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