为什么某些命令无法使用BASH进程替换？

有时，流程替换将无法按预期进行。这是一个例子：

输入：

gcc <(echo 'int main(){return 0;}')

输出：

/dev/fd/63: file not recognized: Illegal seek
collect2: error: ld returned 1 exit status

输入：

但是，当与其他命令一起使用时，它可以按预期工作：

grep main <(echo 'int main(){return 0;}')

输出：

int main(){return 0;}

我注意到其他命令也发生了类似的故障（即，期望来自进程替换的文件的命令无法使用/dev/fd/63或类似）。这次故障gcc只是最近一次。我是否应该确定一些通用规则来确定何时进程替换将以这种方式失败并且不应该使用？

我正在Ubuntu 12.04上使用此BASH版本（我也在arch和debian中也看到过）：
GNU bash，版本4.3.11（1）-release（i686-pc-linux-gnu）

进程替换会生成一个特殊的文件（如/dev/fd/63您的示例中所示），其行为类似于命名管道的读取端。可以打开和读取此文件，但不能写入，查找。

将其参数视为纯流的命令将起作用，而希望在给定文件（或写入它们）中查找的命令将不起作用。那种命令，将工作就是通常被认为是一个过滤器：cat，grep，sed，gzip，awk，等...这是行不通就像是一个编辑器命令的例子vi或类似的文件操作mv。

gcc希望能够对其输入文件执行随机访问以检测它们所使用的语言。如果您gcc提示输入文件的语言，则很高兴流式处理该文件：

gcc -x c <(echo 'int main(){return 0;}')

没有流程替代的更简单，更直接的形式也可以使用：

echo 'int main(){return 0;}' | gcc -x c -

请注意，这并非特定于bash。所有支持进程替换的外壳的行为都相同。