शेल स्क्रिप्टिंग के नुकसान

ग्राफिक्स के व्यापक उपयोग के बावजूद, शेल आज तक इसकी प्रासंगिकता नहीं खोता है। और कभी-कभी यह आपको ग्राफिकल वातावरण की तुलना में बहुत तेज और आसान संचालन करने की अनुमति देता है। हालाँकि, कई ऐसी चीजें हैं जिनसे ज्यादातर लोग अनजान हैं।
मैं किसी विशेष शेल के साथ संलग्न नहीं होना चाहूंगा, फिर भी, नीचे चर्चा की गई संभावनाओं में से प्रत्येक POSIX संगत नहीं हो सकती है, हालांकि यह ksh / bash / zsh में काम करने की गारंटी होगी।

1. चर और परीक्षण

यह कोई रहस्य नहीं है कि शेल में आप तार, संख्या और यहां तक ​​कि चर की तुलना कर सकते हैं। (:

[[ 2 -eq 3 ]] [[ "test" == "test" ]] [[ $VAR -eq 3 ]] 

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

 $ V=V ; [[ V -eq 12 ]] -bash: [[: V: expression recursion level exceeded (error token is "V") 

2. थर्ड पार्टी यूटिलिटीज के बिना सबस्क्रिप्शन से वेरिएबल प्राप्त करें

मान लें कि हमारे पास एक सरल डिजाइन है:

 do_something | while read LINE ; do export VAR_N=${LINE##%*} ; done 

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

 VAR=$(cycle) VAR_N=$(echo "$VAR"|sed 'magic_sed') 

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

 OLD__IFS="$IFS" IFS='~' #    set -- $(cycle) VAR_N="$1" VAR_NN="$2" IFS="$OLD__IFS" 

और यह बहुत साफ है, और अगर इसे ठीक करना ज्यादा आसान है, तो हर बार नियमित आइटम रीमेक करना।

3. पाइप से डेटा का हिस्सा छिपाएं

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

 $ ( { echo DATA ; echo HIDDEN_DATA >&2 ; } | sed 's/^/MODIFIED_/' ) 2>&1 | sed s/$/_CATCHED/ HIDDEN_DATA_CATCHED MODIFIED_DATA_CATCHED 

4. मैं टीमों के इतिहास को पार्स करना चाहता हूं

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

5. मुझे याद है कि if .. then .. else .. fi से अलग है .. && .. || .. .. && .. || ..

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

 if $(condition); then com_1; else com_2; fi condition && com_1 || com_2 

स्पष्ट अंतर यह है कि पहले मामले में, com_2 को केवल एक मामले में निष्पादित किया जाएगा: स्थिति झूठी वापस आ जाएगी।
दूसरे मामले में, com_2 लॉन्च किया जाएगा यदि स्थिति झूठी हो, साथ ही साथ com_1 त्रुटि देता है। विश्वास नहीं होता? अपने लिए देखें:

  $ if true ; then false ; else echo 'hello' ; fi $ true && false || echo 'hello' hello 

खैर, शायद यह सब है। मैं अपनी प्रिय सीड के बारे में कुछ शब्दों में कहना चाहता था, लेकिन पहले से ही यह किसी भी तरह लंबे समय के लिए हुआ। शायद दूसरी बार (: