क्यों [AZ] बैश में लोअरकेस अक्षरों से मेल खाता है?

Question

सभी गोले में मैं अवगत हूं, rm [A-Z]*उन सभी फाइलों को हटा देता है जो एक बड़े अक्षर से शुरू होती हैं, लेकिन बैश के साथ यह उन सभी फाइलों को हटा देती है जो एक पत्र से शुरू होती हैं।

चूंकि यह समस्या bash-3 और bash-4 के साथ Linux और Solaris पर मौजूद है, इसलिए यह libc या मिस-कॉन्फ़िगर की गई स्थानीय परिभाषा में छोटी गाड़ी के पैटर्न मिलान के कारण बग नहीं हो सकता है।

क्या यह अजीब और जोखिम भरा व्यवहार है या यह सिर्फ एक बग है जो कई सालों से अस्तित्व में है?

Comments

localeआउटपुट क्या करता है? मैं इसे पुन: उत्पन्न नहीं कर सकता ( touch foo; echo [A-Z]*शाब्दिक पैटर्न को आउटपुट करता है, न कि "फू", अन्यथा खाली निर्देशिका में)।

— सहकर्मी

यह देखते हुए कि कितने लोगों ने कहा है कि यह उनके लिए काम करता है, या LC_COLLATE इसको कैसे प्रभावित करता है, के उदाहरण दिखाए हैं, हो सकता है कि आप नमूना बैश सत्र को जोड़ने के लिए अपने प्रश्न को संपादित कर सकें, जो आपके द्वारा पूछे जा रहे परिदृश्य को दिखाता है। कृपया बैश संस्करण को शामिल करें जिसका आप उपयोग कर रहे हैं।

— केनस्टर

यदि आपने यहां सभी पाठ पढ़े हैं, तो आपको पता होगा कि मैं किस संस्करण का उपयोग करता हूं और मैंने अपने प्रश्न का हल पहले ही पोस्ट कर दिया था। मुझे समाधान दोहराने दें: bash इसे स्वयं का स्थान प्रबंधित नहीं करता है ताकि LC_COLLATE सेट करना तब तक कुछ भी न बदले जब तक कि आप नए परिवेश के साथ कोई अन्य bash प्रक्रिया प्रारंभ न करें।

— विद्वान

यह भी देखें (चाहिए) LC_COLLATE वर्ण श्रेणियों को प्रभावित करता है? (लेकिन यह सवाल विशेष रूप से बैश के बारे में नहीं था)

— गाइल्स का SO-

"LC_COLLATE सेट करने से कुछ भी नहीं बदलता है जब तक कि आप नए वातावरण के साथ एक और बैश प्रक्रिया शुरू नहीं करते हैं।" सोलारिस पर बाश -4 के साथ मेरे द्वारा देखे गए व्यवहार से मेल नहीं खाता। यह चल रहे शेल में व्यवहार को बदल रहा है। # echo [A-Z]* ; export LC_COLLATE=C ; echo [A-Z]*A b B z ZABZ

— बाउलऑफ्रेडेड

Answer 1

ध्यान दें कि LC_COLLATE की सेटिंग के आधार पर [az] जैसे श्रेणी के भावों का उपयोग करते हुए, अन्य मामले के अक्षर शामिल किए जा सकते हैं।

LC_COLLATE एक वैरिएबल है, जो पथनाम विस्तार के परिणामों को सॉर्ट करते समय उपयोग किए जाने वाले कोलाजेशन ऑर्डर को निर्धारित करता है, और रेंजनाम, समतुल्यता वर्गों के व्यवहार को निर्धारित करता है, और पथनाम विस्तार और पैटर्न मिलान के भीतर अनुक्रम को टकराता है।

---

निम्नलिखित को धयान मे रखते हुए:

$ touch a A b B c C x X y Y z Z
$ ls
a  A  b  B  c  C  x  X  y  Y  z  Z
$ echo [a-z] # Note the missing uppercase "Z"
a A b B c C x X y Y z
$ echo [A-Z] # Note the missing lowercase "a"
A b B c C x X y Y z Z

ध्यान दें कि जब कमांड echo [a-z]को बुलाया जाता है, तो अपेक्षित आउटपुट लोअर केस कैरेक्टर वाली सभी फाइलें होंगी। इसके अलावा, echo [A-Z]अपरकेस कैरेक्टर्स वाली फाइल की उम्मीद की जाएगी।

---

en_USनिम्न क्रम वाले स्थानों के साथ मानक टकराव :

aAbBcC...xXyYzZ

• बीच aऔर z(में [a-z]) सभी बड़े अक्षरों, के अलावा हैं Z।
• बीच Aऔर Z(में [A-Z]) सभी छोटे अक्षरों, के अलावा हैं a।

देख:

     aAbBcC[...]xXyYzZ
     |              |
from a      to      z

     aAbBcC[...]xXyYzZ
      |              |
from  A     to       Z

यदि आप LC_COLLATEवैरिएबल को बदलते हैं तो Cयह अपेक्षित है:

$ export LC_COLLATE=C
$ echo [a-z]
a b c x y z
$ echo [A-Z]
A B C X Y Z

तो, यह बग नहीं है , यह एक टकराव का मुद्दा है ।

---

श्रेणी अभिव्यक्तियों के बजाय आप POSIX परिभाषित वर्ण वर्गों का उपयोग कर सकते हैं , जैसे upperया lower। वे विभिन्न LC_COLLATEविन्यासों के साथ और यहां तक ​​कि उच्चारण पात्रों के साथ भी काम करते हैं :

$ echo [[:lower:]]
a b c x y z à è é
$ echo [[:upper:]]
A B C X Y Z

Comments

यदि यह व्यवहार LC_ * पर्यावरण चर द्वारा नियंत्रित किया गया था, तो मैंने नहीं पूछा। मैं POSIX मानक समिति में काम करता हूं और मैं उदाहरण के साथ समस्याओं को trसमाप्‍त करने के बारे में जानता हूं।

— विद्वान

@ सामान्य रूप से मैं आपकी समस्या को न तो पुराने बैश -3 या बैश -4 के साथ पुन: पेश कर सकता हूं; दोनों नियंत्रणीय हैं LC_COLLATEजिसके माध्यम से मैनुअल में भी प्रलेखित है।

— अराजकता

क्षमा करें, आप जो भी मानते हैं, मैं उसे पुन: प्रस्तुत नहीं कर सकता, लेकिन मेरा स्वयं का उत्तर देखें ... इस चर्चा में विचारों से मैंने समस्या का कारण खोजा।

— विद्वान

Answer 2

[A-Z]bashसभी मेल खाने वाले तत्वों (वर्ण लेकिन Dszहंगेरियन लोकेशन्स जैसे वर्णों का अनुक्रम भी होना चाहिए ) से मेल खाते हैं जो Aपहले और बाद में क्रमबद्ध होते हैं Z। आपके स्थान पर, cसंभवतः B और C के बीच में है।

$ printf '%s\n' A a á b B c C Ç z Z Ẑ | sort
a
A
á
b
B
c
C
Ç
z
Z
Ẑ

तो cया zद्वारा मिलान किया जाएगा [A-Z], लेकिन नहीं Ẑया नहीं a।

$ printf '%s\n' A a á b B c C Ç z Z Ẑ |
pipe>  bash -c 'while IFS= read -r x; do case $x in [A-Z]) echo "$x"; esac; done'
A
á
b
B
c
C
Ç
z
Z

सी लोकेल में, आदेश होगा:

$ printf '%s\n' A a á b B c C Ç z Z Ẑ | LC_COLLATE=C sort
A
B
C
Z
a
b
c
z
Ç
á
Ẑ

तो [A-Z]मेल खाएंगे A, B, C, Z, लेकिन नहीं Çहै और अभी भी नहीं Ẑ।

यदि आप ऊपरी-केस अक्षरों (किसी भी स्क्रिप्ट में) पर मिलान करना चाहते हैं, तो आप [[:upper:]]इसके बजाय उपयोग कर सकते हैं । लैटिन लिपि bashमें केवल अपरकेस अक्षरों से मेल खाने का कोई अंतर्निहित तरीका नहीं है (व्यक्तिगत रूप से सूचीबद्ध करने के अलावा)।

आप मैच के लिए चाहते हैं Aके लिए Z अंग्रेजी विशेषक बिना पत्र, या तो आप उपयोग कर सकते हैं [A-Z]या [[:upper:]]लेकिन में Cस्थान (डेटा संभालने बिग 5 या GB18030 जो कई पात्रों जिसका एन्कोडिंग है जैसे वर्ण सेट में एन्कोड नहीं है शामिल है या सूची उन पत्रों की एन्कोडिंग) उन्हें व्यक्तिगत रूप से ( [ABCDEFGHIJKLMNOPQRSTUVWXYZ])।

ध्यान दें कि गोले के बीच कुछ भिन्नता है।

के लिए zsh, bash -O globasciiranges(bash-4.3 में विचित्र रूप से नाम दिया गया विकल्प), schily-shऔर yash, [A-Z]उन वर्णों से मेल खाता है जिनका कोड बिंदु उसके और उसके बीच Aका है Z, इसलिए bashC लोकेल के व्यवहार के बराबर होगा ।

राख, mksh और प्राचीन गोले के लिए, zshऊपर के रूप में, लेकिन एकल-बाइट वर्णमाला तक सीमित। उदाहरण के लिए, UTF-8 लोकेल में, [É-Ź]मेल नहीं खाएगा Ó, लेकिन इसके बाद से [<c3><89>-<c5><b9>], यह बाइट मान 0x89 से 0xc5 पर मेल करेगा!

ksh93की तरह बर्ताव करता है bashसिवाय इसके कि यह विशेष मामलों पर्वतमाला जिसका समाप्त होता है दोनों छोटे अक्षरों या बड़े अक्षरों के साथ शुरू के रूप में व्यवहार करता है। उस मामले में, यह केवल तत्वों का मिलान पर से मेल खाता है उस तरह उन समाप्त होता है, लेकिन बीच में है कि कर रहे हैं (या बहु चरित्र का मिलान तत्वों के लिए अपनी पहली चरित्र) भी लोअरकेस (या अपरकेस क्रमशः)। तो [A-Z]वहाँ पर से मेल खाएंगे É, लेकिन पर नहीं eके रूप में eके बीच तरह से करता है Aऔर Zलेकिन जैसे अपरकेस नहीं है Aऔर Z।

के लिए fnmatch()पैटर्न (के रूप में find -name '[A-Z]') या सिस्टम नियमित अभिव्यक्ति (के रूप में grep '[A-Z]'), यह प्रणाली और स्थान पर निर्भर करता है। उदाहरण के लिए, यहाँ एक GNU सिस्टम [A-Z]पर x, en_GB.UTF-8लोकेल में मेल नहीं खाता है , लेकिन यह th_TH.UTF-8एक में करता है । यह मेरे लिए स्पष्ट नहीं है कि यह निर्धारित करने के लिए कौन सी जानकारी का उपयोग करता है, लेकिन यह जाहिरा तौर पर LC_COLLATE स्थानीय डेटा से प्राप्त लुकअप तालिका पर आधारित है )।

POSIX द्वारा सभी व्यवहारों की अनुमति दी जाती है क्योंकि POSIX सी लोकेल के अलावा अन्य स्थानों में अनिर्दिष्ट श्रेणियों के व्यवहार को छोड़ देता है। अब हम प्रत्येक दृष्टिकोण के लाभों पर बहस कर सकते हैं।

bashदृष्टिकोण बहुत समझ में आता है [C-G], हम चाहते हैं कि पात्रों के बीच Cऔर G। और जो बीच-बीच में निर्धारित करता है, उसके लिए उपयोगकर्ता के क्रमबद्ध आदेश का उपयोग करना सबसे तार्किक दृष्टिकोण है।

अब, समस्या यह है कि यह बहुत से लोगों की अपेक्षाओं को तोड़ता है, विशेष रूप से उन लोगों ने पूर्व-यूनिकोड के पारंपरिक व्यवहार, यहां तक ​​कि पूर्व-अंतर्राष्ट्रीयकरण के दिनों में भी इस्तेमाल किया। जबकि एक सामान्य उपयोगकर्ता से, यह मई अर्थ है कि बनाता है [C-I]शामिल है hके रूप में hपत्र के बीच है Cऔर Iऔर कहा कि [A-g]शामिल नहीं है Z, यह लोगों को केवल दशकों के लिए ASCII के साथ पेश होने के लिए एक अलग बात है।

वह bashव्यवहार भी [A-Z]अन्य GNU टूल्स जैसे कि GNU रेगुलर एक्सप्रेशंस (जैसे grep/ sed...) में या के fnmatch()रूप में मेल खाते रेंज से अलग है find -name।

इसका अर्थ यह भी है कि [A-Z]ओएस के साथ और ओएस के संस्करण के साथ पर्यावरण के साथ क्या मेल खाता है। यह तथ्य कि [A-Z]fact लेकिन Ź से मेल नहीं खाता है, वह भी उप-समरूप है।

के लिए zsh/ yash, हम एक अलग छंटाई आदेश का उपयोग करें। चरित्र के आदेश की उपयोगकर्ता की धारणा पर भरोसा करने के बजाय, हम चरित्र बिंदु कोड मूल्यों का उपयोग करते हैं। यह समझने में आसान होने का लाभ है, लेकिन कुछ के व्यावहारिक बिंदु से, एएससीआईआई के बाहर, यह बहुत उपयोगी नहीं है। [A-Z]26 US-english ऊपरी-केस अक्षरों से [0-9]मेल खाता है , दशमलव अंकों से मेल खाता है। यूनिकोड में कोड बिंदु हैं जो कुछ वर्णमालाओं के क्रम का पालन करते हैं लेकिन यह सामान्यीकृत नहीं है और इसे सामान्यीकृत नहीं किया जा सकता है क्योंकि वैसे ही एक ही स्क्रिप्ट का उपयोग करने वाले विभिन्न लोग अक्षरों के क्रम पर सहमत नहीं होते हैं।

पारंपरिक गोले और mksh, डैश के लिए, यह टूट गया है (अब ज्यादातर लोग मल्टी-बाइट वर्ण का उपयोग करते हैं), लेकिन मुख्य रूप से क्योंकि उनके पास अभी तक मल्टी-बाइट का समर्थन नहीं है। गोले की तरह बहु-बाइट समर्थन जोड़ना bashऔर zshएक बड़ा प्रयास रहा है और अभी भी जारी है। yash(एक जापानी शेल) को शुरू से मल्टी-बाइट समर्थन के साथ डिजाइन किया गया था।

ksh93 के दृष्टिकोण को सिस्टम की नियमित अभिव्यक्तियों या fnmatch () के साथ सुसंगत होने का लाभ है (या कम से कम GNU सिस्टम पर कम से कम दिखाई देता है)। वहाँ, यह कुछ लोगों की अपेक्षाओं को नहीं तोड़ता है के रूप में [A-Z]छोटे अक्षरों, शामिल नहीं है [A-Z]शामिल है É(और एक नहीं, बल्कि z)। यह sortया आम तौर पर strcoll()आदेश के अनुरूप नहीं है ।

Comments

यदि आप सही थे, तो इसे LC_ * चर के माध्यम से नियंत्रित किया जा सकता है। एक अलग कारण लगता है।

— विद्वान

@cuonglm, अधिक पसंद mksh(दोनों pdksh से प्राप्त)। posh -c $'case Ó in [É-Ź]) echo yes; esac'कुछ नहीं देता।

— स्टीफन चेजालस

@ सामान्य रूप से, मैं उल्लेख करता हूं sortक्योंकि bashग्लोब चरित्र प्रकार के क्रम पर आधारित हैं। वर्तमान में मेरे पास इस तरह के पुराने संस्करण तक पहुंच नहीं है bash, लेकिन मैं बाद में जांच कर सकता हूं। क्या यह तब अलग था?

— स्टीफन चेजालस

मुझे फिर से उल्लेख करें: zsh, POSIX-ksh88, ksh93t + Bourne Shell, सभी उसी तरह व्यवहार करते हैं जैसे मैं उम्मीद करता हूं। बैश एकमात्र शेल है जो अलग व्यवहार करता है और बैश इस मामले में लोकेल के माध्यम से नियंत्रणीय नहीं है।

— विद्वान

@schily, ध्यान दें कि \xFFवहाँ बाइट 0xFF, नहीं चरित्र U + 00FF ( ÿखुद 0xC3 0xBF के रूप में एन्कोड)। \xFFअकेला एक वैध चरित्र नहीं बनाता है, इसलिए मैं यह नहीं देख सकता कि इसे क्यों मिलना चाहिए [É-Ź]।

— स्टीफन चेजलस 22

Answer 3

इसका उद्देश्य और bashप्रलेखन, पैटर्न मिलान अनुभाग में प्रलेखित है । रेंज अभिव्यक्ति [X-Y]के बीच कोई भी वर्ण शामिल किया जाएगा Xऔर Yवर्तमान स्थान के क्रमवार अनुक्रम और वर्ण सेट का उपयोग:

LC_ALL=en_US.utf8 bash -c 'case b in [A-Z]) echo yes; esac' 
yes

आप देख सकते हैं, के bबीच Aऔर स्थान Zमें क्रमबद्ध en_US.utf8।

इस व्यवहार को रोकने के लिए आपके पास कुछ विकल्प हैं:

# Setting LC_ALL or LC_COLLATE to C
LC_ALL=C bash -c 'echo [A-Z]*'

# Or using POSIX character class
LC_ALL=C bash -c 'echo [[:upper:]]*'

या सक्षम globasciiranges(बाश 4.3 और ऊपर के साथ):

bash -O globasciiranges -c 'echo [A-Z]*'

Answer 4

मैंने एक नए अमेज़ॅन EC2 उदाहरण पर इस व्यवहार का अवलोकन किया। चूंकि ओपी ने MCVE की पेशकश नहीं की , इसलिए मैं एक पोस्ट करूंगा:

$ cd $(mktemp -d)
$ touch foo
$ echo [A-Z]*     # prepare for a surprise!
foo

$ echo $BASH_VERSION
4.1.2(1)-release
$ uname -a
Linux spinup-tmp12 3.14.27-25.47.amzn1.x86_64 #1 SMP Wed Dec 17 18:36:15 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ env | grep LC_  # no locale, let's set one
$ LC_ALL=C
$ echo [A-Z]*
[A-Z]*

$ unset LC_ALL    # ok, good. what if we go back to no locale?
$ echo [A-Z]*
foo

तो, मेरा LC_*सेट नहीं होने से 4.1.2 (1) बैश हो जाता है, लिनक्स पर-जाहिरा तौर पर विषम व्यवहार का उत्पादन करने के लिए। मैं संबंधित स्थानीय चर को सेट और अनसेट करके विषम व्यवहार को मज़बूती से पकड़ सकता हूं। अप्रत्याशित रूप से, यह व्यवहार निर्यात के माध्यम से सुसंगत प्रतीत होता है:

$ export LC_ALL=C
$ bash
$ echo [A-Z]*
[A-Z]*
$ exit
$ echo $SHLVL
1
$ unset LC_ALL
$ bash
$ echo [A-Z]*
foo

जब मैं बैश को स्टैफेन "शेलशॉक" के रूप में देख रहा हूं , चेज़ल ने जवाब दिया , मुझे लगता है कि पैटर्न मिलान पर बैश प्रलेखन छोटी गाड़ी है:

उदाहरण के लिए, में डिफ़ॉल्ट सी लोकेल , '[एक-dx-z]' के समान है '[abcdxyz]'

मैंने उस वाक्य (जोर मेरा) के रूप में पढ़ा "यदि प्रासंगिक लोकल चर सेट नहीं किए जाते हैं, तो सी लोकेल में बैश होगा"। बैश ऐसा करते नहीं दिखाई देते। इसके बजाय यह एक स्थान पर डिफ़ॉल्ट करने के लिए प्रतीत होता है जहां वर्णों को डिआक्रिटिक तह के साथ शब्दकोश क्रम में क्रमबद्ध किया जाता है:

$ echo [A-E]*
[A-E]*
$ echo [A-F]*
foo
$ touch "évocateur"
$ echo [A-F]*
foo évocateur

मुझे लगता है कि यह दस्तावेज के लिए अच्छा होगा कि यह कैसे व्यवहार करेगा जब LC_*(विशेष रूप LC_CTYPEसे LC_COLLATE) अपरिभाषित हो। लेकिन इस बीच, मैं कुछ ज्ञान साझा करूंगा :

... आपको [चरित्र श्रेणियों] के साथ बहुत सावधान रहना होगा क्योंकि वे अपेक्षित परिणाम नहीं देंगे जब तक कि ठीक से कॉन्फ़िगर न किया जाए। अभी के लिए, आपको उनका उपयोग करने से बचना चाहिए और इसके बजाय चरित्र वर्गों का उपयोग करना चाहिए।

तथा

यदि आप वास्तव में उचित हैं, और / या एक बहु-स्थानीय वातावरण के लिए स्क्रिप्टिंग कर रहे हैं, तो संभवतः यह सुनिश्चित करना सबसे अच्छा है कि आप जानते हैं कि जब आप फ़ाइलों का मिलान कर रहे हैं, या जब आप कोडिंग कर रहे हैं, तो सुनिश्चित करें कि आपके लोकल वेरिएबल क्या हैं पूरी तरह से सामान्य तरीका है।

---

अपडेट @ जी-मैन टिप्पणी के आधार पर, आइए देखें कि क्या हो रहा है:

$ env | grep LANG
LANG=en_US.UTF-8

आह, हा! इससे पहले देखा गया कोलाज बताते हैं। आइए सभी स्थानीय चर निकालें:

$ unset LANG LANGUAGE LC_ALL
$ env | grep 'LC_|LANG'
$ echo [A-Z]*
[A-Z]*

हम वहाँ चलें। अब इस लिनक्स सिस्टम पर प्रलेखन के संबंध में बैश लगातार चल रहा है। स्थान चर के किसी भी सेट कर रहे हैं ( LANGUAGE, LANG, LC_COLLATE, LC_CTYPE, LC_ALL, आदि) तो बैश अपनी पुस्तिका के अनुसार उन का उपयोग करता है। अन्यथा, बैश वापस सी पर गिर जाता है।

Wooledge बैश पूछे जाने वाले प्रश्न यह कहना है:

हाल ही में जीएनयू सिस्टम पर, इस क्रम में चर का उपयोग किया जाता है। यदि LANGUAGE सेट है, तो LANGUAGE को अनदेखा करने की स्थिति में, जब तक LANG C पर सेट नहीं हो जाता है, तब तक उसका उपयोग करें। इसके अलावा, कुछ कार्यक्रम केवल भाषा का उपयोग नहीं करते हैं। अन्यथा, यदि LC_ALL सेट है, तो इसका उपयोग करें। अन्यथा, यदि इस उपयोग को कवर करने वाला विशिष्ट LC_ * वैरिएबल सेट है, तो इसका उपयोग करें। (उदाहरण के लिए, LC_MESSAGES त्रुटि संदेश शामिल करता है।) अन्यथा, LANG का उपयोग करें।

तो ऑपरेशन और प्रलेखन दोनों में स्पष्ट समस्या, सभी स्थानीय ड्राइविंग चर के कुल योग को देखकर बताई जा सकती है।

Comments

यदि कोई LC_variable मौजूद नहीं है और bash Cलोकेल के लिए प्रलेखित व्यवहार नहीं करता है , तो यह एक बग है।

— 14

@ बिशप: (1) टाइपो: MVCE MCVE होना चाहिए। (२) यदि आप चाहते हैं कि आपका उदाहरण पूरा हो, तो आपको जोड़ना चाहिए env | grep LANGया echo "$LANG"।

— जी-मैन ने

@ सामान्य रूप से आगे की जांच ने मुझे आश्वस्त किया कि इस लिनक्स सिस्टम पर प्रलेखन या संचालन में कोई बग नहीं है।

— बिशप

@ जी-मैन थैंक्स! मैं भूल गया LANG। उस संकेत के साथ, सभी को समझाया गया है।

— बिशप

पहले स्थानीयकरण के प्रयासों के लिए सन द्वारा 1988 के आसपास LANG को पेश किया गया था, इससे पहले कि उन्हें पता चला कि एक एकल चर पर्याप्त नहीं है। आज इसे फॉलबैक के रूप में उपयोग किया जाता है और LC_ALL को जबरन अधिलेखित के रूप में उपयोग किया जाता है।

— विद्वान

Answer 5

लोकेल बदल सकती है कि कौन से कैरेक्टर मैच कर रहे हैं [A-Z]। उपयोग

(LC_ALL=C; rm [A-Z]*)

प्रभाव को खत्म करने के लिए। (मैंने बदलाव को स्थानीय बनाने के लिए एक उपखंड का उपयोग किया)।

Comments

यह काम नहीं करता है, यह अभी भी सभी पत्रों से मेल खाता है

— विद्वानों का

यह काम नहीं करेगा क्योंकि आरएम निष्पादित होने से पहले ग्लोब किया गया था। export LC_ALL=Cपहले प्रयास करें ।

— congonglm

क्षमा करें, आप उस प्रश्न को गलत समझते हैं जो bash से संबंधित है और rm से नहीं।

— विद्वान

@ शालि: हां, मैं गलत था, आपको बयानों को अलग करना होगा। अद्यतन की जाँच करें।

— कोरोबा

Answer 6

जैसा कि पहले ही कहा जा चुका है, यह एक "कोलिटिंग ऑर्डर" मुद्दा है।

रेंज az में कुछ स्थानों पर ऊपरी केस अक्षर हो सकते हैं:

     aAbBcC[...]xXyYzZ
     |              |
from a      to      z

4.3 के बाद से सही समाधान विकल्प सेट करना है globasciiranges:

shopt -s globasciiranges

बाश अधिनियम बनाने के लिए मानो ग्लोब आईएनजी रेंज LC_COLLATE=Cमें सेट किया गया है।

Answer 7

ऐसा लगता है कि मुझे अपने ही सवाल का सही जवाब मिल गया:

बैश छोटी गाड़ी है क्योंकि यह प्रबंधन नहीं करता है यह खुद का स्थान है। तो एक bash प्रक्रिया में LC_ * सेट करना उस शेल प्रक्रिया में प्रभाव के बिना है।

यदि आप LC_COLLATE = C सेट करते हैं और फिर एक और बैश शुरू करते हैं, तो ग्लोबिंग नई बैश प्रक्रिया में अपेक्षित रूप से काम करता है।

Comments

मेरी किसी कमी में नहीं।

— अराजकता

मैं अपनी मशीन पर बैश के किसी भी संस्करण में इसे नहीं दोहराता, ऐसा लगता है जैसे आपने exportइसे ठीक से नहीं किया ।

— क्रिस डाउन

तो आप मानते हैं कि कुछ ऐसा है जो सही तरीके से निर्यात किया जाता है, जिससे यह प्रभावित होता है कि एक नई बैश प्रक्रिया ठीक से निर्यात नहीं की जाती है?

— 18

सोलारिस के पर्यावरण को संभालने की बहुत कमी है, इसलिए मुझे आश्चर्य नहीं होगा कि अगर "बग" को कोसने में सोलारिस-विशिष्ट वर्कअराउंड की कमी थी।

— हॉब्स

@ शिल्पी: क्या आपके पास एक प्रशस्ति पत्र है जहां एक शेल के भीतर LC_ * वेरिएबल्स को बदलना अपने स्वयं के स्थानीय स्थिति को अपडेट करने के लिए आवश्यक है? मैं इसके बिल्कुल विपरीत सोचूंगा। किसी स्क्रिप्ट को निष्पादित करने के लिए विशेष रूप से, स्क्रिप्ट के पार्सिंग / निष्पादन के माध्यम से लोकल मिड-वे को बदलना भी अच्छी तरह से परिभाषित व्यवहार नहीं होगा, क्योंकि स्क्रिप्ट एक पाठ फ़ाइल है और "टेक्स्ट फ़ाइल" केवल एक संदर्भ के संदर्भ में सार्थक है एकल चरित्र एन्कोडिंग।

— आर ..