Why ls output does not sort in alphabet order
在 VPS（系统为 Ubuntu 11.04）ls 总感觉列出的内容很乱，仔细一看原来是列出的内容没有正常排序：
~/ws/home $ ls -1
404.md
blog
CNAME
_config.yml
css
images
_includes
index.html
js
_layouts
_posts
pub
README.md
robots.txt
_site
ASC 码表里大写字母是在小写字母前面的，CNAME 应该排在 blog
前面，还有那些下划线开头的没有挨着明显不对。
尝试用 sort，居然得到一样的结果，难道 sort 也出问题了？这可是天天用的命令啊。。
~/ws/home $ ls | sort
404.md
blog
CNAME
_config.yml
css
images
_includes
index.html
js
_layouts
_posts
pub
README.md
robots.txt
_site
不信邪，换一个 RHEL 5.4 发现又是正常的。一时间没有头绪，感觉自己像一个白痴正在被愚弄。。
仔细研读了一会 ls 和 sort 的 man page，终于发现线索，在 sort(1) 中有这么一段：
_ WARNING _ The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values.
我系统的 locale 是 en_US.utf8，接下去 google 一番终于在万能的 StackOverflow 找到了权威解答：
Sort does not sort in normal order!
问题知道了，修正我的 .bashrc 解决问题：
export LC_COLLATE=C
ls 的输出终于正常了：
~/ws/home $ ls -1
404.md
CNAME
README.md
_config.yml
_includes/
_layouts/
_posts/
_site/
blog/
css/
images/
index.html
js/
pub/
robots.txt
Made a small contribution to ubuntu
Just before leaving work on Friday, I encountered a bizarre issue:
gnome-session suddenly failed to start, and the log files provided no root
cause. Today, working from home, I decided to debug it thoroughly.
The setup process was quite tedious: first, connecting to the corporate network
via VPN, then logging into the corporate machine via SecureCRT, and installing
x11vnc. Since running X applications remotely requires a local X Server, I
booted up Ubuntu in VMware, started X, and used ssh -X to enable X11
Forwarding. However, x11vnc still refused to start because the user hadn’t
logged in yet, which required configuring gdm for automatic login. I
discovered that editing /etc/gdm/gdm.conf-custom directly was the easiest
approach, adding the following snippet:
[daemon]
AutomaticLoginEnable=true
AutomaticLogin=username
#TimedLoginEnable=true
#TimedLoginDelay=10
#TimedLogin=username
After restarting gdm and continually monitoring with the w command, I
confirmed the user was logging in automatically. The script executing was
/etc/gdm/Xsession, which would immediately fail and trigger an error dialog
instead of properly reaching /usr/bin/gnome-session. I opened
/etc/gdm/Xsession, added the -x parameter to the #!/bin/sh shebang, and
redirected the execution trace by prepending:
exec 1>/tmp/x.log 2>&1
Restarting gdm again and inspecting /tmp/x.log revealed the culprit:
++ '[' '!' -d /etc/X11/Xsession.d ']'
+++ /bin/ls -F --color /etc/X11/Xsession.d
++ for F in '$(ls $1)'
++ expr '^[[0m^[[0m20xorg-common_process-args^[[0m' : '[[:alnum:]_-]\+$'
++ for F in '$(ls $1)'
++ expr '^[[0m30xorg-common_xresources^[[0m' : '[[:alnum:]_-]\+$'
...
The moment I saw those ^[[0m control characters, everything made sense. The
ls command had been aliased to /bin/ls -F --color, and the terminal color
codes were breaking the script logic. It’s surprising to see such a fundamental
oversight in a core system script! The initialization script reads from
/etc/profile and $HOME/.profile, and if either sets this --color alias,
the session launch fails. In my case, it was globally set in /etc/profile.
The fix was trivially simple: update the script to use the absolute path
/bin/ls instead of relying on the environment’s ls.
Given the headache this caused, I decided to report it to the Ubuntu bug tracker. I found that others had encountered and reported it, but hadn’t pinpointed the exact root cause, so I gladly added my findings to the ticket.
- Bug #48876: gnome-session fails when “alias ls=‘ls –color’” in .profile
Update:
Shortly after reporting this, Canonical (the company behind Ubuntu) actually mailed me 5 physical Live CDs as a thank you! Back in those early days, receiving a package of physical installation CDs all the way from across the world was an incredible feeling. It perfectly captured the pure joy and tight-knit community spirit of contributing to the early open-source movement—knowing that a few hours of debugging on a weekend could positively impact thousands of users globally.