path: root/src/corsi/2014-linea_di_comando/log-lezione_4-raw.log

21:01 <@valhalla> Direi che si pu`o iniziare
21:02 <@valhalla> Innanzitutto, domande sulla lezione scorsa? (fatele pure come al solito su #lifo-domande )
21:02 <@valhalla> Nel frattempo, come al solito andate con cd sulla directory dove avete il resto del materiale
21:02 <@valhalla> ls e pwd per controllare di essere nel posto giusto
21:02 <@valhalla> e poi wget http://www.lifolab.org/corsi/2014-linea_di_comando/riga_di_comando-lezione_4.tar.xz
21:02 <@valhalla> tar -x -v -f riga_di_comando-lezione_4.tar.xz
21:03 <@valhalla> per scaricare e scompattare il materiale di stasera
21:03 -!- JulesX [~lorenzo@adsl-ull-93-115.51-151.net24.it] has joined #lifo
21:03 -!- tiziano [~tiziano@host6-191-dynamic.24-79-r.retail.telecomitalia.it] has joined #lifo
21:04 <@valhalla> nessuna domanda sulla volta scorsa? scaricato il materiale?
21:05 <@valhalla> per chi è arrivato in ritardo: wget 
21:05 <@valhalla> http://www.lifolab.org/corsi/2014-linea_di_comando/riga_di_comando-lezione_4.tar.xz
21:05 <@valhalla> Questa sera non parleremo quasi per niente di programmi, ma di feature della shell
21:06 <@valhalla> in particolare, credo di aver accennato nella prima lezione al fatto che la shell è un interprete per un vero e proprio linguaggio di programmazione
21:07 <@valhalla> non entreremo nei dettagli della cosa, perché se non si sa programmare richiederebbe tutto un corso
21:07 <@valhalla> ma ci sono un paio di caratteristiche utili un po' per tutti
21:07 -!- erossi [~enrico@tecnobrain.com] has joined #lifo
21:08 <@valhalla> iniziamo con le variabili: semplificando un po' possiamo dire che le variabili sono una scatola con etichetta
21:08 <@valhalla> nelle quali si possono inserire dati, richiamandoli per tramite l'etichetta
21:09 <@valhalla> in bash si assegna un valore ad una variabile con nomevariabile=contenuti
21:09 <@valhalla> ad esempio ``PERSONAGGIO="pippo"``
21:09 <@valhalla> importante: in questo caso non ci vogliono spazi
21:10 <@valhalla> e le " vengono interpretate dalla shell prima di assegnare il valore alla variabile
21:10 <@valhalla> con il comando ``echo`` possiamo far stampare cose a schermo
21:10 <@valhalla> ad esempio ``echo pincopallino`` stamperà pincopallino
21:11 <@valhalla> se scriviamo ``echo $PERSONAGGIO`` bash sostituirà il valore di PERSONAGGIO per passarlo ad echo
21:11 <@valhalla> che quindi stamperà pippo
21:12 <@valhalla> il carattere $ viene usato prima del nome quando ci si riferisce alla variabile e se ne vuole il valore
21:12 <@valhalla> altra cosa, se si mette una variabile tra "" avviene la sostituzione, se lo si mette tra '' no
21:13 <@valhalla> ad esempio, provate a vedere la differenza tra ``echo '$PERSONAGGIO'`` e ``echo "$PERSONAGGIO"``
21:13 <@valhalla> domande?
21:13 <@diego71> < polva> le variabili vanno sempre messe upcase?
21:13 <@valhalla> ottima domanda: no, le variabili possono essere minuscole, maiuscole o qualsiasi loro combinazione
21:14 <@valhalla> ma c'è l'abitudine di usare tutte lettere maiuscole per le variabili, in modo da riconoscerle facilmente quando si legge
21:14 <@valhalla> soprattutto se si sta scrivendo uno script, ma anche se si sta scrivendo della documentazione
21:14 <@valhalla> nella quale è facile trovare delle variabili usate a mo' di segnaposto
21:14 <@valhalla> tipo ``cd $DIRECOTORY_DOVE_AVETE_IL_MATERIALE``
21:15 <@valhalla> altre domande?
21:15 <@diego71> < JulesX> ha messo un apice singolo sul primo dei due echo appena messi
21:16 <@valhalla> dici ``echo '$PERSONAGGIO'``? sì, è per far vedere il caso in cui non funziona, da confrontare con quello con gli apici doppi
21:16 <@valhalla> altre domande?
21:16 <@diego71> < erio_> ho fatto la prova ma il risultato è sempre Pippo
21:17 <@valhalla> la prova con "" o ''? no, nel primo caso dovrebbe scrivere ``pippo``, nel secondo dovrebbe scrivere ``$PERSONAGGIO``
21:18 <@valhalla> altre domande?
21:18 <@diego71> < polva> è indifferente quindi fare echo "$PERSONAGGIO" e echo $PERSONAGGIO?
21:19 <@valhalla> se si sta usando il comando echo sì
21:19 -!- giocat [~giocat@host83-69-dynamic.58-82-r.retail.telecomitalia.it] has joined #lifo
21:19 <@valhalla> la differenza è nel modo in cui vengono gestiti gli spazi e simili all'interno della variabile
21:19 <@valhalla> ad esempio, se si ha ``CON_SPAZIO="uno due"``
21:20 <@valhalla> (creiamo una directory esempi, con ``mkdir esempi`` ed entriamoci con ``cd esempi`` prima del prossimo comando
21:21 <@valhalla> touch $CON_SPAZIO creerà due file, che si chiamano uno e due
21:21 <@valhalla> ``touch "$CON_SPAZIO"`` invece crea un file solo, con lo spazio nel nome
21:21 <@valhalla> questa è una fonte di millemila bug quando si scrivono script
21:21 <@valhalla> altre domande?
21:22 <@diego71> < rasalgethi> si può spiegare meglio la storia dei segnaposto?
21:22 <@valhalla> capita che nella documentazione (ad esempio su pagine internet ecc.) si trovino scritte delle variabile con un nome "intuitivo"
21:23 <@valhalla> in quel caso, non ci si aspetta veramente di definire una variabile con quel nome, ma che il lettore della documentazione faccia direttamente la sostituzione
21:24 <@valhalla> tipo appunto se si trova scritto di fare ``cd $DIRECTORY_CON_IL_MATERIALE`` non mi aspetto che qualcuno definisca la variabile DIRECTORY_CON_IL_MATERIALE, ma che scriva in bash direttamente l'indirizzo corretto della directory
21:24 <@valhalla> altre domande?
21:24 <@diego71> no
21:24 <@valhalla> ok
21:25 <@valhalla> le variabili sono definite all'interno della sessione di shell 
21:25 <@valhalla> ad esempio, se si hanno aperti due terminali e si definisce una variabile in uno dei due, non la si trova poi nell'altro
21:26 <@valhalla> non vengono neanche passate ad eventuali altre shell aperte nello stesso terminale
21:26 <@valhalla> ad esempio, se si lancia di nuovo ``bash`` 
21:26 <@valhalla> non siamo più nella shell di prima, e ``echo $PERSONAGGIO`` non stamperà niente
21:26 <@valhalla> poi possiamo dare ``exit`` per tornare alla nostra bash iniziale
21:27 <@valhalla> per passare le variabili ad una shell "figlia" si pu`o usare il comando export
21:27 <@valhalla> con ``export PERSONAGGIO`` se si lancia una nuova shell questa avrà il valore impostato
21:27 <@valhalla> ad esempio potete dare di nuovo ``bash`` e poi ``echo $PERSONAGGIO`` per verificare che ha cambiato comportamento
21:28 <@valhalla> (e poi di nuovo ``exit`` per uscirne
21:28 <@valhalla> altre domande?
21:28 <@diego71> < erio_> come mai non riesco a cancellare i file appena creati ? (uno due)
21:28 <@valhalla> dato che il file ha uno spazio nel nome, bisogna "proteggere" lo spazio in modo che venga passato a rm e non interpretato dalla shell
21:29 <@valhalla> il modo più semplice è usare tab, che riempie già i nomi dei file proteggendoli nel modo corretto 
21:29 <@valhalla> quindi ``rm un[tab]``
21:29 <@valhalla> (altrimenti, si possono usare opportune "" attorno)
21:29 <@valhalla> altre domande?
21:30 -!- albertux [~Icedove@dynamic-adsl-78-14-228-201.clienti.tiscali.it] has joined #lifo
21:30 <@diego71> < tiziano> export PERSONAGGIO funziona, mentre export $PERSONAGGIO non funziona, perche?
21:30 <@valhalla> perché in bash NOME si riferisce alla variabile, mentre $NOME si riferisce ai contenuti della variabile
21:31 <@valhalla> tra l'altro, scrivendo ``export $PERSONAGGIO`` al comando export arriva ``export pippo``
21:31 <@valhalla> e quindi cerca di esportare una variabile di nome pippo
21:31 <@valhalla> altre domande?
21:31 <@valhalla> ci sono alcune variabili "predefinite" con un significato specifico
21:32 <@valhalla> in particolare $? contiene sempre il valore di ritorno dell'ultimo comando
21:32 <@valhalla> ovvero
21:32 <@valhalla> quando un programma ha finito di girare, sotto unix questo passa al sistema un numero che indica se il programma ha funzionato o se ci sono stati errori
21:33 <@valhalla> se tutto è andato bene questo valore sarà 0
21:33 <@valhalla> in caso contrario, potrebbe essere 1 (errore generico) o un altro numero da 2 a 127 (di solito)
21:34 <@valhalla> alcuni programmi definiscono un significato specifico a quei numeri, altri usano delle convenzioni comuni un po' a tutti
21:34 <@valhalla> ma alla fin fine di solito la distinzione importante è tra 0 e tuttoilresto
21:35 <@valhalla> (dato che per distinguere tra gli altri casi ci si aspetta ci siano dei messaggi di errore)
21:35 <@valhalla> ad esempio, ``cd ..`` per tornare nella directory di prima
21:35 <@valhalla> e poi ``cat dispensa.rst`` e subito dopo ``echo $?``
21:35 -!- albertux [~Icedove@dynamic-adsl-78-14-228-201.clienti.tiscali.it] has quit [Quit: Alla prossima...]
21:35 <@valhalla> stamperà 0, per dire che cat ha funzionato
21:36 <@valhalla> mentre ``cat sdgfsdf`` e subito dopo ``echo $?`` 
21:36 <@valhalla> stampa 1, per dire "c'è stato un errore, cat non ha funzionato come doveva
21:36 <@valhalla> domande?
21:38 <@valhalla> questo fatto di avere un modo veloce per sapere se un programma ha funzionato o meno è molto utile quando si scrivono script
21:38 <@valhalla> ma si usa anche sulla riga di comando interattiva
21:39 <@valhalla> in generale, il valore 0 è considerato equivalente al valore logico "vero", mentre tutti gli altri numeri sono considerati col valore logico "falso"
21:39 <@valhalla> questo è il contrario di quel che fanno tutti gli altri linguaggi di programmazione
21:39 <@valhalla> ma serve perché la si può considerare risposta alla domanda "il programma ha girato giusto?"
21:40 <@valhalla> a quel punto si possono fare operazioni logiche su questi valori
21:40 <@valhalla> ad esempio, dando due comandi di seguito con ``&&`` in mezzo si ottiene la risposta alla domanda "entrambi i programmi hanno girato?"
21:41 <@valhalla> ad esempio ``cat dispensa.rst && cat ssdfdsf``
21:41 <@valhalla> darà 1, ovvero falso, perché il secondo programma ha dato errore
21:41 <@valhalla> la cosa utile, è che per calcolare questo AND logico, viene eseguito solo il minimo indispensabile
21:42 <@valhalla> ovvero: dato che se il primo comando fallisce, la risposta è falso, se il primo comando fallisce, il secondo non viene eseguito
21:42 <@valhalla> ad esempio ``cat sdefsfs && cat dispensa.rst``
21:42 <@valhalla> vedrete che il contenuto di dispensa.rst non viene mai stampato
21:42 <@valhalla> questo è molto utile quando si vogliono dare comandi, andando avanti solo se il primo ha avuto successo
21:43 <@valhalla> un esempio tipico è per compilare programmi da sorgente: ``./configure && make``: se la configurazione fallisce, non si prova neanche a compilare
21:43 -!- lucmon71 [~luca@net-93-71-184-195.cust.vodafonedsl.it] has joined #lifo
21:43 <@valhalla> domande fin qui?
21:44 <@valhalla> ok, come chiesto da tiziano, e se invece si vuole lanciare un comando solo se il primo è fallito? c'è l'operazione logica OR
21:45 <@valhalla> ovvero la risposta alla domanda "almeno uno dei due programmi ha funzionato?"
21:45 <@valhalla> ad esempio ``cat dispensa.rst || cat sdsfdsf``
21:45 <@valhalla> darà come valore di ritorno 0
21:46 <@valhalla> e notate che dato che il primo comando ha funzionato, il secondo non viene eseguito, perché comunque sarebbe inutile per il calcolo del valore di ritorno finale
21:46 <@valhalla> al contrario, ``cat sddgsg || cat dispensa.rst`` eseguirà entrambi, dato che il primo ha fallito
21:47 <@valhalla> già che siamo sull'argomento, se invece si vogliono semplicemente concatenare due comandi si pu`o usare ``;``, in questo caso vengono eseguiti sempre comunque entrambi, e il valore di ritorno è quello dell'ultimo comando dato
21:47 <@valhalla> domande?
21:47 <@diego71> < JulesX> tutto questo vale anche negli script  bash immagino
21:47 <@valhalla> sì
21:48 <@valhalla> la maggior parte delle cose che si usano nella shell interattiva funziona anche negli script e viceversa, con poche eccezioni
21:48 <@valhalla> altre domande?
21:48 <@diego71> < aldagaau> perché a me stampa "0: comando non trovato" ? Contiene entrambe le risposte, sia quella valida che quella falsa? (cat  asdfg)
21:48 <@valhalla> probabilmente anziché scrivere ``echo $?`` hai scritto ``$?`` e basta
21:49 <@valhalla> in questo caso bash sostituisce il valore di $? e lo prende come se sulla riga di comando tu avessi scritto ``0↵``
21:49 <@valhalla> altre domande?
21:49 <@diego71> < erio_> dare due comandi in linea senza ; funziona lo stesso vero ?
21:50 <@valhalla> no, se si mette un secondo comando senza ; bash non sa che quello è un secondo comando, e lo passa al primo comando come se fosse un opzione
21:50 <@valhalla> ad esempio ``cat dispensa.rst cat cheat_file.txt`` risalendo un po' si vede l'errore ``cat: cat: No such file or directory``
21:51 <@valhalla> perché il primo cat ha cercato di aprire i file dispensa.rst, un file chiamato ``cat`` e poi cheat_file.txt
21:51 <@valhalla> altre domande?
21:51 <@diego71> no
21:52 <@valhalla> ok, c'era una domanda sulle variabili arrivata quando già parlavamo di valori di uscita
21:52 <@diego71> < polva> scusate mi ero assentato. quindi in pratica "$VARIABILE" tratta il suo valore come stringa di caratteri, mentre $VARIABILE  ne estrae il contenuto che viene letto sintatticamente dal programma?
21:53 <@valhalla> no, $VARIABILE estrae sempre il contenuto di VARIABILE
21:53 <@valhalla> a quel punto, se ci sono le "" il tutto viene passato come parametro unico al comando
21:53 <@valhalla> se invece non ci sono, e $VARIABILE contiene degli spazi, i contenuti vengono separati lungo gli spazi e passati come parametri distinti
21:53 <@valhalla> altre domande?
21:54 <@diego71> < erio_> ho dato cat sddsfh cat dispensa.rst e mi ha dato il messaggio di errore e poi ha eseguito il cat corretto...probabilmente  perchè il primo comando non era valido...
21:54 <@valhalla> no, in quel caso c'è un unico cat che da messaggio di errore sui due file ``sddsfh`` e ``cat``, e poi lavora correttamente su ``dispensa.rst``
21:54 -!- malo [~malo@217.203.155.175] has quit [Quit: Sto andando via]
21:55 <@valhalla> altre domande?
21:55 <@diego71> sembra di no
21:57 <@diego71> < aldagaau> per favore puoi fare un esempio con e senza "" ?
21:57 <@diego71> < aldagaau> ho dato uno="UNO" e due "DUE" poi richiamati con "$uno" e $uno e da sempre UNO
21:58 <@valhalla> allora, nella prima parte le "" servono per far prendere alla variabile eventuali spazi
21:58 <@valhalla> ad esempio, se scrivete ``UNO=uno due`` vi darà errore perché prende il due come se fosse un comando, e non parte del valore da assegnare ad UNO
21:59 <@valhalla> se invece si scrive ``UNO="uno due"`` la variabile UNO conterrà la stringa ``uno due``, con lo spazio in mezzo
22:00 <@valhalla> anche nella seconda parte si nota la differenza se ci sono degli spazi
22:00 <@valhalla> DUE="tre quattro"
22:00 <@valhalla> (e ``cd esempi``)
22:01 <@valhalla> anzi, meglio ancora ``DUE="tre        quattro"``
22:01 <@valhalla> con tanti spazi in mezzo
22:01 <@valhalla> a quel punto ``echo $DUE`` stamperà ``tre quattro``, con un solo spazio
22:02 <@valhalla> perché echo ha ricevuto due parametri, ``tre`` e ``quattro`` e li stampa uno dopo l'altro separati da uno spazio
22:02 -!- mediechions1 [~mediechio@2-234-206-242.ip224.fastwebnet.it] has quit [Quit: Ex-Chat]
22:02 <@valhalla> invece ``echo $DUE`` stampa ``tre        quattro``, perché echo ha ricevuto un solo parametro, ``tre        quattro`` con tutta la sfilza di spazi in mezzo
22:02 <@valhalla> altre domande?
22:03 <@diego71> sembra di no
22:04 <@valhalla> ehm, sì, nell'ultima riga ``echo "$DUE"``, grazie
22:04 <@diego71> < aldagaau> sempre io a rompere: ci applichi questa cosa nella vita di shell di tutti i giorni?
22:05 <@valhalla> un grosso uso delle variabili è negli script, ma le variabili vengono anche usate nella shell interattiva
22:05 <@valhalla> perché possono essere usate per la configurazione di programmi
22:06 -!- tullio_ [~tullio@217.200.185.208] has quit [Read error: Connection timed out]
22:06 <@valhalla> ovvero, in una shell ci sono solitamente impostate varie variabili, e i programmi possono leggerne i valori, e comportarsi in modo diverso 
22:06 <@valhalla> ad esempio, col comando ``env`` si stampano i valori delle variabili definite nella shell corrente
22:06 -!- tullio_ [~tullio@217.200.185.208] has joined #lifo
22:07 <@valhalla> ci sono cose come LANG che ad esempio servono per sapere che localizzazione del programma usare
22:08 <@valhalla> se si ha il sistema in inglese e si vuole lanciare un programma in italiano, ad esempio, si pu`o usare ``export LANG=it_IT.utf8`` e poi lanciare i programmi, che a quel punto saranno in italiano (se l'italiano è installato sul sitema)
22:09 <@diego71> polva: la differenza e' questa. Nel primo caso esegue 'echo tre     quattro', nel secondo 'echo "tre    quattro"'
22:09 <@valhalla> oppure usare ``LANG=it_IT.utf8 $NOMEPROGRAMMA`` e a quel punto *solo* quel programma avrà accesso a quel valore della variabile, e girerà in italiano, mentre i successivi continuano a partire in inglese
22:10 -!- dimaz [~dimaz@host65-45-dynamic.9-79-r.retail.telecomitalia.it] has joined #lifo
22:11 <@valhalla> altro esempio, ci sono dei programmi che lanciano un editor esterno per modiifcare i file, questi prenderanno il valore della variabile $EDITOR per scegliere cosa lanciare
22:11 <@valhalla> altre domande?
22:13 <@valhalla> mi segnalano dalla regia un'altra variabile usata nella vita di tutti i giorni: TZ
22:13 <@valhalla> che pu`o essere usata per far credere ad un programam di dover usare una timezone diversa da quella di default
22:14 <@valhalla> ad esempio ``date`` e ``TZ=UTC date``
22:14 <@valhalla> altre domande?
22:15 <@diego71> < gioque> ok grazie :-) allora una più semplice non ho ben capito come mail se fai `LANG=it_IT.utf8 $NOMEPROGRAMMA` ti lancia solo un  programma in italiano perchè c'è lo spazio cioè la variabile viene assegnata a quel solo programma o ??
22:15 <@valhalla> la variabile ha quel valore solo per quel programma perché è stata assegnata sulla stessa riga 
22:16 <@valhalla> e quindi anziché assegnarle il valore per la shell corrente bash lo assegna solo nell'ambiente che passa a $NOMEPROGRAMMA
22:16 <@valhalla> altre domande?
22:16 -!- MrPan [~marcopani@gateway/tor-sasl/mrpan] has quit [Ping timeout: 240 seconds]
22:16 <@diego71> < JulesX> EDITOR E TZ sono variabili della vostra distro immagino io non ce le ho
22:17 <@valhalla> non proprio: sono variabili usate dai programmi in tutte le distro, ma di default non hanno un valore
22:17 <@valhalla> se non c'è un valore, c'è un editor o una timezone di default per tutto il sistema che viene usata
22:17 <@valhalla> se le si imposta, vale il valore che si è impostato
22:18 <@valhalla> ad esempio io condivido il computer con un utente di un altro editor, e quindi imposto EDITOR=vim per non dover usare quell\altro editor :)
22:19 <@valhalla> approposito: questo tipo di variabili viene impostato spesso in file come ``~/.bashrc`` che vengono letti da tutte le shell all'avvio
22:19 <@valhalla> (tutte le istanze di bash, non tutte le shell nel senso di bash, sh, zsh ecc)
22:19 <@valhalla> altre domande?
22:20 -!- dimaz [~dimaz@host65-45-dynamic.9-79-r.retail.telecomitalia.it] has quit [Quit: Sto andando via]
22:20 <@diego71> < tiziano> obiezione::-D $ TZ=UTC date;date
22:20 <@diego71> < tiziano> mar 11 feb 2014, 21.15.42, UTC
22:21 <@diego71> < tiziano> mar 11 feb 2014, 22.15.42, CET
22:21 -!- MrPan [~marcopani@gateway/tor-sasl/mrpan] has joined #lifo
22:21 <@valhalla> ottima osservazione: il ``;`` finisce il primo comando e ne inizia un secondo, mentre la variabile viene assegnata solo per il primo
22:22 <@valhalla> altre domande?
22:23 <@diego71> sembra di no
22:24 <@valhalla> sempre tornando sul ; ``TZ=UTC date ; TZ=America/New_York date`` da la data con due timezone diverse nessuna delle quali è quella di default del sistema
22:24 <@valhalla> diego71: passa pure altre domande
22:24 <@diego71> < polva> quindi le variabili sono assegnate temporaneamente a ogni sessione o rimangono?
22:25 <@valhalla> sono assegnate ad ogni sessione, temporaneamente
22:25 <@valhalla> alcune sono impostate di default, per cui ad ogni nuova sessione vengono reimpostate, ma non perché siano permanenti
22:25 <@valhalla> altre domande?
22:28 <@diego71> < JulesX> distruggere la variabile?
22:28 <@valhalla> unset VARIABILE
22:34 -!- rasalgethi [~quassel@host144-245-dynamic.17-79-r.retail.telecomitalia.it] has left #lifo []
22:34 <@valhalla> visto che non ci sono altre domande direi che finiamo
22:35 <@valhalla> come non detto, ci sono domande
22:35 <@diego71> < samuele76> ...scusate se la sparo grossa...differenza tra variabili e alias ?...ho un pò di confusione in testa...
22:36 -!- DD3my [~DD3my@unaffiliated/dd3my] has quit [Quit: Sto andando via]
22:36 <@valhalla> un alias è solo un comando, la variabile pu`o essere usata ovunque, anche come parametro ecc.
22:36 <@diego71> < tiziano> quindi export pubblica la variabile per tutte le istanza di bash nella sessione corrente...anche quelle già aperte?
22:36 -!- aldagaau [~Alain@95.233.88.242] has quit [Remote host closed the connection]
22:37 <@valhalla> no, solo per quella corrente e quelle lanciate da quella corrente
22:37 <@valhalla> (o eventuali programmi lanciati dalla shell corrente)
22:37 <@valhalla> altre shell aperte in parallelo non sono toccate
22:37 <@diego71> < tiziano> dubbio: cosa intendi per sessione? la sessione dell'utente?
22:37 <@valhalla> no, la singola shell
22:38 <@valhalla> ad esempio, ogni terminale aperto ha la sua sessione
22:38 <@valhalla> e se da dentro un terminale si lancia di nuovo bash, si fa partire una sessione nuova
22:39 -!- Delfino1983 [~Alex@unaffiliated/delfino1983] has quit [Remote host closed the connection]
22:40 <@valhalla> e qui direi che chiudo e preparo il log da uploadare