Bonjour à tous, Après une abscence relativement longue me revoilà encore une fois . Aujourd'hui, je m'adresse à vous pour un problème que je n'arrive pas à résoudre et qui m'a empêché de dormir la nuit dernière. Sur la ligne de commande dans un terminal, j'execute: i=0; infostr=(); while read line; do infostr[i++]="$line"; echo "$line"; done < <(cddb.pl -I cddb query $(cd-discid /dev/cdrom)); echo "${infostr[0]}" Celà m'affiche 16 lignes contenant des informations sur mon cd audio, dont notemment les titres (les chansons) category: misc cddbid: bd0c0f10 trackno: 16 track 1: Les Flamands track 2: La Valse A Milie Temps track 3: Jacky track 4: La Chanson Des Vieux Amants track 5: Ne Me Quitte Pas etc ... track 16: Le Moribond Le problème apparaît à partir du moment ou je mets ce code dans un script bash que j'appelle cdripper.sh, j'ai alors cette erreur: cdripper.sh: line 56: syntax error near unexpected token `<' cdripper.sh: line 56: ` while read line; do infostr[i++]="$line"; echo "$line"; done < <(cddb.pl -I cddb query $(cd-discid /dev/cdrom)); echo "${infostr[0]}"' J'utilise GNU bash, version 3.2.25(1)-release (x86_64-unknown-linux-gnu) Le but est de mettre chaque ligne retourné par cddb.pl -I cddb query $(cd-discid /dev/cdrom) dans un élément du tableau infostr en dehors de la boucle (après la boucle) (encodage ogg avec des tags). Bien entendu, il y a des logiciels super beaux et super facils pour faire cette tâche, mais comme vous l'aurez compris, ce n'est pas mon but. Je vous remercie d'avoir été patient et de m'avoir lu jusqu'à la fin pour une question de bash . en fait j'ai lu la definition que vous donnez au bash dans le wiki :) Al Bayrouni
On 2007-12-16 12:19:18 +0100, bayrouni wrote:
Le problème apparaît à partir du moment ou je mets ce code dans un script bash que j'appelle cdripper.sh, j'ai alors cette erreur: cdripper.sh: line 56: syntax error near unexpected token `<' cdripper.sh: line 56: ` while read line; do infostr[i++]="$line"; echo "$line"; done < <(cddb.pl -I cddb query $(cd-discid /dev/cdrom)); echo "${infostr[0]}"'
J'utilise GNU bash, version 3.2.25(1)-release (x86_64-unknown-linux-gnu)
Tu peux toujours esssayer avec zsh. Mais si tu connais Perl, c'est probablement mieux de faire tout en Perl. -- 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)
Vincent Lefevre wrote:
On 2007-12-16 12:19:18 +0100, bayrouni wrote:
Le problème apparaît à partir du moment ou je mets ce code dans un script bash que j'appelle cdripper.sh, j'ai alors cette erreur: cdripper.sh: line 56: syntax error near unexpected token `<' cdripper.sh: line 56: ` while read line; do infostr[i++]="$line"; echo "$line"; done < <(cddb.pl -I cddb query $(cd-discid /dev/cdrom)); echo "${infostr[0]}"'
J'utilise GNU bash, version 3.2.25(1)-release (x86_64-unknown-linux-gnu)
Tu peux toujours esssayer avec zsh. Mais si tu connais Perl, c'est probablement mieux de faire tout en Perl.
En effet, Il faudra bien qu'un jour je prennes la décision d'apprendre perl sérieusement et/ou zsh! Merci Vincent.
bayrouni a écrit :
Sur la ligne de commande dans un terminal, j'execute: i=0; infostr=(); while read line; do infostr[i++]="$line"; echo "$line"; done < <(cddb.pl -I cddb query $(cd-discid /dev/cdrom)); echo "${infostr[0]}" Celà m'affiche 16 lignes contenant des informations sur mon cd audio, dont notemment les titres (les chansons)
category: misc cddbid: bd0c0f10 trackno: 16 track 1: Les Flamands track 2: La Valse A Milie Temps track 3: Jacky track 4: La Chanson Des Vieux Amants track 5: Ne Me Quitte Pas etc ... track 16: Le Moribond
Le problème apparaît à partir du moment ou je mets ce code dans un script bash que j'appelle cdripper.sh, j'ai alors cette erreur: cdripper.sh: line 56: syntax error near unexpected token `<' cdripper.sh: line 56: ` while read line; do infostr[i++]="$line"; echo "$line"; done < <(cddb.pl -I cddb query $(cd-discid /dev/cdrom)); echo "${infostr[0]}"'
Drôle de syntaxe... j'avais jamais rencontré <(commande) auparavant. D'ailleurs on dirait bien que c'est ça qui ne lui plait pas ! ;) À ma connaissance, < et > ne fonctionnent que pour les fichiers en bash. Si tu veux récupérer la sortie d'une commande dans un while, utilise un pipe : commande | while read line; do code done
J'utilise GNU bash, version 3.2.25(1)-release (x86_64-unknown-linux-gnu)
Le but est de mettre chaque ligne retourné par cddb.pl -I cddb query $(cd-discid /dev/cdrom) dans un élément du tableau infostr en dehors de la boucle (après la boucle) (encodage ogg avec des tags).
Bien entendu, il y a des logiciels super beaux et super facils pour faire cette tâche, mais comme vous l'aurez compris, ce n'est pas mon but.
Je vous remercie d'avoir été patient et de m'avoir lu jusqu'à la fin pour une question de bash . en fait j'ai lu la definition que vous donnez au bash dans le wiki :)
Celle là : http://cli.asyd.net/home/shell/bash ? Non parce que si il y en a une autre, en tant que vieil irréductible du bash refusant de passer à zsh pour des tas de raisons (et même quelques bonnes dans le tas, sisi), ça m'intéresse ;) -- Clément Hermann (nodens)
On 2007-12-17 00:18:03 +0100, Clément Hermann wrote:
Drôle de syntaxe... j'avais jamais rencontré <(commande) auparavant.
C'est une extension (process substitution) présente dans bash et dans zsh. -- 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)
Vincent Lefevre a écrit :
On 2007-12-17 00:18:03 +0100, Clément Hermann wrote:
Drôle de syntaxe... j'avais jamais rencontré <(commande) auparavant.
C'est une extension (process substitution) présente dans bash et dans zsh.
Comme quoi on en apprend tous les jours ;) Quelle est la différence avec l'utilisation d'un pipe, en pratique ? J'ai bien lu dans le man que ça utilisait un fifo, et que la substitution de processus est effectuée simultanément au développement des paramètres et variables, la substitution de commande et le developpement arithmétique (du moins sur les systèmes qui le permettent), mais ça ne dit pas vraiment ce que ça change par rapport à un pipe en pratique. Dans quel cas est-ce plus pertinent qu'un bête pipe ? -- Clément
On 2007-12-17 10:51:30 +0100, Clement Hermann wrote:
Quelle est la différence avec l'utilisation d'un pipe, en pratique ?
C'est utile quand on ne fait pas une redirection. Par exemple, j'utilise le script suivant: ------------------------------------------------------------------ #!/usr/bin/env zsh # Diffs two PDF files using pdftotext. emulate -LR zsh if [[ $# -lt 2 ]] then echo "Usage: pdfdiff [diff_options] file1.pdf file2.pdf" >&2 return 1 fi tdiff <(pdftotext "$@[-2]" -) <(pdftotext "$@[-1]" -) ------------------------------------------------------------------ tdiff est simplement un wrapper à diff; il est disponible ici: http://www.vinc17.org/unix/#tdiff Même avec des redirections, c'est utile en zsh avec les multios (man zshmisc, section MULTIOS). Dans la section Process Substitution, zsh donne l'exemple suivant: paste <(cut -f1 file1) <(cut -f3 file2) | tee >(process1) >(process2) >/dev/null et avec les multios: paste <(cut -f1 file1) <(cut -f3 file2) > >(process1) > >(process2) -- 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)
Clement Hermann wrote:
Vincent Lefevre a écrit :
On 2007-12-17 00:18:03 +0100, Clément Hermann wrote:
Drôle de syntaxe... j'avais jamais rencontré <(commande) auparavant.
C'est une extension (process substitution) présente dans bash et dans zsh.
Comme quoi on en apprend tous les jours ;)
Quelle est la différence avec l'utilisation d'un pipe, en pratique ? J'ai bien lu dans le man que ça utilisait un fifo, et que la substitution de processus est effectuée simultanément au développement des paramètres et variables, la substitution de commande et le developpement arithmétique (du moins sur les systèmes qui le permettent), mais ça ne dit pas vraiment ce que ça change par rapport à un pipe en pratique.
Dans quel cas est-ce plus pertinent qu'un bête pipe ?
Sauf erreur de ma part (loin d'être un as du bash), c'est l'explication que j'ai donné dans le post précédent.
Clément Hermann wrote:
bayrouni a écrit :
Sur la ligne de commande dans un terminal, j'execute: i=0; infostr=(); while read line; do infostr[i++]="$line"; echo "$line"; done < <(cddb.pl -I cddb query $(cd-discid /dev/cdrom)); echo "${infostr[0]}" Celà m'affiche 16 lignes contenant des informations sur mon cd audio, dont notemment les titres (les chansons)
category: misc cddbid: bd0c0f10 trackno: 16 track 1: Les Flamands track 2: La Valse A Milie Temps track 3: Jacky track 4: La Chanson Des Vieux Amants track 5: Ne Me Quitte Pas etc ... track 16: Le Moribond
Le problème apparaît à partir du moment ou je mets ce code dans un script bash que j'appelle cdripper.sh, j'ai alors cette erreur: cdripper.sh: line 56: syntax error near unexpected token `<' cdripper.sh: line 56: ` while read line; do infostr[i++]="$line"; echo "$line"; done < <(cddb.pl -I cddb query $(cd-discid /dev/cdrom)); echo "${infostr[0]}"'
Drôle de syntaxe... j'avais jamais rencontré <(commande) auparavant. D'ailleurs on dirait bien que c'est ça qui ne lui plait pas ! ;)
À ma connaissance, < et > ne fonctionnent que pour les fichiers en bash. Si tu veux récupérer la sortie d'une commande dans un while, utilise un pipe :
commande | while read line; do code done
cette commande marche syntaxiquement correctement, mais en bash, il y a un subterfuge qui permet de récuperer les varibles dans la boucles en dehors de celle-ci. Parce que si j'ai bien compris, dans une boucle, bash crée un nouveau (sous)shell.
J'utilise GNU bash, version 3.2.25(1)-release (x86_64-unknown-linux-gnu)
Le but est de mettre chaque ligne retourné par cddb.pl -I cddb query $(cd-discid /dev/cdrom) dans un élément du tableau infostr en dehors de la boucle (après la boucle) (encodage ogg avec des tags).
Bien entendu, il y a des logiciels super beaux et super facils pour faire cette tâche, mais comme vous l'aurez compris, ce n'est pas mon but.
Je vous remercie d'avoir été patient et de m'avoir lu jusqu'à la fin pour une question de bash . en fait j'ai lu la definition que vous donnez au bash dans le wiki :)
Celle là : http://cli.asyd.net/home/shell/bash ?
Non parce que si il y en a une autre, en tant que vieil irréductible du bash refusant de passer à zsh pour des tas de raisons (et même quelques bonnes dans le tas, sisi), ça m'intéresse ;)
On 2007-12-18 13:01:35 +0100, bayrouni wrote:
Clément Hermann wrote:
commande | while read line; do code done
cette commande marche syntaxiquement correctement, mais en bash, il y a un subterfuge qui permet de récuperer les varibles dans la boucles en dehors de celle-ci. Parce que si j'ai bien compris, dans une boucle, bash crée un nouveau (sous)shell.
Oui, c'est obligatoire de créer un sous-shell quelque part. Mais noter que zsh est plus intellignet: il crée le sous-shell sur la partie gauche du pipe afin que le pipe soit OK pour récupérer la variable. Cf http://www.zsh.org/mla/users/2002/msg00750.html -- 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)
Clément Hermann wrote:
bayrouni a écrit :
en fait j'ai lu la definition que vous donnez au bash dans le wiki :)
Celle là : http://cli.asyd.net/home/shell/bash ?
Non parce que si il y en a une autre, en tant que vieil irréductible du bash refusant de passer à zsh pour des tas de raisons (et même quelques bonnes dans le tas, sisi), ça m'intéresse ;)
Non, celle-là: http://cli.asyd.net/home/shell/comparatif salutations
On Mon 17 December, Clément Hermann wrote:
Non parce que si il y en a une autre, en tant que vieil irréductible du bash refusant de passer à zsh pour des tas de raisons (et même quelques bonnes dans le tas, sisi), ça m'intéresse ;)
vas y raconte :) -- http://asyd.net/home/ - Home Page http://guses.org/home/ - French Speaking (Open)Solaris User Group
Bruno Bonfils a écrit :
On Mon 17 December, Clément Hermann wrote:
Non parce que si il y en a une autre, en tant que vieil irréductible du bash refusant de passer à zsh pour des tas de raisons (et même quelques bonnes dans le tas, sisi), ça m'intéresse ;)
vas y raconte :)
Alors, il était une fois... - l'habitude : c'est pas forcément la meilleure raison, mais bon, je suis habitué à mon bon vieux bash que je retrouve partout. Si je m'habitue à zsh faudra que je l'installe partout ou que je change de shell selon la machine, bof... Je suis assez casanier en fait ;) - un sentiment très subjectif et peut-être erroné de plus de performance (au lancement notamment, même avec la completion activée, surtout sur mon zaurus, où zsh met plus de 10 secondes à se lancer, contre pas plus de 3/4 sur bash, terminal compris évidemment). - la completion est prévue pour pleins de paquets debian, quand j'avais voulu tester zsh (il y a quelques temps dejà) je m'étais aperçu que beaucoup moins de trucs étaient prévus au départ. Bon, d'accord, c'est plus facile de faire des règles de completion contextuelle avec zsh qu'avec bash. Mais je suis flemmard ;) - aucun défaut de bash ne m'a paru assez gênant pour que je prenne la peine de changer. - aucun feature de zsh ne m'a suffisamment attiré pour que je prenne la peine de changer. voilà voilà... Mais après je pourrais changer d'avis facilement, si un killer feature m'apparait subitement dans zsh. A+ -- Clément Hermann (nodens)
On 2007-12-19 10:05:57 +0100, Clement Hermann wrote:
- l'habitude : c'est pas forcément la meilleure raison, mais bon, je suis habitué à mon bon vieux bash que je retrouve partout. Si je m'habitue à zsh faudra que je l'installe partout ou que je change de shell selon la machine, bof... Je suis assez casanier en fait ;)
zsh est souvent installé, sinon c'est la première chose que je fais, et c'est vite rentabilité.
- un sentiment très subjectif et peut-être erroné de plus de performance (au lancement notamment, même avec la completion activée, surtout sur mon zaurus, où zsh met plus de 10 secondes à se lancer, contre pas plus de 3/4 sur bash, terminal compris évidemment).
Sur mon zaurus, "zsh -f" met moins d'une seconde à se lancer.
- la completion est prévue pour pleins de paquets debian, quand j'avais voulu tester zsh (il y a quelques temps dejà) je m'étais aperçu que beaucoup moins de trucs étaient prévus au départ. Bon, d'accord, c'est plus facile de faire des règles de completion contextuelle avec zsh qu'avec bash. Mais je suis flemmard ;)
Je trouve que quasiment tout est prévu, et quand la complétion existe, elle est plus complète que sous bash. J'ai bien surtout l'aide, e.g.: vin:~> cp -[TAB] Completing option --archive -a -- same as -dpR --backup -- specify: method --copy-contents -- copy contents of special files when recur --dereference -L -- always follow symbolic links --force -f -- remove and retry for destinations that ca --link -l -- link files instead of copying --no-preserve -- specify: attributes not to preserve --one-file-system -x -- stay on this file system --parents -- append source path to target directory --preserve -- specify: attributes to preserve --recursive -r -R -- copy directories recursively --remove-destination -- remove each existing destination file bef --reply -- specify: how to handle the prompt about a --sparse -- specify: when to create sparse files --strip-trailing-slashes -- remove any trailing slashes from each sou --suffix -S -- specify: backup suffix --symbolic-link -s -- make symbolic links instead of copies of --target-directory -- specify: target directory --update -u -- copy only when source is newer than desti --verbose -v -- explain what is being done -H -- follow command-line symbolic links -P -- same as --no-dereference -b -- backup -d -- same as --no-dereference --preserve=link --help --version
- aucun feature de zsh ne m'a suffisamment attiré pour que je prenne la peine de changer.
Je trouve l'éditeur multi-ligne une raison suffisante, de même que le globbing récursif, le =command aussi est bien pratique. -- 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)
participants (5)
-
bayrouni -
Bruno Bonfils -
Clement Hermann -
Clément Hermann
-
Vincent Lefevre