si je veux afficher "aaa" à l'écran:
(1)$: echo aaa | cat ... works OK
(2)$: echo aaa | ( cat ) ... works OK
(3)$: echo aaa | ( cat & ) ... NOT working
(4)$: ( echo aaa & ) | cat ... works OK
(5)$: echo aaa | ( cat <&0 & ) ... works ok in BASH (but not in SH)
(6)$: echo aaa | ( cat <&3 & ) 3<&0 ... works ok in BASH and SH
Conlusion de (3) et (4) -> le processus détaché a toujours une sortie connectée qui peut être contrôlée, utilisée, redirigée ..., mais pas d'entrée!
Ma question est: quelqu'un comprend-il pourquoi et comment fonctionne la ligne (5) ???
... "<& 0" est l'abréviation de "0 <& 0", pourquoi rediriger 0 vers 0 est une solution, et ce qui se passe vraiment derrière avec l'entrée du processus détaché. Les sous-coquilles ne sont pas le problème, l'utilisation d'accolades {...} au lieu de (...) donne les mêmes résultats.
... et question2: existe-t-il une meilleure solution pour "donner une entrée au processus détaché" que la ligne (6).
la source
bash
interprète (et cela semble être une interprétation raisonnable) comme annulant la/dev/null
redirection. Maintenant, peu d'obus font la même chose. Ash et pdksh ne le font pas.3<&-
pièce nécessaire et est-il sûr de l'utiliser (ne fermera-t-il pas le tuyau avant la lecture complète de l'ir)?cmd
n'en a pas besoin. Nous le fermons après l'avoir doublé sur fd 0 (<&3
abréviation de0<&3
).nohup
redirige également stdin vers / dev / null, vous aurez besoin:{ nohup sh -c 'cmd <&3 3<&-' & } 3<&0
. Ou(trap '' HUP; cmd <&3 3<&- > nohup.out 2>&1 &) 3<&0