Les lignes n\'ont pas forcément toutes les clés renseignées.
Je souhaite parser ces lignes pour n\'en conserver qu\'une partie, par
exemple msg, id, value2 et value3. Je ne trouve pas de moyen simple
pour parser ces lignes. Mon plus gros problème vient des espaces dans
certaines valeurs et de l\'absence de clés dans d\'autres.
J\'en ai besoin pour faire:
tail -f /var/log/my_log | parse_line.sh
C\'est sous FreeBSD, avec csh (pas de bash disponible) et les utilitaires
classiques (sed, cut, awk, etc..)
Les lignes n'ont pas forcément toutes les clés renseignées.
Je souhaite parser ces lignes pour n'en conserver qu'une partie, par exemple msg, id, value2 et value3. Je ne trouve pas de moyen simple pour parser ces lignes. Mon plus gros problème vient des espaces dans certaines valeurs et de l'absence de clés dans d'autres.
Les lignes n'ont pas forcément toutes les clés renseignées.
Je souhaite parser ces lignes pour n'en conserver qu'une partie, par
exemple msg, id, value2 et value3. Je ne trouve pas de moyen simple
pour parser ces lignes. Mon plus gros problème vient des espaces dans
certaines valeurs et de l'absence de clés dans d'autres.
Les lignes n'ont pas forcément toutes les clés renseignées.
Je souhaite parser ces lignes pour n'en conserver qu'une partie, par exemple msg, id, value2 et value3. Je ne trouve pas de moyen simple pour parser ces lignes. Mon plus gros problème vient des espaces dans certaines valeurs et de l'absence de clés dans d'autres.
Je souhaite parser ces lignes pour n'en conserver qu'une partie, par exemple msg, id, value2 et value3. Je ne trouve pas de moyen simple pour parser ces lignes. Mon plus gros problème vient des espaces dans certaines valeurs et de l'absence de clés dans d'autres.
Et je retombe dans un problème : je peux concaténer les lignes en une seule avec un | sed 'N;s/n/ /' ou équivalent avec awk, mais comme certaines lignes de log n'ont pas toutes les clés, cela finit par tout décaler :-/
Ca va finir avec un oneliner abominable du genre: tail -f log | grep (...) | tr 'n' ' ' | sed s/msg/µmsg/g | tr 'µ' 'n'
ou mieux, un: ssh server tail -f log | script_local_evolué
Merci pour l'idée en tout cas :) -- Kevin
Le 25-03-2015, Lucas Levrel <lucas.levrel@u-pec.fr> a écrit :
Je souhaite parser ces lignes pour n'en conserver qu'une partie, par
exemple msg, id, value2 et value3. Je ne trouve pas de moyen simple
pour parser ces lignes. Mon plus gros problème vient des espaces dans
certaines valeurs et de l'absence de clés dans d'autres.
Et je retombe dans un problème : je peux concaténer les lignes
en une seule avec un | sed 'N;s/n/ /' ou équivalent avec awk, mais comme
certaines lignes de log n'ont pas toutes les clés, cela finit par tout
décaler :-/
Ca va finir avec un oneliner abominable du genre:
tail -f log | grep (...) | tr 'n' ' ' | sed s/msg/µmsg/g | tr 'µ' 'n'
ou mieux, un:
ssh server tail -f log | script_local_evolué
Je souhaite parser ces lignes pour n'en conserver qu'une partie, par exemple msg, id, value2 et value3. Je ne trouve pas de moyen simple pour parser ces lignes. Mon plus gros problème vient des espaces dans certaines valeurs et de l'absence de clés dans d'autres.
Et je retombe dans un problème : je peux concaténer les lignes en une seule avec un | sed 'N;s/n/ /' ou équivalent avec awk, mais comme certaines lignes de log n'ont pas toutes les clés, cela finit par tout décaler :-/
Ca va finir avec un oneliner abominable du genre: tail -f log | grep (...) | tr 'n' ' ' | sed s/msg/µmsg/g | tr 'µ' 'n'
ou mieux, un: ssh server tail -f log | script_local_evolué
Merci pour l'idée en tout cas :) -- Kevin
Lucas Levrel
Le 25 mars 2015, Kevin Denis a écrit :
$ egrep egrep: Command not found.
:-)
J'ai quand même grep -E qui me permet de faire ce genre de choses: grep -E -o 'msg="[A-Za-z0-9 -.:]*"|value2=[a-z]*'
Ca marche bien, mais l'ensemble des clés choisies sont affichées sur plusieurs lignes:
Est-ce qu'un truc comme ça est possible en csh : --- parse_line.sh --- while read LINE do MSG=$(echo $LINE | grep -E -o ...) VALUE2=$(echo $LINE | ...) ... done echo $MSG $VALUE2 ... --------------------- ?
(Tu as bien dit que tu pouvais envoyer le log dans un script, tu n'es pas contraint à un one-liner ?)
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
Le 25 mars 2015, Kevin Denis a écrit :
$ egrep
egrep: Command not found.
:-)
J'ai quand même grep -E qui me permet de faire ce genre de choses:
grep -E -o 'msg="[A-Za-z0-9 -.:]*"|value2=[a-z]*'
Ca marche bien, mais l'ensemble des clés choisies sont affichées sur
plusieurs lignes:
Est-ce qu'un truc comme ça est possible en csh :
--- parse_line.sh ---
while read LINE
do
MSG=$(echo $LINE | grep -E -o ...)
VALUE2=$(echo $LINE | ...)
...
done
echo $MSG $VALUE2 ...
---------------------
?
(Tu as bien dit que tu pouvais envoyer le log dans un script, tu n'es pas
contraint à un one-liner ?)
Est-ce qu'un truc comme ça est possible en csh : --- parse_line.sh --- while read LINE do MSG=$(echo $LINE | grep -E -o ...) VALUE2=$(echo $LINE | ...) ... done echo $MSG $VALUE2 ... --------------------- ?
(Tu as bien dit que tu pouvais envoyer le log dans un script, tu n'es pas contraint à un one-liner ?)
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
Nicolas George
Lucas Levrel , dans le message , a écrit :
while read LINE
Ça commence mal si la ligne contient des backslashes.
do MSG=$(echo $LINE | grep -E -o ...)
Et ça continue de même.
Des scripts qui ne marchent pas, on peut en faire en csh aussi, oui, pas de problème.
Lucas Levrel , dans le message
<alpine.LNX.2.11.1503252125230.2674@localhost>, a écrit :
while read LINE
Ça commence mal si la ligne contient des backslashes.
do
MSG=$(echo $LINE | grep -E -o ...)
Et ça continue de même.
Des scripts qui ne marchent pas, on peut en faire en csh aussi, oui, pas de
problème.
(Tu as bien dit que tu pouvais envoyer le log dans un script, tu n'es pas contraint à un one-liner ?)
Non. C'est une appliance Netasq, donc un FreeBSD dedans. Je pensais qu'il y avait moyen d'obtenir un one-liner :) mais je vais faire un script. -- Kevin
Le 25-03-2015, Lucas Levrel <lucas.levrel@u-pec.fr> a écrit :
J'ai quand même grep -E qui me permet de faire ce genre de choses:
grep -E -o 'msg="[A-Za-z0-9 -.:]*"|value2=[a-z]*'
Ca marche bien, mais l'ensemble des clés choisies sont affichées sur
plusieurs lignes:
Est-ce qu'un truc comme ça est possible en csh :
--- parse_line.sh ---
while read LINE
J'avais tenté, mais le while read ne semble pas exister en csh:
http://www.linuxquestions.org/questions/programming-9/csh-while-read-738708/
question: Is there an equivalent in csh to bash's while read cariable list?
Answer: AFAIK, the answer is no.
(Tu as bien dit que tu pouvais envoyer le log dans un script, tu n'es pas
contraint à un one-liner ?)
Non. C'est une appliance Netasq, donc un FreeBSD dedans. Je pensais qu'il
y avait moyen d'obtenir un one-liner :) mais je vais faire un script.
--
Kevin
(Tu as bien dit que tu pouvais envoyer le log dans un script, tu n'es pas contraint à un one-liner ?)
Non. C'est une appliance Netasq, donc un FreeBSD dedans. Je pensais qu'il y avait moyen d'obtenir un one-liner :) mais je vais faire un script. -- Kevin
Benoit Izac
Bonjour,
le 26/03/2015 à 10:06, Kevin Denis a écrit dans le message :
Est-ce qu'un truc comme ça est possible en csh : --- parse_line.sh --- while read LINE
Donc pourquoi utiliser csh (tcsh) plutôt que sh (ash il me semble) ?
-- Benoit Izac
Bonjour,
le 26/03/2015 à 10:06, Kevin Denis a écrit dans le message
<slrnmh80hn.iql.kevin@slackwall.local.tux> :
Est-ce qu'un truc comme ça est possible en csh :
--- parse_line.sh ---
while read LINE
J'avais tenté, mais le while read ne semble pas exister en csh:
http://www.linuxquestions.org/questions/programming-9/csh-while-read-738708/
question: Is there an equivalent in csh to bash's while read cariable list?
Answer: AFAIK, the answer is no.
Donc pourquoi utiliser csh (tcsh) plutôt que sh (ash il me semble) ?
Ça commence mal si la ligne contient des backslashes.
do MSG=$(echo $LINE | grep -E -o ...)
Et ça continue de même.
Sans doute. Comme les points de suspension le suggèrent, ce sont des pistes.
En l'occurence, seul l'OP sait ce qu'il est susceptible d'y avoir.
Des scripts qui ne marchent pas, on peut en faire en csh aussi, oui, pas de problème.
Ouaip, c'est comme les réponses inutiles, on peut les faire dans toutes les langues.
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
Nicolas George
Lucas Levrel , dans le message , a écrit :
Ouaip, c'est comme les réponses inutiles
Souligner les erreurs classiques dans la rédaction de scripts shell, erreurs classiques qui conduisent régulièrement à des pertes de données accidentelles ou des trous de sécurité...
À toi de voir si tu considères ça comme inutile.
Lucas Levrel , dans le message
<alpine.LSU.2.10.1503271255420.3781@coulomb.u-pec.fr>, a écrit :
Ouaip, c'est comme les réponses inutiles
Souligner les erreurs classiques dans la rédaction de scripts shell, erreurs
classiques qui conduisent régulièrement à des pertes de données
accidentelles ou des trous de sécurité...
Souligner les erreurs classiques dans la rédaction de scripts shell, erreurs classiques qui conduisent régulièrement à des pertes de données accidentelles ou des trous de sécurité...
À toi de voir si tu considères ça comme inutile.
Paul Gaborit
À (at) 27 Mar 2015 12:52:36 GMT, Nicolas George <nicolas$ écrivait (wrote):
Lucas Levrel , dans le message , a écrit :
Ouaip, c'est comme les réponses inutiles
Souligner les erreurs classiques dans la rédaction de scripts shell, erreurs classiques qui conduisent régulièrement à des pertes de données accidentelles ou des trous de sécurité...
À toi de voir si tu considères ça comme inutile.
Plutôt que de souligner les erreurs, il serait bon de proposer le moyen de ne pas les faire !
Et le premier moyen, bien connu de tous ceux qui développent proprement en shell, est de ne pas utiliser (t)csh comme shell pour les scripts.
Il vaut mieux choisir sh (celui de FreeBSD n'est pas bash) ce qui oblige à faire du shell standard POSIX. Ou alors choisir bash, ksh ou zsh qui sont bien plus puissants mais dont la disponibilité n'est pas garantie partout.
À (at) 27 Mar 2015 12:52:36 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Lucas Levrel , dans le message
<alpine.LSU.2.10.1503271255420.3781@coulomb.u-pec.fr>, a écrit :
Ouaip, c'est comme les réponses inutiles
Souligner les erreurs classiques dans la rédaction de scripts shell, erreurs
classiques qui conduisent régulièrement à des pertes de données
accidentelles ou des trous de sécurité...
À toi de voir si tu considères ça comme inutile.
Plutôt que de souligner les erreurs, il serait bon de proposer le moyen
de ne pas les faire !
Et le premier moyen, bien connu de tous ceux qui développent proprement
en shell, est de ne pas utiliser (t)csh comme shell pour les scripts.
Il vaut mieux choisir sh (celui de FreeBSD n'est pas bash) ce qui oblige
à faire du shell standard POSIX. Ou alors choisir bash, ksh ou zsh qui
sont bien plus puissants mais dont la disponibilité n'est pas garantie
partout.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) 27 Mar 2015 12:52:36 GMT, Nicolas George <nicolas$ écrivait (wrote):
Lucas Levrel , dans le message , a écrit :
Ouaip, c'est comme les réponses inutiles
Souligner les erreurs classiques dans la rédaction de scripts shell, erreurs classiques qui conduisent régulièrement à des pertes de données accidentelles ou des trous de sécurité...
À toi de voir si tu considères ça comme inutile.
Plutôt que de souligner les erreurs, il serait bon de proposer le moyen de ne pas les faire !
Et le premier moyen, bien connu de tous ceux qui développent proprement en shell, est de ne pas utiliser (t)csh comme shell pour les scripts.
Il vaut mieux choisir sh (celui de FreeBSD n'est pas bash) ce qui oblige à faire du shell standard POSIX. Ou alors choisir bash, ksh ou zsh qui sont bien plus puissants mais dont la disponibilité n'est pas garantie partout.
