On 2007-08-07 18:58:02 +0200, Daniel Caillibaud wrote:
Vincent Lefevre a écrit :
On 2007-08-07 17:13:01 +0200, Daniel Caillibaud wrote:
while read f; do #commandes#; done<fichier et for f in `cat fichier`; do #commandes#; done;
Comme je l'ai dit, il peut y avoir un problème quand le processus n'a pas un stdin attaché au terminal (ce qui se produit avec la première ligne). Par exemple:
Mais pourquoi le for "propage" le stdin vers les commandes de la boucle et pas le while ?
Le while le propage[*] aussi, mais le stdin du while, c'est le fichier "fichier", pas le stdin par défaut (i.e. le terminal) comme dans le for. D'où les deux solutions que j'ai proposées: 1. Redonner le stdin initial à l'éditeur. 2. Ne pas utiliser le descripteur de fichier 0 (stdin) pour transmettre les données au read. Normalement, le descripteur 3 est inutilisé. Donc je fais globalement passer les données dedans et je redirige vers le stdin de read. Note: si ça se trouve dans le script, le stdin pourrait aussi être redirigé lors de l'appel du script. Fournir le tty à l'éditeur est probablement la meilleure solution. [*] En fait, lors du fork, le descripteur de fichier réfère le même fichier, ce n'est pas vraiment une propagation.
Essaie plutôt un truc du style:
while read f; do emacs -nw $f < $TTY; done < file
$ while read f; do joe $f <$TTY ; done <fichiers.list -bash: $TTY: ambiguous redirect -bash: $TTY: ambiguous redirect ..
Ah, TTY est propre à zsh. Mais ceci devrait fonctionner partout: while read f; do joe $f < `tty` ; done <fichiers.list si ça tourne bien dans un terminal. Mais il vaut probablement mieux tester, et pendant qu'on y est, mettre des quotes: tty="`tty`" || tty=/dev/null while read f; do joe "$f" < "$tty" ; done <fichiers.list -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)