问 ：关于 [a-z] 的问题

woodie

梦兄，你可以试试用ls -U取消排序，那LC_COLLATE的值就没有影响了。

awk就是awp加ak

这么复杂啊，还不如就用正则，懒得想那么多了

一梦如是

1. LC_COLLATE=C ls *

复制代码

其实确实被解释成了

1. LC_COLLATE=C ls a A b B c C

复制代码

大家直接执行下上面这句，会发现输出为

1. A B C a b c

复制代码

可见，只是LC_COLLATE=C影响了ls的行为，并非影响了*的扩展

r2007

楼上讲的有理

ivanleung

我在unixware上试过是可以的，LANG=C。

ailms

又发现有点不对劲了。

1. 
   
2. [root@home test]# ksh
   
3. 
   
4. # locale
   
5. LANG=zh_CN.GB18030
   
6. LC_CTYPE="zh_CN.GB18030"
   
7. LC_NUMERIC="zh_CN.GB18030"
   
8. LC_TIME="zh_CN.GB18030"
   
9. LC_COLLATE="zh_CN.GB18030"
   
10. LC_MONETARY="zh_CN.GB18030"
    
11. LC_MESSAGES="zh_CN.GB18030"
    
12. LC_PAPER="zh_CN.GB18030"
    
13. LC_NAME="zh_CN.GB18030"
    
14. LC_ADDRESS="zh_CN.GB18030"
    
15. LC_TELEPHONE="zh_CN.GB18030"
    
16. LC_MEASUREMENT="zh_CN.GB18030"
    
17. LC_IDENTIFICATION="zh_CN.GB18030"
    
18. LC_ALL=
    
19. 
    
20. # ls [a-z]*
    
21. a12
    
22. 
    
23. # ls
    
24. 123  A  a12
    
25. #
    

复制代码

如果按照 bash 的manual 所说的，和当前 locale 的 LC_COLLATE 和字符集有关，

那么为什么上面的 ksh 又可以呢？

locale 输出的结果还是和 bash 的一样啊

一梦如是

因为ksh没有采用这种机制 ^__^
我们看到的是bash的手册页，不是ksh的，不是么？

woodie

原帖由 一梦如是 于 2006-12-15 13:04 发表

1. LC_COLLATE=C ls *

复制代码

其实确实被解释成了

1. LC_COLLATE=C ls a A b B c C

复制代码

大家直接执行下上面这句，会发现输出为

1. A B C a b c

复制代码

可见，只是LC_COLLATE=C影响了ls的行为，并非影响了*的扩展

梦兄这句容易产生误解，我再强调一下：准确地说是在
LC_COLLATE=C ls
这样的命令中才能这样讲。
可以肯定地说：环境变量LC_COLLATE的值是一定会影响字符排序的顺序的，进而也会对
[a-z]
这样统配符的扩展结果产生影响。如17楼用了export LC_COLLATE=C的例子。关于如何如何影响[a-z]这样的的扩展在BASH FAQ的E9中讲的很清楚。
只是在LC_COLLATE=C ls这种特定的场合下，LC_COLLATE=C的赋值生效是在统配符扩展之后，还来不及对之前已经完成的统配符扩展这一步操作产生影响罢了。

[ 本帖最后由 woodie 于 2006-12-15 14:55 编辑 ]

r2007

就是说不是不能影响shell扩展，而是没有来得及。
精彩的讨论，又有收获了。

網中人

是的，所以很多要處理文字的程式，為了避免語系的差異，會先行定義 LANG
如 LANG=C proman parameters.....