[bash] Barretta di avanzamento progressivo

[kanzy]

ciao a tutti!
Mi piacerebbe creare la classica barretta di avanzamento progressivo per l'output di alcuni semplici script, che prevedono un'attesa per completare le varie operazioni. Tanto per capirci: [============ ] o simile. Ho tentato con `seq', ma, a parte il fatto che non ho moltissima confidenza con la programmazione, non ho idea di come collegare l'avanzamento con il processo in corso. C'è qualche genietto che me lo può spiegare per piacere?.. o meglio indicarmi man, howto od esempi?.. Ho consultato i due principali manuali della bash, ma non ho trovato riferimenti al riguardo..

[submax82]

interesserebbe anche a me ma il problema è stimare quanto manca al processo per terminare o quanto ci mette in totale per calcolare l'avanzamento della barra

c'è questa già fatta

http://www.theiling.de/projects/bar.html

mi ero interessato per aggiungerla in kernelpkg, ma ora non ricordo per quale motivo ma non funzionava come credevo...

[_NYTRO_]

Bho, la butto così come m'è venuta in mente ora..

Se si tratta di brevi script di cui, bene o male, conosci il flusso puoi suddividerli in vari segmenti ad ognuno dei quali assegni un "peso"(1, 2 o 3 ecc) e dopo aver eseguito quel pezzo di codice "appendi" in output il numero di '=' o '*' relativo al peso assegnato..
E' moooolto empirica come cosa però, in teoria, dovrebbe funzionare.. Forse con qualche ulteriore dettaglio del job da tracciare è più facile studiare la soluzione..

PS: qualcuno in qualche post della settimana scorsa aveva inserito un pezzettino di script per creare una status-bar per i trasferimenti di file di grandi dimensioni. Se ritrovo il thread te lo linko..

[_NYTRO_]

Eccolo!

[submax82]

nessuno di queste barre può monitorare il pid di un processo perchè penso che non sia possibile farlo almeno non con una progess bar in quanto si dovrebbe fare ogni volta una stima sulla durata del processo

[kanzy]

@ Nytro

grazie mille per il link! dove ho trovato proprio quello che cercavo!

[kanzy]

@submax82

in effetti hai ragione.. ho provato lo script, ma va bene solo per copiare grossi files; se però devo effettuare una scansione del disco o un backup sono al punto di partenza..

[Mario Vanoni]

Ragionate un po`:

cpio -V stampa un punto (.) per ogni file copiato,
se dovesse calcolare una directory di 100GB,
quanto tempo in piu` ci impiega?
Poi per calcolare e stampare la percentuale attuale?

Un esempio che lo fa e` e2fsck con reboot cattivo.

UNIX/Linux/Slackware cercano sempre la via piu` corta,
altri quella (graficamente) piu` appariscente,
ad ognuno il suo gusto personale.

PS I codici sorgente cpio/e2fsck sono GPL!

[bit123]

Implementare una progressbar non è il problema più semplice del programmatore. Ho visto progressbar che prima avanzano spedite e poi si fermano o ritornano indietro per poi ripartire, e sto parlando di software blasonati. Come diceva NITRO, quando c'è una lista iterabile con un ciclo for, basta stampare un carattere 'X' alla fine di ogni ciclo. La situazione diventa più complicata se il processo non è iterabile. Per scrivere un grosso file, ad esempio, lo si potrebbe dividere in piccoli chunck utilizzando un buffer oppure un modo meno corretto ma più semplice potrebbe essere quello di eseguire un processo parallelo che vada a leggere il file temporaneo ogni tot msec.
Bisognerebbe vedere cosa fa il tuo programma. Saluti!

[kanzy]

@bit123
grazie per la risposta, che mi fa comprendere il problema nello specifico.
i miei due scriptini servono 1) ad effettuare la scansione del disco del server web con clamav; 2) ad effettuare il backup del volume dei dati. funzionalmente - ovviamente - non ho bisogno di nessuna barra di avanzamento, ma - come ho scritto nel post - 'mi piacerebbe'.. non avendo una conoscenza molto approfondita dello scripting, pensavo si potesse risolvere in modo generico (le barre di avanzamento pullulano ovunque, sin dagli albori di linux). purtroppo quando le cose non si sanno, si trattano con superficialità.. ma i forum servono a questo . grazie.

[submax82]

Come diceva NITRO, quando c'è una lista iterabile con un ciclo for, basta stampare un carattere 'X' alla fine di ogni ciclo.

non è così semplice perchè in questo modo la lunghezza della barra è variabile non essendo divisa in modo proporzionale alla durata del processo che viene monitorato

la cosa più semplice è non fare una barra ma una breve stringa di attesa tipo "..." che stampa uno, due, tre puntini e poi riparte o la barretta che ruota... non a caso in kernelpkg ho adottato questa soluzione.

[Blizzard]

ciao,
visto come un esercizio di programmazione è senz'altro ottimo.
Riguardo il suo utilizzo pratico sono dello stesso avviso di Mario. Le operazioni di output su schermo sono effettivamente pesanti, soprattutto se ripetute spesso oltre al fatto che il codice che deve calcolare i dati deve andare a pescarli dall'esecuzione di un altro processo.
Ponendo ad esempio il caso della copia di un grande file, il tutto è veloce proprio grazie al memory mapping che consente riduzioni delle operazioni di I/O su disco mappando il file in ram. Così facendo andreste ad aggiungere operazioni di I/O a video che IMHO pesano comunque.

a cosa più semplice è non fare una barra ma una breve stringa di attesa tipo "..." che stampa uno, due, tre puntini e poi riparte o la barretta che ruota... non a caso in kernelpkg ho adottato questa soluzione.

Tra le altre cose questa mi sembra un'ottima soluzione, anche se effettivamente non mostra l'attuale avanzamento dell'operazione ma solo la sua progressione.

ciao
Gio

[kanzy]

ma una breve stringa di attesa tipo "..." che stampa uno, due, tre puntini e poi riparte o la barretta che ruota...

..e come si fa?..

[sir_alex]

ciao,
visto come un esercizio di programmazione è senz'altro ottimo.
Riguardo il suo utilizzo pratico sono dello stesso avviso di Mario. Le operazioni di output su schermo sono effettivamente pesanti, soprattutto se ripetute spesso oltre al fatto che il codice che deve calcolare i dati deve andare a pescarli dall'esecuzione di un altro processo.
Ponendo ad esempio il caso della copia di un grande file, il tutto è veloce proprio grazie al memory mapping che consente riduzioni delle operazioni di I/O su disco mappando il file in ram. Così facendo andreste ad aggiungere operazioni di I/O a video che IMHO pesano comunque.

Bè, a parte la rara eventualità di copiare in un colpo solo 100 gb (salvo per un ripristino di sistema), sicuramente ci sarà meno overhead di una barra di progressione GUI (stile KDE o Gnome, per intenderci), tra l'altro anche l'overhead di queste ultime non è così incisivo... certo, se cercate le prestazioni ad ogni costo...

[Mario Vanoni]

Bè, a parte la rara eventualità di copiare in un colpo solo 100 gb (salvo per un ripristino di sistema), sicuramente ci sarà meno overhead di una barra di progressione GUI (stile KDE o Gnome, per intenderci), tra l'altro anche l'overhead di queste ultime non è così incisivo... certo, se cercate le prestazioni ad ogni costo...

Giudica la mia situazione,
main machine: 2 HD di 1TB, pieni di dati al 55% ed al 65%
backup machine idem, identica,
nastri di quelle dimensioni per backup sono impagabili.

Faccio un aggiornamento ogni 30 minuti con ssync(1) licenza GPL,
ed ho il suo file protocollo in /var/log/ssync/ssyncDD (giornaliero).
Usando il log-level meno ciarliero, impiega 2 minuti,
se non ci sono cambiamenti maggiori, altrimenti fino a venti minuti.

Visto che il codice sorgente (in C) e` disponibile,
fare una barretta di avanzamento non e` un problema,
fprintf(stderr ... per file 1 "-", file 2 "\", file 3 "|", file 4 "/" ecc. ecc.

Ma quanto tempo impiega poi il tty a portarlo sullo schermo?
In modo GUI probabilmente ancora di piu`!