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..)
le 27/03/2015 à 12:59, Lucas Levrel a écrit dans le message :
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.
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.
Je suppose que Nicolas faisait allusion au fait qu'il serait plus prudent d'utiliser l'option -r de read afin de ne pas faire de traitement spécial sur les backslashes (typiquement les retirer sauf s'il y en a deux consécutifs) ou encore qu'il est toujours hasardeux d'utiliser une variable qui n'est pas entourée de double quote (dès qu'il y a des espaces par exemple).
Peut-être pensait-il également qu'il serait préférable d'utiliser printf à la place d'echo afin d'avoir un comportement uniforme sur les différents shell qui peuvent proposer un mode sh ? Lui seul le sait et c'est bien ça le problème me semble-t-il.
while read -r LINE; do MSG=$(printf '%sn' "$LINE" | grep -E -o ...) done
-- Benoit Izac
Bonjour,
le 27/03/2015 à 12:59, Lucas Levrel a écrit dans le message
<alpine.LSU.2.10.1503271255420.3781@coulomb.u-pec.fr> :
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.
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.
Je suppose que Nicolas faisait allusion au fait qu'il serait plus
prudent d'utiliser l'option -r de read afin de ne pas faire de
traitement spécial sur les backslashes (typiquement les retirer sauf
s'il y en a deux consécutifs) ou encore qu'il est toujours hasardeux
d'utiliser une variable qui n'est pas entourée de double quote (dès
qu'il y a des espaces par exemple).
Peut-être pensait-il également qu'il serait préférable d'utiliser printf
à la place d'echo afin d'avoir un comportement uniforme sur les
différents shell qui peuvent proposer un mode sh ? Lui seul le sait et
c'est bien ça le problème me semble-t-il.
while read -r LINE; do
MSG=$(printf '%sn' "$LINE" | grep -E -o ...)
done
le 27/03/2015 à 12:59, Lucas Levrel a écrit dans le message :
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.
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.
Je suppose que Nicolas faisait allusion au fait qu'il serait plus prudent d'utiliser l'option -r de read afin de ne pas faire de traitement spécial sur les backslashes (typiquement les retirer sauf s'il y en a deux consécutifs) ou encore qu'il est toujours hasardeux d'utiliser une variable qui n'est pas entourée de double quote (dès qu'il y a des espaces par exemple).
Peut-être pensait-il également qu'il serait préférable d'utiliser printf à la place d'echo afin d'avoir un comportement uniforme sur les différents shell qui peuvent proposer un mode sh ? Lui seul le sait et c'est bien ça le problème me semble-t-il.
while read -r LINE; do MSG=$(printf '%sn' "$LINE" | grep -E -o ...) done
-- Benoit Izac
Nicolas George
Benoit Izac , dans le message , a écrit :
Je suppose que Nicolas faisait allusion au fait qu'il serait plus prudent d'utiliser l'option -r de read afin de ne pas faire de traitement spécial sur les backslashes (typiquement les retirer sauf s'il y en a deux consécutifs) ou encore qu'il est toujours hasardeux d'utiliser une variable qui n'est pas entourée de double quote (dès qu'il y a des espaces par exemple).
Peut-être pensait-il également qu'il serait préférable d'utiliser printf à la place d'echo afin d'avoir un comportement uniforme sur les différents shell qui peuvent proposer un mode sh ?
Je crois que tu n'as rien oublié.
Lui seul le sait et c'est bien ça le problème me semble-t-il.
Mon but n'était pas de faire un cours de shell, il y en a probablement plein le web. Mon but était de faire remarquer à certains interlocuteurs qu'ils auraient besoin de lire un cours de shell, au moins un abrégé sur les erreurs classiques et comment les éviter.
Benoit Izac , dans le message <878uei73zl.fsf@izac.org>, a écrit :
Je suppose que Nicolas faisait allusion au fait qu'il serait plus
prudent d'utiliser l'option -r de read afin de ne pas faire de
traitement spécial sur les backslashes (typiquement les retirer sauf
s'il y en a deux consécutifs) ou encore qu'il est toujours hasardeux
d'utiliser une variable qui n'est pas entourée de double quote (dès
qu'il y a des espaces par exemple).
Peut-être pensait-il également qu'il serait préférable d'utiliser printf
à la place d'echo afin d'avoir un comportement uniforme sur les
différents shell qui peuvent proposer un mode sh ?
Je crois que tu n'as rien oublié.
Lui seul le sait et
c'est bien ça le problème me semble-t-il.
Mon but n'était pas de faire un cours de shell, il y en a probablement plein
le web. Mon but était de faire remarquer à certains interlocuteurs qu'ils
auraient besoin de lire un cours de shell, au moins un abrégé sur les
erreurs classiques et comment les éviter.
Je suppose que Nicolas faisait allusion au fait qu'il serait plus prudent d'utiliser l'option -r de read afin de ne pas faire de traitement spécial sur les backslashes (typiquement les retirer sauf s'il y en a deux consécutifs) ou encore qu'il est toujours hasardeux d'utiliser une variable qui n'est pas entourée de double quote (dès qu'il y a des espaces par exemple).
Peut-être pensait-il également qu'il serait préférable d'utiliser printf à la place d'echo afin d'avoir un comportement uniforme sur les différents shell qui peuvent proposer un mode sh ?
Je crois que tu n'as rien oublié.
Lui seul le sait et c'est bien ça le problème me semble-t-il.
Mon but n'était pas de faire un cours de shell, il y en a probablement plein le web. Mon but était de faire remarquer à certains interlocuteurs qu'ils auraient besoin de lire un cours de shell, au moins un abrégé sur les erreurs classiques et comment les éviter.
Doug713705
Le 27-03-2015, Nicolas George nous expliquait dans fr.comp.os.unix (<5515ce73$0$3305$) :
Mon but n'était pas de faire un cours de shell, il y en a probablement plein le web. Mon but était de faire remarquer à certains interlocuteurs qu'ils auraient besoin de lire un cours de shell, au moins un abrégé sur les erreurs classiques et comment les éviter.
Le problème est que ta remarque, comme souvent, ne pointe aucun problème particulier. Elle suggère la présence d'une erreur mais ne donne aucune indication, pas même une pîste vers laquelle s'orienter.
Elle n'a donc aucun portée effective car tout le monde a plus ou moins besoin de (re)lire un cours de shell et ce n'est en rien une nouvelle.
C'est un peu comme répondre "Oui" à quelqu'un qui te demande l'heure ;-)
-- Mais l'ombre des plaisirs s'enfuit Toujours plus loin vers l'inconnu. -- H.F. Thiéfaine, La môme kaléïdoscope
Le 27-03-2015, Nicolas George nous expliquait dans
fr.comp.os.unix
(<5515ce73$0$3305$426a74cc@news.free.fr>) :
Mon but n'était pas de faire un cours de shell, il y en a probablement plein
le web. Mon but était de faire remarquer à certains interlocuteurs qu'ils
auraient besoin de lire un cours de shell, au moins un abrégé sur les
erreurs classiques et comment les éviter.
Le problème est que ta remarque, comme souvent, ne pointe aucun problème
particulier. Elle suggère la présence d'une erreur mais ne donne aucune
indication, pas même une pîste vers laquelle s'orienter.
Elle n'a donc aucun portée effective car tout le monde a plus ou moins
besoin de (re)lire un cours de shell et ce n'est en rien une nouvelle.
C'est un peu comme répondre "Oui" à quelqu'un qui te demande l'heure ;-)
--
Mais l'ombre des plaisirs s'enfuit
Toujours plus loin vers l'inconnu.
-- H.F. Thiéfaine, La môme kaléïdoscope
Le 27-03-2015, Nicolas George nous expliquait dans fr.comp.os.unix (<5515ce73$0$3305$) :
Mon but n'était pas de faire un cours de shell, il y en a probablement plein le web. Mon but était de faire remarquer à certains interlocuteurs qu'ils auraient besoin de lire un cours de shell, au moins un abrégé sur les erreurs classiques et comment les éviter.
Le problème est que ta remarque, comme souvent, ne pointe aucun problème particulier. Elle suggère la présence d'une erreur mais ne donne aucune indication, pas même une pîste vers laquelle s'orienter.
Elle n'a donc aucun portée effective car tout le monde a plus ou moins besoin de (re)lire un cours de shell et ce n'est en rien une nouvelle.
C'est un peu comme répondre "Oui" à quelqu'un qui te demande l'heure ;-)
-- Mais l'ombre des plaisirs s'enfuit Toujours plus loin vers l'inconnu. -- H.F. Thiéfaine, La môme kaléïdoscope
caterina123
Le mercredi 25 Mars 2015 Ã 10:37 par Kevin Denis :
