Interpretation du "grep"
Bugs
-
Utilisateur anonyme -
Utilisateur anonyme -
Bonsoir,
Je souhaiterai que vous m'apportiez une explication détaillée d'une ligne en particulier d'un programme.
grep "$(dat_jour);.....;.......;sauve_ARC;Fin;0" $rapp_arc1>/dev/null 2>$1
Je ne comprend pas le raisonnement vous seriez aimable de m'expliquer
Merci
Je souhaiterai que vous m'apportiez une explication détaillée d'une ligne en particulier d'un programme.
grep "$(dat_jour);.....;.......;sauve_ARC;Fin;0" $rapp_arc1>/dev/null 2>$1
Je ne comprend pas le raisonnement vous seriez aimable de m'expliquer
Merci
A voir également:
- Interpretation du "grep"
- Find grep - Forum Shell
- Commande grep - Forum Linux / Unix
- Grep recursif - Forum Linux / Unix
- Commande grep ✓ - Forum Ubuntu
- Interprétation FRST ✓ - Forum Virus
5 réponses
la ou les chaînes du fichier dont le nom est dans la variable $rapp_arc1, contenant le résultat de la commande dat_jour suivi d'un point-virgule suivi de cinq caractères suivi d'un point-virgule suivi de 7 caractères suivi d'un point-virgule suivi de la chaîne sauve_ARC suivi d'un point-virgule suivi de la chaîne Fin suivi d'un point-virgule suivi d'un zéro, est ou sont envoyée(s) dans le vide cosmique, ainsi que la sortie d'erreur (vu qu'à la fin, je parie mon granola qu'il y a une typo et que c'est 2>&1 et pas 2>$1
bref, ça cherche un truc pour _strictement_ rien (sauf si tu récupère le status de sortie de grep pour faire autre chose mais dans ce cas, vaut mieux utiliser -q)
bref, ça cherche un truc pour _strictement_ rien (sauf si tu récupère le status de sortie de grep pour faire autre chose mais dans ce cas, vaut mieux utiliser -q)
grep c'est pour chercher de mots dans un fichier texte et ca fonctionne comme:
=> affiche toutes les lignes de "fichier" contenant le mot "toto".
Maintenant chez toi il y a quelques complications:
1) le ``mot'' a chercher est:
"$(dat_jour);.....;.......;sauve_ARC;Fin;0"
ici "dat_jour" est une variable dans le script et ca contient quelque chose, problement une chaine de texte pour la date, par exemple si ca contient un truc comme "1 Fev 2005" le $(dat_jour) sera remplace par ca.
2) le fichier dans lequel on cherche a un nom qui est dans une autre variable: "rapp_arc1" ou "rapp_arc" (il y a un blance avant le "1" ??).
Donc $rapp_arc1 (ou $rapp_arc) sera remplace par le nom du fichier.
3) A la fin il y a la redirection: >/dev/null 2>$1
ca veut dire que le resultat de l'affichage est redirige vers /dev/null, c.-a-d. la poubelle ou tout disparait et seulement les erreurs (le 2>... c'est la redirection des message d'erreurs) evuentelles sont rediriges vers un truc qui fait sens: vers la varible $1 (normalement le $1 est le 1er parametre dans l'appel du script, normalent a lire et pas a modifier).
Pour finir ca me semble pas de faire un sense serieux. Je soupconne que tu a oublies un guillement pour fermer le grep un peu avant ? Si oui ce serait:
Si c'est plutot ca, le grep s'arreterait plus tot et apres il y a un simplement l'enchainement d'autres commandes avec les ";" qui font encore autre chose. Mais ca ne fait pas de sens non-plus ?
grep toto fichier
=> affiche toutes les lignes de "fichier" contenant le mot "toto".
Maintenant chez toi il y a quelques complications:
1) le ``mot'' a chercher est:
"$(dat_jour);.....;.......;sauve_ARC;Fin;0"
ici "dat_jour" est une variable dans le script et ca contient quelque chose, problement une chaine de texte pour la date, par exemple si ca contient un truc comme "1 Fev 2005" le $(dat_jour) sera remplace par ca.
2) le fichier dans lequel on cherche a un nom qui est dans une autre variable: "rapp_arc1" ou "rapp_arc" (il y a un blance avant le "1" ??).
Donc $rapp_arc1 (ou $rapp_arc) sera remplace par le nom du fichier.
3) A la fin il y a la redirection: >/dev/null 2>$1
ca veut dire que le resultat de l'affichage est redirige vers /dev/null, c.-a-d. la poubelle ou tout disparait et seulement les erreurs (le 2>... c'est la redirection des message d'erreurs) evuentelles sont rediriges vers un truc qui fait sens: vers la varible $1 (normalement le $1 est le 1er parametre dans l'appel du script, normalent a lire et pas a modifier).
Pour finir ca me semble pas de faire un sense serieux. Je soupconne que tu a oublies un guillement pour fermer le grep un peu avant ? Si oui ce serait:
grep "$(dat_jour) blabla" ;.....;.......;sauve_ARC;Fin;0; $rapp_arc1>/dev/null 2>$1
Si c'est plutot ca, le grep s'arreterait plus tot et apres il y a un simplement l'enchainement d'autres commandes avec les ";" qui font encore autre chose. Mais ca ne fait pas de sens non-plus ?
Salut les gens :)
Si le $1 n'est pas une faute de frappe, et que la commande fait parti d'un script, c'est pour récupérer les erreurs éventuelle dans un fichier passé en parametre... pourquoi pas. mais bon, comme l'oeuf, je mets ma main a couper pour une faute de frappe, et dans ce cas, il ne vaut mieux pas chercher a comprendre le raisonnement :D
Si le $1 n'est pas une faute de frappe, et que la commande fait parti d'un script, c'est pour récupérer les erreurs éventuelle dans un fichier passé en parametre... pourquoi pas. mais bon, comme l'oeuf, je mets ma main a couper pour une faute de frappe, et dans ce cas, il ne vaut mieux pas chercher a comprendre le raisonnement :D
Si le $1 n'est pas une faute de frappe, et que la commande fait parti d'un script, c'est pour récupérer les erreurs éventuelle dans un fichier passé en parametre... pourquoi pas.
Tu as raison, c'est bien ca! Je ne l'avais pas vu.
Par contre je me demande comment le grep pourrait produire des messages d'erreurs utiles ? Soit il trouve ou soit il ne trouve pas mais dans les deux cas il ne sort rien en "stderr", au moins je ne le vois pas.
Tu as raison, c'est bien ca! Je ne l'avais pas vu.
Par contre je me demande comment le grep pourrait produire des messages d'erreurs utiles ? Soit il trouve ou soit il ne trouve pas mais dans les deux cas il ne sort rien en "stderr", au moins je ne le vois pas.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
c'est Hector...
éventuellement si la variable $rapp_arc n'est pas initialisée ou que son contenu ne correspond à aucun nom de fichier existant et accessible en lecture, ou si la commande dat_jour n'existe pas.
cela dit, chez moi, une variable $1 je ne sais pas l'initialiser, ça donner un truc genre
1=autre_chose
mon shell n'est pas content :)
éventuellement si la variable $rapp_arc n'est pas initialisée ou que son contenu ne correspond à aucun nom de fichier existant et accessible en lecture, ou si la commande dat_jour n'existe pas.
cela dit, chez moi, une variable $1 je ne sais pas l'initialiser, ça donner un truc genre
1=autre_chose
mon shell n'est pas content :)
oui mais y a pas que ça, elle est en lecture seule. Sans quoi, tu arriverais justement à des trucs du genre 1=2 à l'affectation de n'importe quoi.
au demeurant, on aurait pu imaginer pouvoir par exemple changer directement les variables des paramètres ou allonger $* ou incrémenter $#
ménon, on peut pas travailler directement dessus, et peut-être bien justement pour éviter les 1=2 (ou alors le contraire, un 1=2 fait gueuler le shell, donc le fabricant de shell en profite pour utiliser ces noms de variables à cet emploi :)
au demeurant, on aurait pu imaginer pouvoir par exemple changer directement les variables des paramètres ou allonger $* ou incrémenter $#
ménon, on peut pas travailler directement dessus, et peut-être bien justement pour éviter les 1=2 (ou alors le contraire, un 1=2 fait gueuler le shell, donc le fabricant de shell en profite pour utiliser ces noms de variables à cet emploi :)
Dans le truc ">$1" on ne modifie pas le $1 (c'est en effet constant) mais on modifie le fichier dont le nom et dans la variable $1. Donc le nom du fichier n'est pas modifiable mais le fichier lui meme oui. Donc tout est coherent.
Apres si on a un truc comme: "2>>1" ca ne modifie pas le $1 mais ca redirige le "stderr" (le tube "2") vers le "stdout" (le tube "1"). Ici les numeros 1 et 2 n'ont rien a avoir avec le $1 ou $2. C'est completement autre chose.
Apres si on a un truc comme: "2>>1" ca ne modifie pas le $1 mais ca redirige le "stderr" (le tube "2") vers le "stdout" (le tube "1"). Ici les numeros 1 et 2 n'ont rien a avoir avec le $1 ou $2. C'est completement autre chose.
merci à vous tous pour ces réponses effectivement cela fait partie d'un script et j'ai aussi fait une faute en recopiant. Je vous donne la partie du script qui m'intéresse:
rapp_arc=/home/tools/CPIO/logs/sv" `uname -n`".log
dat_jour=`date '+%d/%m/%y'`
ok=n
if [ `date '+ %a'`!= "Sat" -a `date '+ %a'`!= "Mon" ]
then
grep "$(dat_jour);.....;.......;sauve;Fin;" $rapp_arc1>/dev/null 2>$1
if [$? -eq 0 ]
then
grep "$(dat_jour);.....;.......;sauve;Fin;0" $rapp_arc1>/dev/null 2>$1
if [$? -eq 0 ]
then
grep "$(dat_jour);.....;.......;sauve;Fin;0" $rapp_arc1>/dev/null 2>$1
if [$? -eq 0 ]
then
ok=o
fi
fi
fi
C'est bien le traitement que tu veux faire ? (Dis nous ce que tu souhaite faire exactement stp)
Dans ce cas, bash ou autre on des test spécifiques pour tester l'existance d'un fichier... :)
++
Désolé, effectivement j'aurai du commencer par là.
Voilà mon système sous unix m'effectue une sauvegarde chaque jour.
le résultat de cette sauvegarde est placée dans un fichier sous le nom Sauvegarde_LUNDI.log, Sauvegarde_MARDI et ainsi de suite.
Le script que je voudrai lancer chaque jour, me sélectionnerai automatiquement le fichier log de la veille ( ex: le mardi matin, le fichier Sauvegarde_LUNDI et pour le Lundi, le fichier Sauvegarde_VENDREDI).
Ensuite engager la récupération de certaines données placées à l'intérieur du dit fichier afin de les placer dans un fichier "Result.txt qui m'est envoyé chaque jour par la messagerie (ex: après la mention "JOBID:" je voudrais récupérer le n° qui suit - Après la mention "début de sauvegarde" je voudrai récupérer la date et l'heure et de même pour la fin de sauvegarde).
Et là j'avoue que je patine dur, les embryons de programmes fournis me laissent dans une déroute complète.
Merci à vous pour toute votre aide
Bonne soirée
c'est fait pour ça