Newsgroup: it.comp.os.linux.sys
Titolo: Comando bash

Salve,
Chi mi sa' dire cosa c'e' che non va' in questo comando:
tail -f /var/log/debug | grep 'IPT' | awk '{print $1, $2, $3}'
Grazie

 tail -f /var/log/debug | grep 'IPT' | awk '{print $1, $2, $3}'
Il -f !!!
Non puoi metterlo in pipe con altri comandi in quel modo.
Caio.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.618 / Virus Database: 397 - Release Date: 09/03/2004

Anche questo lo e' ma funziona, perche'?
La differenza e che con questo non riesco a filtrare solo i msg che 
voglio io.
tail -f /var/log/debug | awk '{print $6,$10,$13,$14,$20,$21,$22}'
Davide D'Amico ha scritto:


 
Epperchenno? vuoi dire che ho guardato log nella maniera sbagliata per 4
anni? :-)
-- 
wash the blood from your hands
bury your secrets in the sand
and forget

 tail -f /var/log/debug | grep 'IPT' | awk '{print $1, $2, $3}'
Questo dovresti dircelo tu: cosa non va?
Comunque, una piccola ottimizzazione, forse potrebbe essere:
tail -f ... | gawk '/IPT/{print ...}'
bye,
-- 
   Piergiorgio Sartor

 anni? :-)
Non farci caso.....
Fa finta che non ho detto nulla!  ;-)


Semplicemente non visualizza niente, ma grazie alla tua ottimizzazione 
ho risolto il problema. La cosa che non capivo e che altre combinazioni, 
fino a due comandi funzionavano con il terzo no.
Piergiorgio Sartor ha scritto:



Ora non ho il tempo di approfondire ma il problema sembra effettivamente
legato al numero di pipe :
<USR>@<HOST> [<DIR>] [11:40:50]
#tail -f <FILE> | grep "0"| awk '{ print $1 }'
 NON VISUALIZZA NIENTE.
 
USR>@<HOST> [<DIR>] [11:41:08]
#tail -f <FILE> | awk '/0/{ print $1 }'
** 11/03/2004,11:41:12 [0] unsent_requests = [0]
** 11/03/2004,11:41:12 [0] unsent_responses = [0]
** 11/03/2004,11:41:12 [0] pending_commands = [0]
** 11/03/2004,11:41:12 [0] submit_init = [43]
** 11/03/2004,11:41:12 [0] submit_reject = [0]
Se qualcuno ha tempo e può fornire una spiegazione... ;)
 Dave
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Se qualcuno ha tempo e può fornire una spiegazione... ;)
nah...
mymachine:/var/log/mail/mta# tail -f postfix-log |grep Mar| awk \
'{ print $1" ciao "$2 }'| sed 's/M/D/'
Dar ciao 11
Dar ciao 11
Dar ciao 11
Dar ciao 11
Dar ciao 11
Dar ciao 11
Dar ciao 11
Dar ciao 11
Dar ciao 11
Dar ciao 11
Dar ciao 11
Dar ciao 11
Piuttosto, tocca aspettare un bel po' prima di avere output, perchè il
flusso "a singhiozzo" dato da quel tail -f penso provochi una sorta di
"effetto vagone ferroviario", in cui lo stream passa a scatti da una pipe
alla successiva.
Questo qui ha impiegato circa 30-40 sec. su un p3 500 con kernel 2.6.3,
mentre quel postfix-log logga circa 3.5 MB/h (quindi non è certo la
mancanza di righe in input...)
IMHO... se qualcuno che conosce meglio gli internals delle unnamed pipe
vuole intervenire e dire la sua...


 Questo qui ha impiegato circa 30-40 sec. su un p3 500 con kernel 2.6.3,
Uhmm ... deve essere qualcosa di diverso, ho aspetto ben piů di 30 sec ma
senza output, e la log ti assicuro che era stata scritta nel frattempo:
sdp@locas [/home/sdp] [12:11:35] << NOTA L'ORA
#ls -ltr log/mca/mcaSmpp_00_20040311.log
-rw-rw-r-- 1 sdp slbsema 550791 Mar 11 12:11 mcaSmpp_00_20040311.log
sdp@locas [/home/sdp] [12:11:38]
#tail -f log/mca/mcaSmpp_00_20040311.log | grep "0" | awk '{ print $0 }'
 Nessun output
sdp@locas [/home/sdp] [12:13:41]
#ls -l /home/sdp/log/mca/mcaSmpp_00_20040311.log
-rw-rw-r-- 1 sdp slbsema 561150 Mar 11 12:13
/home/sdp/log/mca/mcaSmpp_00_20040311.log
Ma come vedi ho aspettato quasi 2min e la log 'si č mossa' .
E lo "0" c'č praticamente sempre nelle righe della log
sdp@locas [/home/sdp] [12:16:32]
#head /home/sdp/log/mca/mcaSmpp_00_20040311.log
** 11/03/2004,10:20:40 [2] CShutdownTimer::Doing 'OnTimeout()'
** 11/03/2004,10:20:40 [2] Doing 'CSmppClient::newEvent (const int&, void*)'
** 11/03/2004,10:20:40 [2] Doing 'CSmppClient::reportSmppStatus ()'
** 11/03/2004,10:20:40 [2] Doing 'CSmppClient::GetState ()'
** 11/03/2004,10:20:40 [0] Doing 'CSmppClient::ReadConfiguration()'
 Any other idea? ...
 Davide



ALT mi auto-contraddico, ho lasciato il comando macinare per un po e dopo 5
minuti ha iniziato a farmi vedere qualche riga ... però, non male per un
bi-processore PA8700 con 4GB di memoria ... ;)
 Dave


 legato al numero di pipe :
Sulla mia Debian gia' con la prima pipe non mi visualizza nulla, sulle
redhat invece non ho questo problema.
Strano!


 un bi-processore PA8700 con 4GB di memoria ... ;)
immaginavo...
penso che il motivo sia che lo stream passa alla pipe successiva dopo aver
raggiunto una determinata dimensione del buffer, ma è una ipotesi...
Luca Polo, tu che già altri internals ci insegnasti, batti un colpo...
(anche tutti gli altri, eh..)


 Strano!
No non e' strano sulle redhat di default awk e' un link a gawk
Su Debian invece e' un link a mawk.
mawk evidentemente ha un bug che gawk non ha!
Controllate anche voi dov'e' linkato il vostro awk! Che versione avete?
Ciao.


 Ciao.
per dovere di cronaca:
  no link - awk 'standard' di HP-UX 11.00
Ciao,


 
Prova a guardare il man di awk e dicci che versione installa, se lo dice...
Hola..


   no link - awk 'standard' di HP-UX 11.00
E awk --version che dice?


 Hola..
Hasta la victoria !


Io su Slack 9.1 ho questa versione e non andava
GNU Awk 3.1.3
Copyright (C) 1989, 1991-2003 Free Software Foundation.

 proprio.
La differenza e' proprio quella.
Sarge:
andrea@vulcano:~$ ls -l /etc/alternatives/awk
lrwxrwxrwx    1 root     root           13 2003-12-20 13:22
/etc/alternatives/awk -> /usr/bin/gawk
Woody:
andrea@cerbero:~$ ls -l /etc/alternatives/awk
lrwxr-xr-x    1 root     root           13 set 24  2002
/etc/alternatives/awk -> /usr/bin/mawk
CYA
Banana

 tail -f /var/log/debug | grep 'IPT' | awk '{print $1, $2, $3}'
Sono un po' in ritardo, lo so... portate pazienza: ho troppo da fare in
questi giorni.
L'output di Unix puo' essere fatto bufferato o no. Quando viene fatto bufferato,
per vedere l'output uno deve aspettare che il buffer si riempia o che questo
venga *esplicitamente* svuotato (per esempio con fflush). L'output si buffera
per evitare di fare troppe chiamate di sistema nel caso di output "voluminosi".
I buffer vengono vuotati quando si supera una certa occupazione o quando il
file viene chiuso. Non e` una cache, attenzione: lo scopo non e` di fare da
tampone, ma piuttosto di ridurre il numero di chiamate di sistema. Lo svantaggio
di questo metodo e` che se il buffer non viene svuotato, l'output non si fa.
Questo metodo e` tipico di Unix ma anche di altri O.S., ad esempio VAX/VMS.
Ho dovuto lottare parecchio tempo fa per bypassare questo buffer nel caso di
emulazione terminale via RPC su canali dedicati.
Il behaviour di default per stdout e` bufferato. Per stderr invece e` il
contrario (stderr e` usato per messaggi di errore e quindi si accetta di
fare piu' chiamate di sistema ma di poter vedere immediatamente il risultato).
Per vedere un esempio della differenza che fa, scrivete un programmino in C
che fa dell'output su stdout intervallato con dell'output su stderr, dumpate
il tutto su un file e ... buona lettura!
Quello che non va nel comando e` che l'output di grep e` bufferato (non quello
di tail che deve essere fatto non bufferato per dare l'effetto voluto). Quindi
awk deve aspettare che il buffer si riempia prima di poter lavorare.
Questo spiega perche` tail -f | awk funga (tail non e` bufferato a causa del
"-f" e awk non e` bufferato - credo - perche` collegato al tty).
Conclusione: per il comando di cui sopra, verrai l'output solo quando il
/var/log/debug si riempie abbastanza da giustificare il flush del buffer di
output di grep.
Come esercizio, potresti provare a ridigirere i vari output da stdout a stderr.
Non so se/come funge ma si potrebbe provare...
Qualcuno sa come cambiare il behaviour di stdout da shell (stile O_ASYNC per
F_SETFL di fcntl, man fcntl per piu' informazioni). Potrei guardare sullo
Stevens ma al momento non posso... Questo metodo potrebbe risolvere il tuo
problema (e - se il tuo log si riempie in fretta - creartene un altro quando
Linux cerchera` di stare dietro alle chiamate di sistema...).
Ciao,
-- 
       Roberto Divia`             Love at first sight is one of the greatest
       =============             labour-saving devices the world has ever seen.
Mailbox: C02110                 CERN-European Organization for Nuclear Research
E-mail: 
Robert...@cern.ch
           CH-1211 GENEVE 23, Switzerland