系统与基础设施dwheeler.com
修复 Unix 文件名问题（2012）
Fixing Unix Filenames (2012)
2012 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
David A. Wheeler 的这篇经典文章指出 Unix/Linux 文件名几乎允许任意字节（除路径分隔符和 NUL 外），导致空格、换行、控制字符等文件名在 shell 脚本和各类工具中引发大量隐患，并提出限制文件名字符集的改进方案。文章多次登上 Hacker News 首页，引发了关于问题根源究竟在文件系统、shell 还是终端的长期争论。
为什么经久不衰：文件名处理是每个写脚本、做运维的人都踩过的坑，这篇文章系统梳理了问题并给出可行建议，至今仍是绕不开的参考资料。
HN 评论精选
问题根源主要在 shell 和终端，而非文件系统本身
这些问题一半出在 shell 而与文件系统无关。shell 在把文件名或环境变量中的空格展开成多个参数这件事上做得非常糟糕——文中每个“错误”示例其实都是行为不符合预期的 shell 脚本，错的主要是 shell！至于控制字符影响终端显示，那也主要是终端的错，责任分散在文件系统、终端和 shell 各处，不能全怪文件系统允许任意命名。Linus 那段“文件系统应让写得糟糕的代码也能正常工作”的引言其实对双方都适用：现实中确实存在创建含特殊字符文件名的应用。
ketralnis查看英文原文
Half of these problems are problems with the shell and have nothing to do with the filesystem. The shell is really, really, really bad about doing things like expanding spaces in filenames or environment variables into separate arguments. Notice that every example here about how it's "wrong" is a small shell script that has unexpected behaviour. That's mostly because the shell is wrong! > Oh, and don’t display filenames. Filenames could contain control characters that control the terminal (and X-windows), causing nasty side-effects on display That's the fault of the terminal, mostly. If it's an otherwise "reasonable" name containing, say, encoded unicode, that's everyone's fault from the filesystem to the terminal to (sometimes) the shell. But the fault is spread out over more than just the fact that the filesystem lets you name files however you like. But now, Linus' quote there: > "...filesystem people should aim to make "badly written" code "just work" unless people are really really unlucky. Because like it or not, that’s what 99% of all code is... Crying that it’s an application bug is like crying over the speed of light: you should deal with reality, not what you wish reality was." — Linus Torvalds, on a slightly different topic (but I like the sentiment) (http://lwn.net/Articles/326505/) speaks to both "sides" here: there are applications in the real world that create filenames with special characters in them. The simplest most obvious of these is the space, but yes, in the real world we have applications that do this. So neither alternate reality ("restrict filesystems' names" or "keep doing what we're doing but have bug-free applications") exists, so which "reality" are you proposing that we deal with here?
一线运维经验证明：宽松的文件名规则带来大量实际痛苦
如果文件名有更多限制，我的工作会轻松很多，光是禁掉换行符就能省去不少麻烦。我做运维时，团队项目目录里有一堆以 '-' 开头的文件夹，写脚本时都得小心处理。编辑们还常从 macOS Finder 粘贴含 Unicode 的文本到文件名里。最近有人粘贴了带换行的文本，简直是一场灾难；而且 BSD md5 和 GNU md5sum 对含控制字符的文件名处理方式不同，导致跨机器比对 md5 列表一直失败。常见的 bash 教程说“加双引号就行”，但通过 SSH 远程执行或拼 rsync 命令时照样会出问题。
deckiedan查看英文原文
My life would be a lot easier if there were some more restrictions on file-names, it's true. Just cutting out newlines would save me a lot of grief. At my work I'm doing a lot of sysop/devops/admin stuff for a media production team. The team-wide project file structure contains a whole bunch of folders starting with '-'. It's not a problem, you just have to write all scripts being aware of it. As we're making videos about different places around the world, it's not uncommon for editors to copy and paste things (including unicode weird other languages, etc) into filenames from OSX Finder. I got caught out recently when someone had pasted in some text with newlines. Boy can that ever run havok. The thing which got me was that BSD md5 on OSX and GNU md5sum on CentOS handle things differently (using \ before a filename with control characters in it on one of them). So creating a md5 list on one computer and comparing it against a list made on another computer was failing, even though the files where exactly the same. Also annoying is trying to write scripts which handle " and ' in names. The typical BASH tutorial response is, 'use "$VAR"! That always works!' Unless you are sending a command to run on a remote server, or putting together a rsync command that runs over SSH. Then, it breaks. So: PATH="Fred's New: \"Test\" Project!" rsync -ave "ssh -i ~/.ssh/key" --delete "$PATH/" "user@remote:$PATH" will have problems. (If I remember correctly). I think this one was fixed with something odd like using ' quotes, and then replacing all ' in the filenames with '\'' (which ends the current string, puts a single quote on its own as a string, and then starts the string again, but treats them all as one long string). 99% of my problems went away when I switched most scripts over to python. (And, yes, started adding more and more weirdo filenames into my /shell/ /script/ unit tests...)
从 GUI 工具包视角看，统一文件名编码（如强制 UTF-8）会大幅简化开发
这个提案很有意思。这类文件名对 GUI 工具包同样造成很多麻烦：Qt 4 移除了 QString 中处理畸形 Unicode 的 hack，导致“从系统读文件名直接转成 QString”不再通用，因为存在既非 ASCII 也非合法 UTF-8 的文件名。这实际上迫使 KDE 要求用户必须使用 UTF-8 文件名，否则文件管理器无法显示、也无法通过 DBus 传递。我真心期待能安全地假定文件名就是 UTF-8，最好由内核强制执行。
mpyne查看英文原文
Interesting proposal. It's interesting that such filenames cause a lot of problems for GUI toolkits as well. For example, Qt since Qt 4 removed the hacks they had in QString to allow malformed Unicode data in its QString constructor. What this means is that the old trick of just reading a filename from the OS and making a QString out of it is impossible in general since there are filenames which are not valid ASCII, Latin-1, or UTF-8. Qt does provide a way to convert from the "local 8-bit' filename-encoding to and from QString, but this depends on there being one, and only one, defined filename-encoding (unless the application wishes to roll its own conversion). This has effectively caused KDE to mandate users use UTF-8 for filenames if they want them to show up in the file manager, be able to be passed around on DBus interfaces, etc. Frankly I can't wait until we can safely rely on filenames being UTF-8 and UTF-8 only. Better still if that can be enforced by the kernel somehow.
机制与策略应分离：内核不该限制文件名，宽松机制留给未来
Unix 文件名提供的是一种机制，机制本身不需要改。策略可以因用户群体和工具而异，但通过限制机制来禁止坏的策略是错误的。实践中 shell 用户只需处理带空格的文件名，偶尔用 rm -- 删掉误建的文件；没人会用前导空格、转义码、换行符这种疯狂文件名，因为那自找麻烦，问题某种程度上自我消化了。而且未来的用户界面可能没有当前 shell 的转义和展开问题，届时能放任意字符反而有用。内核只需路径分隔符和 NUL 终止符，对其他不闻不问意味着更少可能出错的内核代码。
yason查看英文原文
The Unix filenames provide a mechanism. That doesn't need to be changed. The policy can be different, based on the userbase and the tools being used, but limiting the mechanism to disallow bad policies is wrong. While you can create a page-long listing of filename troubles, in practice these shell users only end up having to account for filenames with spaces in them. Occasionally you have to rm -- an accidentally created file. Nobody uses those crazy filenames with leading and trailing space, escape codes, and newline characters because it means trouble with the shell. So the problem kind of takes care of itself. But there might be some future user interface that doesn't have the escaping and expansion problems of current shells and with that it might be useful to be able to put nearly any character into filenames. The Linux/Unix kernel isn't in the position to dictate how the filenames shall be used. It only needs the path separator and NUL terminator and not caring about anything else means less kernel code that can break.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选