[BASH] Priorité des métacharactere (Résolu)

[Wax-Reggea]

Salut tous le monde,

J'aurai besoin de la priorité des opérateur utilisable sur un bash (surtout ';', '|', '>', '<', '>>', '<<', '<>' et les redirections des output (1&2)). Je pensais trouver cela facilement sur le net mais impossible à trouver .
Si quelqu'un arrive à trouver une liste 100% fiable cela serait top ! J'ai beau essayer de la faire à la main en essayant sur mon shell, mais je trouve des cas bizarre et ça me prend la tête.
D'après moi, j'ai trouver ça, mais comme dis plus haut, j'en suis absolument pas sur:
1: ';'
2: '<'
3: '|' et '<<'
4: '>>'
5: '>'
Et les autres, je sais pas.

Merci d'avance !
Wax-Reggea.

[oktoberfest]

Ce genre de chose : http://tldp.org/LDP/abs/html/opprecedence.html ?
Demande à google : bash operators prority....

[Wax-Reggea]

J'avais déjà vue cette page mais les opérateurs listés ne sont pas ceux que je veux. Il me faudrait la même chose en plus complet mais j'ai pas trouvé.

[oktoberfest]

Tu voudrais un tableau qui te synthétise tous les opérateurs, sachant que tu mélanges :
- des opérateurs arithmétiques ( +, *, >)
- des opérateurs de séquencement d'opération ( &, ; , && )
- des opérateurs de redirection (>, >&, &>)
et d'autres.

Et en plus '>' (et ce n'est pas le seul) est un opérateur qui peut être :
- un opérateur arithmétique de comparaison
- un opérateur de redirection

Je pense qu'une liste exhaustive n'existe pas. Peut-être que si tu épluches soigneusement le bash tu arriveras à en faire une.

[Wax-Reggea]

Pour mon cas, les '>' et '<' sont des opérateurs de redirection seulement, mais je concoie qu'un tel classement n'existe pas dans une quelconque doc.
C'est possible de confirmer mon classement du coup ? Il me parait juste mais peut-être qu'un regard extérieure trouvera une absurdité.

[FoolEcho]

C'est possible de confirmer mon classement du coup ? Il me parait juste mais peut-être qu'un regard extérieure trouvera une absurdité.

Ben non, ça n'est pas possible car ça n'a absolument aucun sens (en tous cas, je ne comprends pas ce que tu attends).

Les opérateurs arithmétiques sont les seuls à avoir un ordre (ce qui rejoint le lien donnée par oktoberfest):
http://www.gnu.org/software/bash/manual ... Arithmetic

Pour les redirections et le reste, c'est séquentiel et l'ordre importe donc (cf. exemple du manuel).
http://www.gnu.org/software/bash/manual ... directions

[Wax-Reggea]

Il y a des priorités sur les redirections, par exemple si je fais : "ls > toto << salut", le bash va d'abord faire les '<<' (donc que je tape "salut") puis le '>'.
C'est ce genre de priorité qui m'intéresse.
Comme dit plus haut, dans mon cas, les '<' et '>' sont des opérateurs de redirections seulement.

[benjarobin]

Je ne vois aucune priorité... Il lit séquentiellement les commandes.

Code : Tout sélectionner

ls > toto << salut

est identique à

Code : Tout sélectionner

ls << salut > toto

[FoolEcho]

Il y a des priorités sur les redirections, par exemple si je fais : "ls > toto << salut", le bash va d'abord faire les '<<' (donc que je tape "salut") puis le '>'.
C'est ce genre de priorité qui m'intéresse.

Évidemment, si tu tapes dans ce genre de construction, on n'est pas sorti.

Je ne vois aucune priorité... Il lit séquentiellement les commandes.

Code : Tout sélectionner

ls > toto << salut

est identique à

Code : Tout sélectionner

ls << salut > toto

Absolument.
Pour développer...

http://www.gnu.org/software/bash/manual ... -Documents

Appelle ça une priorité si tu veux, mais ce n'est pas le cas: c'est juste que tu indiques au shell qu'il y a encore des choses à tenir compte avant d'exécuter la commande ; c'est pourquoi "toto" est vide si tu interrompts avec CTRL+C par exemple (avec <<, c'est comme de faire une phrase en s'interrompant à la moitié: bash attend que la phrase soit complète avant de l'interpréter).

Ton exemple n'est pas le meilleur pour comprendre ce qu'il se passe...

Je te laisse méditer sur... Mettons:

Code : Tout sélectionner

$ cat > toto << salut 
> Salut toto
> bye
> salut

$ cat toto
Salut toto
bye

Pour bash, c'est effectivement équivalent à écrire cat << salut > toto.

Autre exemple qui te parlera peut-être mieux (tiré de http://en.wikipedia.org/wiki/Here_document):

Code : Tout sélectionner

$ tr a-z A-Z << END_TEXT
> one two three
> uno dos tres
> END_TEXT
ONE TWO THREE
UNO DOS TRES

Le truc est que tr lit sur l'entrée standard par défaut, tu me suis ? Donc tr a-z A-Z attend des choses à analyser, d'accord ? Par conséquent, il ne va s'exécuter qu'après complétement du << ici.

Ainsi si tu veux on peut rajouter l'écriture dans un fichier:

Code : Tout sélectionner

$ tr a-z A-Z > toto << END_TEXT # tr a-z A-Z << END_TEXT > toto est plus clair à mon avis
> one two three
> uno dos tres
> END_TEXT

$ cat toto 
ONE TWO THREE
UNO DOS TRES

Là encore avant d'écrire dans le fichier, il faut que le tr soit complet et il le sera dans l'exemple via le << (sinon c'est la même chose que faire tr a-z A-Z > toto , toto n'est rempli qu'une fois fini sur l'entrée standard avec CTRL+D ; la seule différence par rapport à l'entrée standard tient au fait que toto n'est créé qu'après END_TEXT, mais c'est normal comme je te disais: bash attend d'avoir tout sous la main).

[Wax-Reggea]

Pourtant quand je tape "cat > toto << salut" et "cat << salut > toto" et je quitte avec Ctrl-C pendant le '<<', le fichier toto n'a pas était créer. C'est donc qu'il traite d'abord le '<<' puis un fois celui-ci fini, lance le cat puis met la sortie dans un fichier toto. Or sur c'est deux ligne, les opérateurs n'ont pas la même position l'un par rapport à l'autre.
Donc le bash ne traite pas les opérateurs dans l'ordre où ils sont rentrer. Comment fait-il alors ? Il y a bien un système de "priorité" (peut-etre pas le mot adapté) non ?

[FoolEcho]

Pourtant quand je tape "cat > toto << salut" et "cat << salut > toto" et je quitte avec Ctrl-C pendant le '<<', le fichier toto n'a pas était créer. C'est donc qu'il traite d'abord le '<<' puis un fois celui-ci fini, lance le cat puis met la sortie dans un fichier toto.

Pas compris.
Le comportement est le même dans les deux cas... mais oui, il cherche à traiter le << avant, mais si tu interrompts la commande à ce moment, il n'y a aucun fichier de créé justement.

[Wax-Reggea]

Ah oui, le comportement est le même, ça j'avais saisie mais justement pour qu'il soit identique, il va faire le '<<' avant le '>'.
Et justement je souhaite avoir cette ordre pour tous les opérateur. Par exemple, pour un '|' et un '>>' etc...
Désolé pour le qui-procos, c'est vrai que j'ai pas bien précisé sur mon post.

EDIT: Du coup, j'ai re-verifier mon ordre, il y avait des erreurs:
1: ';'
2: '<'
3: '<<'
4: '>' et '>>'
6: '|'

[benjarobin]

Il n'y a aucun ordre !!!
; ou > ou | sont totalement incompatible entre eux. C'est une syntaxe bien précise, mais dire qu'il y a un ordre est complètement faux.
Ce n'est pas une formule de math, c'est une syntaxe de programmation...

[Wax-Reggea]

Bien sur que si, il y un ordre dans lesquel le bash va faire les choses. Sinon, niveau processing comment ça ce passe ? Je crois que j'ai du mal à expliquer mon problème.
Quand tu rentre une commande dans un bash, celui-ci la decoupe selon un arbre binaire, où un noeud est soit un opérateur soit une commande, une fois créer, il parcours recursivement chaque noeud, et donc par exemple s'il trouve un '>' il va dup un fichier à la place de la sortie standard, s'il trouve un '<' il va dup un fichier à la place de l'entrée standard etc... Après, ma question est: Dans quel ordre découpe-t-il la commande ? Quels opérateurs doivent être plus haut dans l'ardre par rapport aux autres ?

[FoolEcho]

Quand tu rentre une commande dans un bash, celui-ci la decoupe selon un arbre binaire, où un noeud est soit un opérateur soit une commande, une fois créer, il parcours recursivement chaque noeud, et donc par exemple s'il trouve un '>' il va dup la sortie standard dans un fichier, s'il trouve un '<' il va dup un fichier à la place de l'entrée standard etc... Après, ma question est: Dans quel ordre découpe-t-il la commande ? Quels opérateurs doivent être plus haut dans l'ardre par rapport aux autres ?

Heu... Je ne connais pas l'analyse lexicale et syntaxique de bash, mais c'est nettement plus complexe que ça.
Mais c'est ce que disait benjarobin, comme quoi pipe, etc. sont incompatibles et ne s'analysent pas en terme de formule mathématique avec une quelconque priorité: c'est un langage, l'interprèteur de bash cherche à vérifier que la phrase est syntaxiquement correcte et si elle a du sens, tu comprends ce qu'on essaie de te dire ? Il n'y a pas de notion de priorité entre ces éléments: ce serait comme de savoir ce qui prévaut entre la ponctuation, le verbe, le sujet et les compléments d'une phrase et chaque élément entre eux... un point n'est pas prioritaire par rapport à un point virgule, «je» n'est pas prioritaire sur «tu», un point n'est pas prioritaire sur «je», etc.

[Wax-Reggea]

Admettons, alors que fait le l'interpréteur comme je rentre une commande ? Je veux dire, il y a bien un moment, ou il va executer des binaires et faire ce que la commande est sensée faire...

Heu... Je ne connais pas l'analyse lexicale et syntaxique de bash, mais c'est nettement plus complexe que ça.

Bien sur, c'est plus compliqué, mais cette étape, il la fait j'en suis certain.

[FoolEcho]

Heu... Je ne connais pas l'analyse lexicale et syntaxique de bash, mais c'est nettement plus complexe que ça.

Bien sur, c'est plus compliqué, mais cette étape, il la fait j'en suis certain.

Bien évidemment, mais encore une fois ce n'est pas une affaire d'opérateur prioritaire ou pas. Bash analyse l'instruction avant d'exécuter... et une instruction peut être éminément tordue (hors arithmétique où là oui, il y a des priorités déterminées).

Enlève-toi le mal de tête en construisant des instructions dans l'ordre séquentiel car de toutes manières c'est ainsi que bash procède, c'est tout (à mon avis ls << salut > toto est plus compréhensible que ls > toto << salut, même s'il se trouve que bash comprend les deux tournures... comme une phrase qui serait du type: «je vais sortir ce soir» et «ce soir, je vais sortir» ... en dehors de ce cas précis et des raccourcis d'écriture, tu as juste mis le doigt sur un cas assez particulier).

[Wax-Reggea]

Bien évidemment, mais encore une fois ce n'est pas une affaire d'opérateur prioritaire ou pas. Bash analyse l'instruction avant d'exécuter... et une instruction peut être éminément tordue (hors arithmétique où là oui, il y a des priorités déterminées).

S'il ne se base pas sur des prioprités, comment fait-il pour construire son arbre correctement ? Ils ont fait une IA qui parle en bash ?

Alors oui, mon exemple est un cas bien tordu, mais c'est ce genre de truc qui fait qu'on comprend ou pas.

[FoolEcho]

S'il ne se base pas sur des prioprités, comment fait-il pour construire son arbre correctement ? Ils ont fait une IA qui parle en bash ?

Cela se base sur des règles (des règles propres à un langage de programmation donné), non des priorités: bash analyse et reconnaît (ou non) ces motifs. Une fois fait, il peut tenter d'exécuter le code.

Si ça t'intéresse autant, procure-toi des cours sur les analyses lexicales et syntaxiques et tu comprendras peut-être ce qu'on se tue à te dire.

[benjarobin]

Si tu veux des infos :
http://www.aosabook.org/en/bash.html
http://www.opensource.apple.com/source/ ... arse.y?txt
Après il faut connaitre ce que c'est le token parsing, le langage yacc / bison...