expression régulière selection d'un bout de trame

Le
n
bonjour,
j'ai fait une cature de trames qui contient notament des trames
<SyncML>*</SyncML>
avec l'* qui est tout le contenu de la trame.

Je voudrais recuprer le contenu de ces trames, (avec les deux balises
<SyncML> et </SyncML> si possible), mais j'ai un peut de mal trouver
la commande adapte.
Pour moi, il faudrai utiliser une expression rgulire du type
"<SyncML>(.*)</SyncML>" mais je ne vois pas trop avec quelle
commande,

j'obtiens toutes les trames en faisant un
cat maCapture
et je pense qu'on pourrais mettre tous a dans une autre commande avec
un pipe et une expression rgulire
Je ne suis pas trs dou avec tous a, pourriez vous me donner un ptit
coup de main ?

Merci

Fab
Vos réponses Page 3 / 4
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
n
Le #732193
Et c'est quoi le probleme avec la commande perl que j'ai donnée?


aucun, elle fonctionne très bien, c'est juste que je ne l'avais pas
encore testé puis que je cherchait à faire une commande que je
comprenait, mais du coup, j'ai compris la tienne ;)
merci, en fait, c'est exactement le genre de commande simple que je
cherchait !

Fab

ALain Montfranc
Le #743034
Stephane Chazelas a écrit
2007-04-16, 15:39(+02), ALain Montfranc:
[...]
Faire ensuite un sed 's/F[^D]*D//' pour virer le contenu hors trame =>
tu obtiens le contenu des trames
[...]


Dans l'esprit, c'est valide. A ceci pres que sed travaille sur
du texte et qu'en enlevant les sauts de lignes (pas retour
charriot!),


Exact, on peut ruser en ajoutant dessauts de ligne avant les <SynxML>
et apres les </SyncML> pour limiter la taille des lignes

Remarque...

Finalement on peut faire plus simple :
on translate les sautfs de ligne par un caractère bouchon
on rajoute un saut de ligne avant les <Syn et apres les </sync
on grepe les lignes contenant <Sync en debut de ligne
on reinjecte les retours chariot


Stephane Chazelas
Le #743030
2007-04-16, 16:45(+02), ALain Montfranc:
[...]
Finalement on peut faire plus simple :
on translate les sautfs de ligne par un caractère bouchon


A partir de la, on n'as plus du texte.

Et il nous faut donc un outil non-text (i.e. ni sed, ni grep)
pour faire:

on rajoute un saut de ligne avant les <Syn et apres les </sync
on grepe les lignes contenant <Sync en debut de ligne
on reinjecte les retours chariot


En gros, il faudra utiliser perl ou des versions GNU des
text-utilities qui supportent du non-text.

--
Stéphane

ALain Montfranc
Le #743029
Stephane Chazelas a écrit
2007-04-16, 16:45(+02), ALain Montfranc:
[...]
Finalement on peut faire plus simple :
on translate les sautfs de ligne par un caractère bouchon


A partir de la, on n'as plus du texte.


Pourquoi ? Le caractere bouchon peut etre un caractere texte


Et il nous faut donc un outil non-text (i.e. ni sed, ni grep)
pour faire:

on rajoute un saut de ligne avant les <Syn et apres les </sync
on grepe les lignes contenant <Sync en debut de ligne
on reinjecte les retours chariot


En gros, il faudra utiliser perl ou des versions GNU des
text-utilities qui supportent du non-text.



Stephane Chazelas
Le #735775
2007-04-16, 17:13(+02), ALain Montfranc:
Stephane Chazelas a écrit
2007-04-16, 16:45(+02), ALain Montfranc:
[...]
Finalement on peut faire plus simple :
on translate les sautfs de ligne par un caractère bouchon


A partir de la, on n'as plus du texte.


Pourquoi ? Le caractere bouchon peut etre un caractere texte
[...]


Parce que du texte, par definition (definition Unix ou POSIX
tout du moins) est

([^n]{0,LINE_MAX}n)*

Donc, si tu enleve le n final, ou si tu te retrouves avec plus
de LINE_MAX characters entre 2 n, ce n'est plus du texte.

--
Stéphane



ALain Montfranc
Le #735774
Stephane Chazelas a écrit
2007-04-16, 17:13(+02), ALain Montfranc:
Stephane Chazelas a écrit
2007-04-16, 16:45(+02), ALain Montfranc:
[...]
Finalement on peut faire plus simple :
on translate les sautfs de ligne par un caractère bouchon


A partir de la, on n'as plus du texte.


Pourquoi ? Le caractere bouchon peut etre un caractere texte
[...]


Parce que du texte, par definition (definition Unix ou POSIX
tout du moins) est

([^n]{0,LINE_MAX}n)*

Donc, si tu enleve le n final, ou si tu te retrouves avec plus
de LINE_MAX characters entre 2 n, ce n'est plus du texte.


ok




Stephane Chazelas
Le #735773
2007-04-16, 15:38(+00), Stephane Chazelas:
2007-04-16, 17:13(+02), ALain Montfranc:
Stephane Chazelas a écrit
2007-04-16, 16:45(+02), ALain Montfranc:
[...]
Finalement on peut faire plus simple :
on translate les sautfs de ligne par un caractère bouchon


A partir de la, on n'as plus du texte.


Pourquoi ? Le caractere bouchon peut etre un caractere texte
[...]


Parce que du texte, par definition (definition Unix ou POSIX
tout du moins) est

([^n]{0,LINE_MAX}n)*
[...]


En fait, c'est plutot:

([^n]{0,LINE_MAX-1}n)*

(note que ce sont des characters, pas des bytes, encore moins
des octets...)

Voir
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_392

--
Stéphane




Olivier Miakinen
Le #735772

En fait, c'est plutot:

([^n]{0,LINE_MAX-1}n)*

(note que ce sont des characters, pas des bytes, encore moins
des octets...)


Je vois bien la différence entre les octets (bytes) et les caractères
(characters), mais pas entre les bytes et les octets.

Voir
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_392


Dans cette définition, on voit bien qu'une ligne doit contenir des
caractères, mais la longueur est définie en nombre d'octets. D'où la
quasi impossibilité de la définir en une seule regexp.

Stephane Chazelas
Le #735771
2007-04-16, 18:36(+02), Olivier Miakinen:

En fait, c'est plutot:

([^n]{0,LINE_MAX-1}n)*

(note que ce sont des characters, pas des bytes, encore moins
des octets...)


Je vois bien la différence entre les octets (bytes) et les caractères
(characters), mais pas entre les bytes et les octets.


Depend des terminologies. Quand on fait du C par exemple, octet
et byte sont differents. Le byte est le plus petit element
adressable, souvent un octet. Et un octet est un mot de 8 bits.

Par contre, pour POSIX/Unix, apparemment byte == octet:
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_84

donc mon commentaire n'etait pas vraiment pertinent.

Voir
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_392


Dans cette définition, on voit bien qu'une ligne doit contenir des
caractères, mais la longueur est définie en nombre d'octets. D'où la
quasi impossibilité de la définir en une seule regexp.


Indeed, well spotted, my bad again.

--
Stéphane


Matthieu Moy
Le #735770
Stephane Chazelas
Depend des terminologies. Quand on fait du C par exemple, octet
et byte sont differents. Le byte est le plus petit element
adressable, souvent un octet. Et un octet est un mot de 8 bits.

Par contre, pour POSIX/Unix, apparemment byte == octet:
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#ta g_03_84

donc mon commentaire n'etait pas vraiment pertinent.


Bah, le problème, c'est que « octet », c'est cens é être la traduction
française de « byte », mais sur une architecture o u le plus petit
élément adressable ne fait pas 8 bits, on est bien embêtà ©s pour
traduire « byte » en français ;-).

--
Matthieu

Publicité
Poster une réponse
Anonyme