grep dans un script ne fonctionne pas alors que fonctionne en ligne de commande

Bonjour,

J'aimerai comprendre pourquoi lorsque je fais cette commande, elle fonctionne correctement en ligne de commande

Code:

---

ps -e --format args | grep "export" >> toto.log

---

Mais lorsque je l'execute dans mon script cela ne fonctionne pas:

Code:

---

1 2 3 4 5

#!/bin/sh while true do ps -e --format args | grep "export" >> toto.log done

---

Merci par avance

Bonjour,

Qu'entends-tu par "Ça ne fonctionne pas" ? Tu n'as aucun résultat, ton fichier ne contient pas ce que tu veux, tu ne trouves pas ton fichier, ... ?

Salut, gs

Citation:

---

Envoyé par gangsoleil

Bonjour,

Qu'entends-tu par "Ça ne fonctionne pas" ? Tu n'as aucun résultat, ton fichier ne contient pas ce que tu veux, tu ne trouves pas ton fichier, ... ?

---

Tu as une icone sympatoche depuis quelque temps (merci à Anomaly ;)), pour te simplifier la vie : ": cristal :" et ça donne ça, sans les espaces :cristal:

A partir du script, ca enregistre grep export dans le fichier, et non le resultat de la commande, alors que la commande en ligne de commande fonctionne bien.

Citation:

---

Envoyé par yaume91

la commande en ligne de commande fonctionne bien.

---

parce qu'il y a quelque chose dans "args" que tu ne nous as pas montré, et qui n'est pas repris dans le script, à tous les coups, parce que chez moi, n'ayant pas ton "args", ça affiche "grep export" dans la console et dans le fichier.
man ps...

Est-ce que tu voulais écrire :

Code:

---

1 2	ps -e -o args | grep blabla >> fichier.txt

---

La commande que j'ai dans le script et que je tape en ligne de commande est exactement la meme:

Code:

---

ps -e --format args | grep "export" >> toto.log

---

avec la commande:

Code:

---

ps -e -o args | grep blabla >> fichier.txt

---

j'ai exactement le meme problème, ca me liste le process blabla en ligne de commande, et par le script ca m'ecrit dans le fichier fichier.txt "grep blabla"

Bon, j'ai suggéré man ps. L'as-tu fait ? Tu aurais pu y lire ça (extraits), où je mets des choses en gras pour bien les voir :

Citation:

---

Envoyé par man ps

--format format
user-defined format. Identical to -o and o.

o format
Specify user-defined format. Identical to -o and --format.

-o format
User-defined format. format is a single argument in the form of
a blank-separated or comma-separated list, which offers a way to
specify individual output columns. The recognized keywords are
described in the STANDARD FORMAT SPECIFIERS section below.
Headers may be renamed (ps -o pid,ruser=RealUser -o
comm=Command) as desired. If all column headers are empty (ps
-o pid= -o comm=) then the header line will not be output.
Column width will increase as needed for wide headers; this may
be used to widen up columns such as WCHAN (ps -o pid,wchan=WIDE-
WCHAN-COLUMN -o comm). Explicit width control (ps opid,
wchan:42,cmd) is offered too. The behavior of ps -o pid=X,
comm=Y varies with personality; output may be one column named
"X,comm=Y" or two columns named "X" and "Y". Use multiple -o
options when in doubt. Use the PS_FORMAT environment variable
to specify a default as desired; DefSysV and DefBSD are macros
that may be used to choose the default UNIX or BSD columns.

---

et ça

Citation:

---

Envoyé par man ps

STANDARD FORMAT SPECIFIERS
Here are the different keywords that may be used to control the output
format (e.g. with option -o) or to sort the selected processes with the
GNU-style --sort option.

For example: ps -eo pid,user,args --sort user

The following user-defined format specifiers may contain spaces:
args, cmd, comm, command, fname, ucmd, ucomm, lstart, bsdstart, start.

CODE HEADER DESCRIPTION

args COMMAND command with all its arguments as a string.
Modifications to the arguments may be shown. The
output in this column may contain spaces. A
process marked <defunct> is partly dead, waiting
to be fully destroyed by its parent. Sometimes
the process args will be unavailable; when this
happens, ps will instead print the executable
name in brackets. (alias cmd, command). See
also the comm format keyword, the -f option, and
the c option.
When specified last, this column will extend to
the edge of the display. If ps can not determine
display width, as when output is redirected
(piped) into a file or another command, the
output width is undefined (it may be 80,
unlimited, determined by the TERM variable, and
so on). The COLUMNS environment variable or
--cols option may be used to exactly determine
the width in this case. The w or -w option may
be also be used to adjust width.

---

In fine, tu vas taper echo $PS_FORMAT et nous dire ce que ça sort (chez moi, une ligne vide).

Juste pour information, peux-tu nous dire ce que tu obtiens lorsque tu tapes ces lignes en ligne de commande:

Code:

---

1 2 3 4

while true do ps -e --format args | grep "export" >> toto.log done

---

Et que donnent les scripts suivants:

Code:

---

1 2 3 4

#!/bin/sh while true; do { ps -e --format args } | grep "export" >> toto.log done

---

Code:

---

1 2 3 4

#!/bin/sh while true; do ( ps -e --format args ) | grep "export" >> toto.log done

---

Merci,
Le deuxieme script fonctionne.
Le premier met une erreur

Code:

---

test.sh: 4: test.sh: Syntax error: "done" unexpected (expecting "}")

---

Code:

---

1 2	echo $PS_FORMAT

---

me donne une ligne vide
Je ne vois pas ce que tu souhaites me montrer avec "man ps".

Citation:

---

Envoyé par yaume91

Le premier met une erreur

Code:

---

test.sh: 4: test.sh: Syntax error: "done" unexpected (expecting "}")

---

---

Laisse tomber ce script. Utilise l'autre.

Cependant, jack-ft t'avait demandé ce que ça donnait en ligne de commande (1^re étape), et tu as zappé...

Citation:

---

Envoyé par yaume91

Code:

---

1 2	echo $PS_FORMAT

---

me donne une ligne vide

---

Et le script fonctionne encore ? (car je suppose que tu as rebooté depuis hier ?)

Ah ben oui, il fonctionne :

Citation:

---

Envoyé par yaume91

Le deuxième script fonctionne.

---

mais on ne sait pas ce que ça sort, donc on ne sait pas si ça fonctionne bien ou n'importe comment...

Par exemple, chez moi aussi ça fonctionne, mais juste pour la bonne et simple raison que par le plus grand des hasards j'ai un fichier ouvert dont le titre comporte le mot "export" :

Citation:

---

leafpad /chemin/export4forum/output/résultats_090_400.txt
grep export
leafpad /chemin/export4forum/output/résultats_090_400.txt
grep export
leafpad /chemin/export4forum/output/résultats_090_400.txt
grep export

---

et comme ça jusqu'à saturation du disque...
C'est ça que tu espères avoir ?
Et si ce fichier était fermé, le fichier de log ne serait qu'une suite infinie de

Citation:

---

grep export

---

Ah ben oui, ça fonctionne, la machine n'est pas plantée...

Citation:

---

Envoyé par yaume91

Je ne vois pas ce que tu souhaites me montrer avec "man ps".

---

Citation:

---

Envoyé par Jipété

[...] où je mets des choses en gras pour bien les voir :

---

pour montrer l'utilité de PS_FORMAT ("ils ont des yeux mais ils ne voient pas"...)

Merci,

jack-ft, je ne sais pas comment on fait pour executer un script en ligne de commande, je sais juste mettre dans un fichier texte et faire un sh nomduscript.sh

en fait je m'en suis sorti.

Citation:

---

Par exemple, chez moi aussi ça fonctionne, mais juste pour la bonne et simple raison que par le plus grand des hasards j'ai un fichier ouvert dont le titre comporte le mot "export" :

---

En fait ca marchait, mais je cherchais un process qui s'execute que de temps en temps (toutes les 60 secondes pour etre precis).
Du coup je comprenais pas pourquoi ca me tracait dans le fichier "grep export", je m'attendais à ce que ca ne trace rien, vu qu'en tapant la ligne en ligne de commande je n'avais pas cette ligne d'affiché.

Citation:

---

Envoyé par yaume91

Je sais juste mettre dans un fichier texte et faire un sh nomduscript.sh

---

Quand tu dis "faire un sh nomduscript.sh", j'imagine que tu veux dire que tu tapes "sh nomduscript.sh" quelque part, et j'imagine que ce quelque part est un terminal linux. Non?

Citation:

---

Envoyé par yaume91

je ne sais pas comment on fait pour executer un script en ligne de commande

---

Tu fais pareil que pour "sh nomduscript.sh"!
Tu tapes (ou copies/colles) les lignes du script directement dans le terminal!
De la même manière qu'on ne va généralement pas faire un script pour faire un "ls" alors qu'on peut le taper directement dans le terminal ou pour un simple "ps -e --format args | grep "export"" une fois pour voir.

Rq: plutôt que "sh nomduscript.sh", habituellement, on fait plutôt "chmod +x nomduscript.sh" une fois dans le terminal pour rendre le script "normalement" exécutable à vie, puis on l'exécute "normalement" en tapant "./nomduscript.sh" dans le terminal (ce qui permet de l'appeler de la même manière depuis d'autres scripts).

Tiens, je profite que même si c'est résolu, c'est encore vivant : j'aimerais bien savoir à quoi sert "args" dans la mesure où, chez l'OP comme chez moi echo $PS_FORMAT renvoie une ligne vide, mais malgré ça, les sorties de ps -e --format args et ps -e ne sont pas identiques
:koi:
exemple avec --format args, les 13 dernières lignes :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

/usr/share/lazarus/1.4.0/lazarus --no-splash-screen --started-by-startlazarus -- /usr/lib/dconf/dconf-service [kworker/1:1] /usr/bin/gdb -silent -i mi -nx [lhelp] <defunct> gksu /usr/bin/x-terminal-emulator /usr/bin/x-terminal-emulator gnome-pty-helper /bin/bash [kworker/1:0] [kworker/0:1] [kworker/0:0] ps -e --format args

---

et sans :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

5155 ? 00:02:00 lazarus 5252 ? 00:00:00 dconf-service 5446 ? 00:00:02 kworker/1:1 5537 ? 00:00:03 gdb 5744 ? 00:00:00 lhelp <defunct> 6008 ? 00:00:00 gksu 6009 ? 00:00:00 x-terminal-emul 6010 ? 00:00:00 gnome-pty-helpe 6019 pts/2 00:00:00 bash 6028 ? 00:00:00 kworker/1:0 6029 ? 00:00:00 kworker/0:1 6033 ? 00:00:00 kworker/0:0 6035 pts/2 00:00:00 ps

---

Merci,

Salut,
Apparemment, args est un argument prédéfini dans ps.
Dans le man de ps

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

INDICATEURS DE FORMAT STANDARDS . . . CODE EN-TÊTE DESCRIPTION   args COMMAND Commande avec tous ses arguments sous forme de chaîne. Les modifications aux arguments peuvent être montrées. Les éléments de cette colonne peuvent contenir des espaces. Un processus marqué <defunct> est partiellement tué. La valeur args est parfois indisponible pour le processus, dans ce cas, ps affichera à la place le nom de l'exécutable entre crochets (alias cmd, command). Consultez aussi le mot-clé de format comm et les options -f et c. Lorsque indiquée en dernier, cette colonne sera élargie jusqu'aux bords de l'affichage. Si ps ne peut pas déterminer la largeur de l'affichage, comme quand la sortie est renvoyée (dans un tube, « pipe ») vers un fichier ou une autre commande, la largeur de sortie n'est pas définie (elle peut être de 80 caractères, illimitée, déterminée par la variable TERM, etc.) La variable d'environnement COLUMNS ou l'option --cols permettent de déterminer avec exactitude la largeur dans ce cas. Les options w ou -w peuvent également être utilisées pour adapter la largeur.

---

On obtient un affichage sur une seule colonne avec l'entête COMMAND

Cordialement.

Citation:

---

Envoyé par ctac_

Salut,
Apparemment, args est un argument prédéfini dans ps.

Cordialement.

---

Ouais, merci, mais même en français cette aide est du charabia pour moi : ils auraient mieux fait de montrer un exemple et le résultat de la commande...

c'est simplement la commande avec ses arguments.

Sur un "ls -lart /tmp" :
ps -e -o comm --> affiche "ls"
ps -e -o args --> affiche "ls -lart /tmp"

Citation:

---

Envoyé par gangsoleil

c'est simplement la commande avec ses arguments.

---

Bonjour, et grand merci à toi de me prendre par la main pour m'aider à traverser la rue, mais je ne dois pas être bien réveillé ce matin (ou alors c'est l'âge...) car

Citation:

---

Envoyé par gangsoleil

Sur un "ls -lart /tmp" :
ps -e -o comm --> affiche "ls"
ps -e -o args --> affiche "ls -lart /tmp"

---

je ne vois absolument pas le rapport, le lien, entre ta commande ls ou n'importe quelle autre et les sorties de ps.
Dit autrement, je ne vois pas comment ls -options peut "se retrouver" dans -o comm ou -o args.
En tout état de cause, quand je saisis ton ls -options je vois bien s'afficher ce qui doit s'afficher, ensuite, que je saisisse l'une ou l'autre ligne de ps, je ne vois jamais la string ls avec ou sans suite.
Normal, la commande est terminée.

Ou alors il faut mettre ce ls -options dans une boucle ?
J'ai donc tenté ça, dans une console :

Code:

---

1 2 3 4

while true do ls -lart /tmp done

---

pendant que dans une autre je saisissais ps -e -o args qui m'a entre autres retourné ls --color=auto -lart /tmp, pas mal puisqu'il y a même l'alias (alias ls='ls $LS_OPTIONS' inclut des couleurs) !
Par contre ps -e -o comm ne m'a pas enthousiasmé :

Code:

---

1 2 3 4

COMMAND plein de lignes de process ... ps

---

mais pas de ls...
Et echo $COMMAND renvoie une ligne vide.

Citation:

---

Envoyé par Jipété

je ne vois jamais la string ls avec ou sans suite.
Normal, la commande est terminée.

Ou alors il faut mettre ce ls -options dans une boucle ?

---

Non, non, car tu risques de passer entre les gouttes!

Pour éviter que la commande "ls" ne termine avant de lancer "ps", j'en prends une longue et je la perluettise (en tâche de fond, background):

Code:

---

1 2 3 4 5 6 7 8

$ ls -R / > /dev/null 2>&1 & [1] 20131   $ ps -e -o comm | egrep '^ls' ls   $ ps -e -o args | egrep '^ls' ls -AF -R /

---

Tiens! Mon "ls" aussi est aliasé!

Une manière plus radicale, c'est de "stopper" le processus, en lui envoyant un SIGSTOP grâce à Ctrl-Z:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

$ ls -R / > /dev/null 2>&1 ^Z [1]+ Stopped ls -AF -R / > /dev/null 2>&1   $ jobs [1]+ Stopped ls -AF -R / > /dev/null 2>&1   $ ps -e -o comm | egrep '^ls' ls   $ ps -e -o args | egrep '^ls' ls -AF -R /   $ kill % [1]+ Terminated: 15 ls -AF -R / > /dev/null 2>&1

---

Bref, ça marche aussi sous macos :)

Citation:

---

Envoyé par jack-ft

Non, non, car tu risques de passer entre les gouttes!

---

:mouarf:

Citation:

---

Envoyé par jack-ft

Pour éviter que la commande "ls" ne termine avant de lancer "ps", j'en prends une longue et je la perluettise (en tâche de fond, background):

---

Bien vu l'exemple ! :ccool: :plusser:

Merci à tous,