Почему подстановка процесса 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только самый последний. Есть ли какое-то общее правило, о котором я должен знать, чтобы определить, когда подстановка процесса потерпит неудачу и не должна использоваться?

Я использую эту версию BASH в Ubuntu 12.04 (я также видел это в arch и debian):
GNU bash, версия 4.3.11 (1) -релиз (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. Все оболочки, поддерживающие процесс замены, ведут себя одинаково.