Je me suis déjà +/- battu avec ce problème, et je n'ai pas de solution complètement satisfaisante. Je te mets ici une version verbosement commentée de ma solution la plus simple : http://tdegreni.free.fr/files/foobar.sh(...)
Le problème qui persiste est que stdout et stderr ne sont pas synchronisés, et que donc des messages rapidement enchainés sur chacune de ses sorties peuvent se retrouver entrelacés sur le terminal. En fait, je ne vois pas vraiment de solution à ce problème : la duplication des deux flux passe forcement par des processus concurrents (les deux 'tee'), qui sont bufferisés, et on n'a pas le contrôle de leur ordonnancement. Peux être qu'en C on pourrait faire un seul processus pour consommer et dupliquer les deux flux alternativement (et vu que côté producteur l'écriture sur des pipes est bloquante, on ne perdrait pas la synchro), bref on pourrait faire un genre de double-tee, mais en shell par contre je ne vois vraiment pas.
À part ça, tu verras que dans mon script je n'ai pas distingué shell interactif de shell non-interactif. Il me semble d'ailleurs que tout ce qui est mis dans un script est non-interactif, sauf à forcer ça avec un "#!/bin/bash -i". Je ne crois pas que ton test sur $PS1 fonctionne comme tu l'attends, parceque $PS1 n'est pas censé être exporter. Moi en général, quand je veux appeler qqch depuis un cron sans pourrir mon log, je ne compte pas sur le script lui même, mais je fais mon appel avec "&>/dev/null", et puis voilà.
Bon ceci dit, si tu tiens à tester ça au niveau du script, alors y'a peut être moyen plutôt avec $TERM, ou encore avec la commande 'tty', je sais pas trop... Je sais qu'en python par exemple, je ferais ça avec le prédicat "sys.stdout.isatty()", mais en bash, j'ai jamais essayer de trouver un équivalent. Si tu trouves, alors dans mon script ce sera facile de rajouter le test pour faire un appel récursif avec une redirection plus simple dans le cas non-interactif (genre '0ドル "${@}" 1>${STDOUT_LOG} 2>${STDERR_LOG}').
# pas évident
Posté par tgl . En réponse au message Redirection de scripts. Évalué à 2.
http://tdegreni.free.fr/files/foobar.sh(...)
Le problème qui persiste est que stdout et stderr ne sont pas synchronisés, et que donc des messages rapidement enchainés sur chacune de ses sorties peuvent se retrouver entrelacés sur le terminal. En fait, je ne vois pas vraiment de solution à ce problème : la duplication des deux flux passe forcement par des processus concurrents (les deux 'tee'), qui sont bufferisés, et on n'a pas le contrôle de leur ordonnancement. Peux être qu'en C on pourrait faire un seul processus pour consommer et dupliquer les deux flux alternativement (et vu que côté producteur l'écriture sur des pipes est bloquante, on ne perdrait pas la synchro), bref on pourrait faire un genre de double-tee, mais en shell par contre je ne vois vraiment pas.
À part ça, tu verras que dans mon script je n'ai pas distingué shell interactif de shell non-interactif. Il me semble d'ailleurs que tout ce qui est mis dans un script est non-interactif, sauf à forcer ça avec un "#!/bin/bash -i". Je ne crois pas que ton test sur $PS1 fonctionne comme tu l'attends, parceque $PS1 n'est pas censé être exporter. Moi en général, quand je veux appeler qqch depuis un cron sans pourrir mon log, je ne compte pas sur le script lui même, mais je fais mon appel avec "&>/dev/null", et puis voilà.
Bon ceci dit, si tu tiens à tester ça au niveau du script, alors y'a peut être moyen plutôt avec $TERM, ou encore avec la commande 'tty', je sais pas trop... Je sais qu'en python par exemple, je ferais ça avec le prédicat "sys.stdout.isatty()", mais en bash, j'ai jamais essayer de trouver un équivalent. Si tu trouves, alors dans mon script ce sera facile de rajouter le test pour faire un appel récursif avec une redirection plus simple dans le cas non-interactif (genre '0ドル "${@}" 1>${STDOUT_LOG} 2>${STDERR_LOG}').