अनुमति नियम ग्लोब जैसे दिखते हैं और उनसे सँकरे बर्ताव करते हैं, और परेशानी वहीं से शुरू होती है। नियम कमांड से वैसे ही मिलाया जाता है जैसा वह लिखा है, और अंत में कोई छिपा वाइल्डकार्ड नहीं होता: जो नियम एक टेस्ट कमांड को ढकता है, वह उसी कमांड को एक विकल्प लग जाने पर नहीं ढकता। मनाही पूछने पर भारी है, पूछना अनुमति पर, और जो किसी से नहीं मिलता वह मौजूदा मोड के डिफ़ॉल्ट पर चला जाता है। यह सब कहना आसान है और एक दर्जन नियम लिखते हुए दिमाग़ में रखना मुश्किल। यहाँ इन्हें आज़माया जा सकता है: नियम चिपकाइए, वे कमांड चिपकाइए जो चलाने का इरादा है, और हर एक का नतीजा उस नियम के साथ देखिए जिसने फ़ैसला किया। यह उन नियमों को भी ढूँढ़ता है जो कभी चल ही नहीं सकते, जिनमें किसी व्यापक मनाही के नीचे दबी अनुमति भी शामिल है।
विशेषताएँ
हर कमांड, उसका नतीजा और फ़ैसला करने वाला नियम
मनाही > पूछो > अनुमति, ठीक असली क्रम की तरह
ऐसे नियम ढूँढ़ता है जो व्यापक नियम की वजह से कभी नहीं चलेंगे
मनाही से पहुँच से बाहर हो चुकी अनुमति को पकड़ता है
जो पंक्तियाँ नियम हैं ही नहीं उनकी सूचना देता है
बिना मेल वाले कमांड अनुमान लगाने के बजाय वैसे ही दिखाता है
वाइल्डकार्ड जैसे लिखे हैं वैसे — कोई अदृश्य अंतिम मेल नहीं
settings.json का अनुमति ब्लॉक निकालता है
अनुमति नियम परीक्षक का उपयोग कैसे करें
अपने अनुमति, पूछो और मनाही नियम चिपकाइए
जो कमांड चलाने का इरादा है वे चिपकाइए
हर एक का नतीजा और फ़ैसला करने वाला नियम पढ़िए
अनुमति ब्लॉक settings.json में कॉपी कीजिए
उदाहरण
इनपुट
Bash(npm run test)
आउटपुट
npm run test:unit — no rule matched
कोई छिपा वाइल्डकार्ड नहीं: नियम ठीक इसी कमांड को ढकता है।
सामान्य त्रुटियाँ और समस्या निवारण
मेरा नियम अपेक्षित कमांड को नहीं ढकता। — अंत में वाइल्डकार्ड नहीं होता। Bash(npm run test) सिर्फ़ उसी कमांड से मिलता है; रूपों के लिए Bash(npm run test:*) लीजिए।
अनुमति दिए कमांड पर भी पूछा जा रहा है। — ज़्यादा प्राथमिकता वाला कुछ मिल गया है। हर कमांड के लिए सभी मिलने वाले नियम उसी क्रम में दिखाए जाते हैं जिसमें वे सुलझते हैं।
मेरा एक नियम पहुँच से बाहर बताया जा रहा है। — बराबर या ज़्यादा प्राथमिकता वाला कोई व्यापक नियम पहले ही सब कुछ ढक रहा है। व्यापक मनाही के नीचे अनुमति आम मामला है: मनाही हमेशा जीतती है, इसलिए वह अनुमति कुछ नहीं करती।
किसी पंक्ति को नियम नहीं बताया गया। — नियम Tool या Tool(पैटर्न) होते हैं। बिना उपकरण उपसर्ग का अकेला कमांड नियम नहीं है और छोड़ दिया जाता है।
अक्सर पूछे जाने वाले प्रश्न
पैटर्न ग्लोब है या रेगुलर एक्सप्रेशन?
ठीक-ठीक कोई नहीं। यह अक्षरशः मेल है जिसमें * किसी भी अक्षर-शृंखला का प्रतीक है, और यह कमांड पर वैसे ही लगता है जैसा वह लिखा है। रेगुलर एक्सप्रेशन की भाषा सादे पाठ की तरह ली जाती है।
जिस कमांड से कोई नियम नहीं मिलता उसका क्या होता है?
वह मौजूदा अनुमति मोड के डिफ़ॉल्ट व्यवहार पर चला जाता है, जो पूछना भी हो सकता है और अनुमति देना भी। यहाँ उन्हें अनुमान लगाने के बजाय «कोई मेल नहीं» दिखाया जाता है, क्योंकि जवाब नियमों पर नहीं, मोड पर निर्भर है।
कई मिलें तो जीतता कौन है?
मनाही, फिर पूछो, फिर अनुमति। हर कमांड के सभी मेल दिखाए जाते हैं ताकि दिखे कि किसे दबाया गया, अनुमान न लगाना पड़े।
मनाही के नीचे अनुमति क्यों दिखाई जाती है?
क्योंकि वह अनुमति कभी असर नहीं कर सकती — मनाही हमेशा जीतती है। लोग इसे व्यापक मनाही के अपवाद की तरह लिखते हैं, और कोई त्रुटि नहीं बताती कि उसने कुछ किया ही नहीं।
ज़्यादातर अनुमति नियम लिखें या मनाही के?
टिकते मनाही वाले हैं। अनुमति सूची रोज़मर्रा के काम को चुप करा देती है; मनाही सूची ठीक वही रोकती है जो आप कभी नहीं चाहते, और वह बाक़ी सब पर भारी है।
संबंधित टूल
हुक बिल्डर — settings.json के हुक बनाइए और कभी न चलने वाले मैचर पकड़िए।
सबएजेंट बिल्डर — सबएजेंट की परिभाषा फ़ाइल बनाइए, उसके उपकरण और मॉडल समेत।