[Résolu]Problème de sed/awk

ehmicky · Le 27/09/2010, à 19:57

Salut à tous,
J'ai un fichier comme ça (l'indentation compte) :

   texte_texte texte_texte
texte 
   texte_quelconque_text texte_texte

Je voudrais que, sur chaque ligne, chaque caractère (imprimable ou non) qui précède la première occurence de  soit dupliqué, avec un \b au milieu. Ainsi ensuite, en pipant avec less, cela donnera tout caractère précédant un  en gras.
Par exemple, sur la première ligne, ça donnerait :

 \b  \b  \b t\bte\bex\bxt\bte\be_\b_t\bte\bex\bxt\bte\be \b texte_texte

Il me faudrait un code qui marche, parce que je ne trouve pas, y'a toujours quelque chose qui cloche !
Merci !

PS : Le problème, c'est que si :

sed 's/./&\\b&/g'

marche (en dehors du fait qu'il ne prend pas en compte le délimiteur ), cependant :

sed 's/\(.\)\(.*\)/\1\\b\1\2/g'

Ne remplace que la première occurence, et non toutes les occurences.

Dernière modification par ehmicky (Le 27/09/2010, à 21:26)

chopinhauer · Le 27/09/2010, à 20:18

ehmicky a écrit :

Je voudrais que, sur chaque ligne, chaque caractère (imprimable ou non) qui précède la première occurence de  soit dupliqué, avec un \b au milieu. Ainsi ensuite, en pipant avec less, cela donnera tout caractère précédant un  en gras.

Le overstrike lettre + backspace + lettre n'est pas l'unique manière pour faire du gras. Dans les terminal il y a aussi la séquence ANSI: '\e[0m' pour le mode normal, '\e[1m' pour le gras, '\e[4m' pour le sous-ligné… Pour l'aspect graphique c'est toujours '\e[<nombres>m'. Tu peux regarder les autres sur Wikipedia ou sur Invisible Island.

PS: '\e' est le caractère escape (^[ ou 0x1b). À la place de '\e[' tu peux aussi utiliser CSI: 0x9b ou 0233.

Dernière modification par chopinhauer (Le 27/09/2010, à 20:29)

ehmicky · Le 27/09/2010, à 20:23

Merci, je vais regarder si ça me permet de simplifier mon problème.
Pour le problème en lui-même, j'ai en fait trouver une solution. Je la poste.

La voici :

#!/bin/bash 

while IFS="" read ligne ; do
	echo "$(sed 's/./&\\b&/g' <<<${ligne%%*})${ligne#*}"
done <"$1"

Ouh là, là ça pas l'air de marcher en fait, je vais regarder ça.

Edit : attends, je teste ton code, mais je crois qu'il va peut-être y avoir le même problème que j'avais eu.
Edit2 : Ah non ! Effectivement, ça devrait résoudre le problème, parce que ça prend tout $.*$ d'un coup. Le problème en fait, c'était que sed ne remplaçait que la première occurence, mais là avec \e[1m...\e[0m ça devrait résoudre le problème, je regarde.
Edit3 : ouh là, il a plein de problèmes le code ci-dessus, il est vraiment mauvais, ta solution devrait être ok

Dernière modification par ehmicky (Le 27/09/2010, à 20:36)

chopinhauer · Le 27/09/2010, à 20:29

En gros

sed 's/^\(.*\)/\x1b[1m\1\x1b0m/g'

devrait marcher. Sans oublier l'option '-R' (ou '-r') à less.

ehmicky · Le 27/09/2010, à 20:37

Alors je vais voir ça.
Par contre, je vais devoir mettre deux backlashs avant e[1m sûrement

Ok, donc avec ça, ça marche :

sed 's/^\([^]*\)/\\e[1m\1\\e[0m/g'

Dernière modification par ehmicky (Le 27/09/2010, à 20:41)

Postmortem · Le 27/09/2010, à 20:39

En repartant de ton essai plus haut :

#!/bin/bash 

while read
do
    echo "$(sed 's/./&\\b&/g' <<<${REPLY%%*})${REPLY#*}"
done <"$1"

Dernière modification par Postmortem (Le 27/09/2010, à 20:40)

ehmicky · Le 27/09/2010, à 20:44

Postmortem a écrit :

En repartant de ton essai plus haut :

#!/bin/bash 

while read
do
    echo "$(sed 's/./&\\b&/g' <<<${REPLY%%*})${REPLY#*}"
done <"$1"

Non justement, le truc c'est que j'avais un problème avec la boucle read, parce que read supprimait les indentations des lignes qu'il lisait, c'est pour ça que j'ai mis IFS="". Sinon la variable par défaut REPLY ou ma variable "ligne", ça donnait le même résultat.

En fait, ça a l'air con comme ça, mais le truc c'est que même avec le flag "/g", sed ne faisait son action que sur la première occurence, mais je savais pas comment faire pour qu'il fasse son action à nouveau sans passer par une boucle. Alors je me suis dit "boucle while read", mais j'ai vu que read en fait supprimait les indentations. Mais là avec la solution de chopinhauer, je traite tout le morceau d'un coup, donc ça devrait coller.

Dernière modification par ehmicky (Le 27/09/2010, à 20:48)

Postmortem · Le 27/09/2010, à 20:45

Le read sans mettre de nom de variable derrière (donc ça initialise la variable REPLY) permet d'éviter cette perte de formatage
En tout cas, je viens d'essayer ton exemple chez moi et ça marche

Dernière modification par Postmortem (Le 27/09/2010, à 20:46)

chopinhauer · Le 27/09/2010, à 20:48

Vu que ta question portait aussi sur Awk l'éternel oublié, voilà la solution avec cet outil:

awk 'BEGIN{FS=OFS=""} {gsub(/./,"&\b&",$1); print $0}'

PS: Ceci dit awk et sed posent un peu de problèmes avec UTF-8. Cette commande va couper les séquences UTF-8 en petits morceaux.

Dernière modification par chopinhauer (Le 27/09/2010, à 20:57)

ehmicky · Le 27/09/2010, à 20:48

Ok ! Désolé, j'ignorais ça, c'est cool, je vais regarder.
Non, ça marche pas en fait pour le fait que REPLY permette de garder le formatage :

while read REPLY ; do
    echo "$REPLY"
done <<<"  essai"

Résultat :

essai

Et avec :

while IFS="" read REPLY ; do
    echo "$REPLY"
done <<<"  essai"

Ca donne :

   essai

Dernière modification par ehmicky (Le 27/09/2010, à 20:53)

Postmortem · Le 27/09/2010, à 20:49

Oups, dans un script ça ne marche pas mais en direct dans le terminal, ça fonctionne !
Désolé !

while read
do
    echo "$(sed 's/./&\\b&/g' <<<${REPLY%%*})${REPLY#*}"
done < test.txt

Dernière modification par Postmortem (Le 27/09/2010, à 20:51)

ehmicky · Le 27/09/2010, à 20:55

Oui, t'as raison en shell interactif, y'a cette différence en fait. J'ai du mal à discerner pourquoi, mais c'est le cas !
Bon, je vais retourner au problème, et finir cette question !

Dernière modification par ehmicky (Le 27/09/2010, à 20:55)

Totor · Le 27/09/2010, à 21:04

@ehmicky : oui effectivement. le truc avec les variables "ligne" et "REPLY" je l'ai répété à plusieurs reprises (mais cela ne doit pas faire suffisamment de temps que tu es régulier pour l'avoir lu !

@Postmortem : ce n'est pas le fait d'être en console ou en script qui fait qu'il y a perte de formatage. C'est que tu ne protèges pas l'expansion de paramètre ${REPLY%%*} lorsque tu la passes à sed :

#!/bin/bash
while read
do
    echo "$(sed 's/./&\\b&/g' <<<"${REPLY%%*}")${REPLY#*}"
done < "$1"

Dernière modification par Totor (Le 27/09/2010, à 21:06)

ehmicky · Le 27/09/2010, à 21:09

Ok, code final, marche impèc' !

while read ; do
    sed 's/^\([^]*\)/\x1b[1m\1\x1b[0m/g' <<<"$REPLY"
done <"$1" | less -r

Merci beaucoup !

@Totor : oui ça doit être ça

Dernière modification par ehmicky (Le 27/09/2010, à 21:10)

Postmortem · Le 27/09/2010, à 21:20

Oups, j'ai du perdre ou rajouter des " lors de mes essais...
Merci pour les sed et autres awk vu sur ce fil qui m'ont fait m'entrainer en tout cas !

ehmicky · Le 27/09/2010, à 21:26

En tout cas, ça carbure ici, pas de problème insolvable !

chopinhauer · Le 27/09/2010, à 22:01

Après quelque test, il me semble que sed et awk se comportent bien tous les deux dans un environnement UTF-8. L'expression '.' trouve bien les codepoint Unicode et pas les simples octets qui le composent.

Si quelqu'un a de la documentation à l'égard, je suis preneur.

ehmicky · Le 27/09/2010, à 22:51

Sans doc' :

sed 's/o.o/oo/g' <<<"oo"

me semble indiquer que sed est compatible UTF-8.
Par contre, par exemple :

awk 'BEGIN { FIELDWIDTHS="1 1 1" } { print $3 }' <<<"oo"

me semble renvoyer un résultat indiquant que ce n'est pas le cas.
A vérifier

Edit : autre test dans ce sens :

awk '{ printf "%.5s\n", $1 }' <<<"1345"

PS : décidément on l'aura bien mis à contribuer le smiley , je comprends qu'il fasse la gueule

Dernière modification par ehmicky (Le 27/09/2010, à 22:56)

chopinhauer · Le 27/09/2010, à 23:42

C'est juste le code qui compte le caractères qui ne supporte pas UTF-8, un simple:

awk '{sub(/o.o/,"oo");print}' <<<"oo"

marche comme prévu.

ehmicky · Le 27/09/2010, à 23:53

Je sais pas si ça se tient, mais je demande si c'est pas parce que gawk fait appel aux fonctions de globbing de glibc, et en interne, il a aussi des fonctions qui marchent pas en multi-octets.
Je dis ça, j'en ai aucune idée, je dis juste ça au cas où, je sais pas

chopinhauer · Le 28/09/2010, à 00:17

Les deux n'ont pas d'autres dépendances que glibc, donc j'imagine qu'ils utilisent les regexp POSIX de la librairie. Le problème de FIELDWIDTHS est bien connu, par contre printf ne se comporte pas comme la fonction de C:

awk '{ printf "%.5ls", $1 }' <<<"" | wc -c

donne 5, tandis qu'il n'est pas censé couper un caractère à moitié.

ehmicky · Le 28/09/2010, à 01:02

Hey, t'as ramené toute la tribu de smiley !

Oui, regexp, pas globbing ! et puis avec %s et non %ls, ça pouvait pas marcher de toute façon

Sinon, pour en être sûr... sources

Bon je rigole, mais en attendant, il y a des "regex.h" et "regex_international.h", donc bon ça a bien l'air d'être le cas ! Maintenant, je me sens pas prêt à aller là-dedans !

Dernière modification par ehmicky (Le 28/09/2010, à 01:04)

chopinhauer · Le 28/09/2010, à 01:54

Donc apparemment gawk utilise son propre printf qui ignore l'option l (selon la norme POSIX). FIELDWIDTHS est un extension gawk qui utilise encore les octets, par contre length donne la longueur exacte.

ehmicky · Le 28/09/2010, à 03:54

Si tu veux vraiment savoir, tu peux demander à comp.lang.awk, y'a des psychopathes du awk là-bas... Ils te sortent des lignes à te retourner le ciboulot
Je pense qu'ils peuvent te décrire l'évolution de la prise en charge d'Unicode par gawk, release par release, depuis 10 ans

Dernière modification par ehmicky (Le 28/09/2010, à 03:56)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 27/09/2010, à 19:57

[Résolu]Problème de sed/awk

#2 Le 27/09/2010, à 20:18

Re : [Résolu]Problème de sed/awk

#3 Le 27/09/2010, à 20:23

Re : [Résolu]Problème de sed/awk

#4 Le 27/09/2010, à 20:29

Re : [Résolu]Problème de sed/awk

#5 Le 27/09/2010, à 20:37

Re : [Résolu]Problème de sed/awk

#6 Le 27/09/2010, à 20:39

Re : [Résolu]Problème de sed/awk

#7 Le 27/09/2010, à 20:44

Re : [Résolu]Problème de sed/awk

#8 Le 27/09/2010, à 20:45

Re : [Résolu]Problème de sed/awk

#9 Le 27/09/2010, à 20:48

Re : [Résolu]Problème de sed/awk

#10 Le 27/09/2010, à 20:48

Re : [Résolu]Problème de sed/awk

#11 Le 27/09/2010, à 20:49

Re : [Résolu]Problème de sed/awk

#12 Le 27/09/2010, à 20:55

Re : [Résolu]Problème de sed/awk

#13 Le 27/09/2010, à 21:04

Re : [Résolu]Problème de sed/awk

#14 Le 27/09/2010, à 21:09

Re : [Résolu]Problème de sed/awk

#15 Le 27/09/2010, à 21:20

Re : [Résolu]Problème de sed/awk

#16 Le 27/09/2010, à 21:26

Re : [Résolu]Problème de sed/awk

#17 Le 27/09/2010, à 22:01

Re : [Résolu]Problème de sed/awk

#18 Le 27/09/2010, à 22:51

Re : [Résolu]Problème de sed/awk

#19 Le 27/09/2010, à 23:42

Re : [Résolu]Problème de sed/awk

#20 Le 27/09/2010, à 23:53

Re : [Résolu]Problème de sed/awk

#21 Le 28/09/2010, à 00:17

Re : [Résolu]Problème de sed/awk

#22 Le 28/09/2010, à 01:02

Re : [Résolu]Problème de sed/awk

#23 Le 28/09/2010, à 01:54

Re : [Résolu]Problème de sed/awk

#24 Le 28/09/2010, à 03:54

Re : [Résolu]Problème de sed/awk

Pied de page des forums