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/63
ou similaire). Cet échec avec gcc
n'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 C
explicitement la langue ).
illegal seek
ressemble à la réponse - celui|pipe
quibash
pointe le programme exécuté n'est pas un fichier recherché. probablement si vous ne pouvez pas réussirecho data | command /dev/fd/0
un 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.