bash, return de la boucle redirigée, est-ce sûr?

Notez que nous revenons d'une boucle, qui est redirigée.

Je ne sais pas, si je devais m'inquiéter du tampon d'écriture de "file".

function f { i=1 while : do echo aaaaaaaaaaaaabbbbbbbbbbbbbbbbb ((i++)) if [ $i -gt 3 ] then return # return while redirected fi done >> file # writing to file } f

Remarque: je suis conscient que cette fonction pourrait être facilement réécrite, de sorte que ne serait pas renvoyée à partir de la boucle redirigée. Cependant, ceci n'est qu'un exemple simplifié pour cette question.

Alors s'il vous plaît, n'essayez pas d'améliorer ce code.

Je ne suis pas intéressé par les solutions de contournement, non plus.

Ma seule question est de savoir s'il y a quelque chose dont je devrais être particulièrement conscient. Comme le descripteur de file n'est pas fermé correctement. Ou parfois, je ne peux attendre que la moitié du tampon (ie "aaaaaa") à écrire dans le file.

J'aimerais savoir, si c'est une très mauvaise idée, et pourquoi? Ou peut-être que cela fonctionnerait sans conditions de course imprévues ou similaires? (mais encore une fois, je ne veux pas de réponses comme «c'est mauvais parce que vous devriez plutôt utiliser ce model»)

Alors que chaque command peut avoir son propre tampon d'écriture, il n'y a pas de tampon d'écriture partagé entre les commands même embeddedes dans bash (ou même deux invocations d'une même command, embeddede ou non).

Même ksh93 qui a été connu pour faire de l'optimization d'E / S (par exemple, il va lire en avant et partager certaines données sur l' input ( causant des bugs )), ne le fait pas.

Donc, ce sera sûr à cet égard. Une fois la command terminée, comme votre echo aaaaaaaaaaaaabbbbbbbbbbbbbbbbb , et à condition qu'elle n'accède pas à un process sans assistance s'exécutant en arrière-plan, vous pouvez être assuré que toutes les E / S ont été effectuées.

Quelques notes cependant. Dans une fonction comme:

 f() { { echo x return echo y } > file echo something else }

Dans le shell Bourne (et le shell Bourne uniquement), ce return interromprait la sortie du groupe de commands interne, mais ne reviendrait pas de la fonction comme dans cet ancien shell, ce groupe de commands s'exécuterait dans un sous-shell en raison de la redirection 'd voir le something else ).

Cela ne se produit plus dans les coquilles modernes comme bash , mais vous auriez le même problème dans bash si vous avez écrit:

 f() { ( echo x return echo y ) > file echo something else }

 f() { { echo x return echo y } | tr xy ab echo something else }

Attention, il y a des cas où certaines commands ne sont pas attendues. Dans:

 f() { { echo >(sleep 1; echo x) return } > file } f; cat file

Vous pouvez constater que x ne s'affiche pas car le cat est exécuté avant echo x .

Certains obus (mais pas bash ) ont des problèmes potentiels similaires avec des composants de pipeline autres que le plus à droite.