Parfois, la substitution de processus ne fonctionnera pas comme prévu. Voici un exemple:
Contribution:
gcc <(echo 'int main(){return 0;}')
Sortie:
/dev/fd/63: file not recognized: Illegal seek
collect2: error: ld returned 1 exit status
Contribution:
Mais cela fonctionne comme prévu lorsqu'il est utilisé avec une commande différente:
grep main <(echo 'int main(){return 0;}')
Sortie:
int main(){return 0;}
J'ai remarqué des échecs similaires avec d'autres commandes (c'est-à-dire que la commande qui attend le fichier de la substitution de processus ne peut pas utiliser /dev/fd/63ou similaire). Cet échec avec gccn'est que le plus récent. Existe-t-il une règle générale que je devrais connaître pour déterminer quand la substitution de processus échouera de cette manière et ne devrait pas être utilisée?
J'utilise cette version BASH sur Ubuntu 12.04 (j'ai également vu cela dans arch et debian):
GNU bash, version 4.3.11 (1) -release (i686-pc-linux-gnu)
gcc -xc <(echo 'int main(){return 0;}')(qui définit Cexplicitement la langue ).
illegal seekressemble à la réponse - celui|pipequibashpointe le programme exécuté n'est pas un fichier recherché. probablement si vous ne pouvez pas réussirecho data | command /dev/fd/0un programme, vous aurez une chance similaire avec<(cmd). Il ne fournit pas de fichier sur disque - il remplace simplement un argument qui pointe vers un descripteur de fichier pipe.