200k个PDF文件目录打包：Process Substitution与Command Substitution两种tar方案选型对比

先直接给你拍板：用tar -cf out.tar -T <(compgen -G '*.pdf')这个方案，命令替换的路子在200k个文件的场景下根本走不通。

为什么命令替换方案会翻车？ #

你担心的命令行长度限制真的是硬伤。系统对单个命令能接收的参数总长度有严格限制（可以用getconf ARG_MAX查看你系统的具体值，一般也就几MB）。200k个PDF文件名加起来的总长度，大概率会远远超过这个阈值，执行tar -cf out.tar compgen -G '*.pdf'``的时候，直接就会抛出Argument list too long的错误，根本没法完成打包。

进程替换方案好在哪里？ #

这个方案巧妙绕开了命令行参数的限制：

• compgen -G '*.pdf'会输出所有PDF文件名的列表
• <(...)是进程替换，它会在后台创建一个临时的伪文件（或者说匿名管道），把compgen的输出内容放到这个伪文件里
• tar的-T参数是指定一个文件，让tar从这个文件里读取要打包的文件名列表

整个流程里，所有文件名并没有作为命令行参数传递，而是通过管道/伪文件的方式流式传给tar，不管你有200k还是更多文件，都不会触碰到参数长度的限制，完美适配你的场景。

额外小补充 #

其实你要是不想用compgen，也可以用find . -maxdepth 1 -name '*.pdf' -print0配合tar --null -T -，不过进程替换的写法已经足够简洁好用了。

内容的提问来源于stack exchange，提问作者Roland