21:01 <@valhalla> Benvenuti a tutti anche stasera :) 21:02 <@valhalla> Come al solito, il canale per le domande è #lifo-domande , diego71 si preoccupererà di copiare di qui le domande nel momento giusto 21:03 <@valhalla> mentre warp10, erossi e fabrixxm lo aiutano a darvi una mano se ci son problemi 21:04 <@valhalla> Nelle prime due lezioni abbiam parlato di come è fatto un comando ed introdotto i comandi veramente basilari che servono per usare la riga di comando al posto del file manager, in modo da potersi allenare ad usarla 21:05 <@valhalla> Stasera iniziamo a parlare veramente di cose che caratterizzano la riga di comando e la rendono potente 21:05 <@valhalla> ovvero, iniziamo a combinare pi`u comandi per fare cose che i singoli comandi non fanno 21:06 <@valhalla> per inziare, come la volta scorsa apriamo una riga di comando, spostiamoci nella directory dove c'è il materiale delle volte scorse con cd 21:06 <@valhalla> (e si può controllare di essere nel posto giusto con ls e pwd) 21:06 <@valhalla> e poi scarichiamo il materiale con wget http://www.lifolab.org/corsi/2014-linea_di_comando/riga_di_comando-lezione_3.tar.xz 21:07 <@valhalla> dopodiché scompattiamolo con tar -x -v -f riga_di_comando-lezione_3.tar.xz 21:07 <@valhalla> se mentre scaricate qualcuno ha domande sulle volte scorse 21:07 <@valhalla> fate pure adesso 21:12 <@valhalla> (ok, intanto mi sono accorta che il file che ho uploadato non è veramente compresso, ma lo correggo dopo la lezione, che tanto funziona comunque) 21:13 <@valhalla> prima dicevo, stasera inizieremo a comporre programmi tra di loro 21:14 <@valhalla> questa è una delle caratteristiche fondamentali della "filosofia unix": avere tanti piccoli programmi che fanno una cosa sola, e comporli tra di loro per poter fare cose più grandi 21:14 <@valhalla> non sempre i tool da riga di comando seguono questo principio (specialmente i più recenti tendono ad avere molte feature), ma i metodi standard per comporre più comandi sono sempre presenti, e sempre molto usati 21:15 <@valhalla> uno di questi metodi si basa sul fatto che ogni programma da riga di comando può sempre avere accesso a tre oggetti: 21:15 <@valhalla> stdin, stdout e stderr 21:15 <@valhalla> per il programma, questi sono considerati alla stregua di un file e il programma li pu`o trattare più o meno allo stesso modo di un file 21:17 <@valhalla> ma sono sempre disponibili, e se si sta lanciando semplicemente il comando dalla shell interattiva stdin contiene tutto quel che viene scritto sulla tastiera, mentre quello che il programma scrive su stdout e stderr vanno sul terminale 21:17 <@valhalla> (std in questi casi sta per "standard", in per "input", "out" per output ed "err" per errors) 21:18 <@valhalla> quello che però si può fare è redirigere questi file, ovvero fare sì che non vengano associati come detto prima, ma presi o scritti da un file "normale", oppure passati da un comando all'altro 21:18 <@valhalla> ad esempio, iniziamo creando la solita directory per gli esercizi: 21:18 <@valhalla> cd lezione_3 21:19 <@valhalla> ``mkdir esercizi`` 21:19 <@valhalla> ``cd esercizi`` 21:19 <@valhalla> a questo punto lanciamo un comando semplice: ``cal`` 21:19 <@valhalla> questo mostra un calendario del mese corrente 21:20 <@valhalla> oppure, nella variante ``cal -y`` un calendario dell'anno 21:21 <@valhalla> se noi però aggiungiamo ``>`` alla fine del comando ed il nome di un file, anziché stampare il calendario sullo schermo, questo verrà scritto sul file, ad esempio: ``cal -y 2014 > calendario_2014.txt`` 21:21 <@valhalla> e poi vediamo con ls che è stato creato un file, e con ``less calendario_2014.txt`` che cosa quel file contiene 21:21 <@valhalla> ``>`` significa "redirigi lo standard output sul file indicato, *rescrivendo il file da zero* 21:22 <@valhalla> ovvero, se adesso ridate ``cal -y 2014 > calendario_2014.txt`` non vi trovate con due volte il calendario, ma il calendario vecchio viene cancellato, e viene scritto di nuovo 21:22 <@valhalla> ci sono domande fin qui? 21:22 <@diego71> si 21:22 <@diego71> < polva> domanda: c'è un legame tra stdout e la variabile DISPLAY (che ho riscontrato nei comandi SSH ad esempio)? 21:23 <@valhalla> no, fondamentalmente non c'entrano nulla 21:23 <@valhalla> DISPLAY è una variabile usata dal sistema grafico (xorg) 21:23 <@valhalla> altre domande? 21:23 <@diego71> < samuele76> la data corretta la prende dal bios? o è quella del sistema? 21:24 <@valhalla> la data usata per scegliere il "mese/anno corrente" è quella di sistema, e ovviamente potrebbe non essere corretta 21:25 <@valhalla> a seconda del sistema potrebbe essere presa all'avvio dal bios, sincronizzata via internet, o millemila altre fonti 21:25 <@valhalla> altre domande? 21:25 <@diego71> no 21:26 <@valhalla> ok, prima dicevo che di default sul terminale vanno sia stdout che stderr: la differenza tra i due è che in stdout va l'output "normale" del terminale, su stderr per convenzione si fanno scrivere eventuali errori 21:26 <@valhalla> ad esempio, dando il comando ``cal -y 12345 > calendario_12345.txt`` 21:27 <@valhalla> vedrete che sullo schermo viene stampato un messaggio di errore, mentre il file calendario_12345.txt viene creato, ma sarà vuoto (visto che cal non sa cosa stampare) 21:28 <@valhalla> se uno non vuole avere nessun messaggio sul terminale può salvare sia l'output che gli errori su due file diversi: 21:29 <@valhalla> ``cal -y 12345 > calendario_12345.txt 2> log-12345.txt`` 21:29 <@valhalla> con 2> si dice dove si vuole che vada lo stderr 21:29 <@valhalla> e con less potete vedere che il messaggio di errore di prima è finito su log-12345.txt 21:29 <@valhalla> ci sono altre domande? 21:29 <@diego71> si 21:30 <@diego71> < JulesX> ma in sostanza stdin out o err non sono devi veri e propri programmi ma...? 21:30 <@valhalla> non sono dei programmi, sono una specie di file 21:30 <@valhalla> ovvero: il programma li tratta come se fossero dei file sull'hd e li pu`o leggere o può scriverci sopra 21:32 <@valhalla> e poi il sistema anziché scriverli sull'hard disk li mostra a schermo o cose varie 21:32 <@valhalla> come principio è molto usato sotto unix: trattare tutto come se fosse un file, in modo tale che i vari programmi debbano solo sapere come fare a leggere o scrivere un file 21:33 <@valhalla> e poi è il sistema a decidere se quei dati finiscono su un hard disk, vengono visualizzati a schermo, o magari addirittura spediti su internet 21:33 <@valhalla> altre domande? 21:33 <@diego71> < polva> gli std "appartengono" ciascuno a una sessione di shell o sono di sistema? se apro due sessioni di terminale uso due stderr, ad esempio, diversi? 21:33 <@valhalla> (o anche se la risposta non è stata chiara, che come concetto per capire come usare la riga di comando è importante) 21:34 <@valhalla> la seconda: ogni terminale ha il suo stdin, stdout e stderr 21:34 <@valhalla> altre domande? 21:34 <@diego71> si 21:34 <@diego71> JulesX> il "2" di 2>filedilog sta per stdin ... quindi per out starebbe 1 e per in 0? 21:35 <@diego71> (poi si e' corretto in stderr) 21:35 <@valhalla> sì, in teoria sì, anche se di fatto non lo si fa 21:35 <@valhalla> ovvero, stdin è il file "0", stdout il file "1" e stderr il file "2", ma quando si scrive sulla shell per out si usa semplicemente > 21:35 <@valhalla> altre domande? 21:36 <@diego71> < gioque1> mi chiedevo a questo punto: ma gli exit status dei comandi.. come vanno considerati? STDOUT o STDERR? 21:36 <@valhalla> gli exit status sono un'altra cosa ancora, che non finisce su nessuno di quei due file 21:36 <@valhalla> e ne parleremo in una prossima lezione 21:36 <@valhalla> altre domande? 21:37 <@diego71> < aldagaau> esempi pratici per utilizzare stdin stdout stderr. Nella shell di tutti i giorni 21:37 <@valhalla> aldagaau: primo esempio pratico canonico: quando si lancia un programma che deve girare a lungo su un server, senza stare lì a vederlo 21:38 <@valhalla> si lancia il programma, si redirigono stdout e stderr su due file, e quando si torna ci si è beccati il risultato ed il log, comodi comodi da leggere in un file 21:38 <@valhalla> altro esempio pratico arriva poco oltre, avendo aggiunto un paio di altre cose 21:38 <@valhalla> altre domande? 21:39 <@valhalla> anzi, aspetta 21:39 <@valhalla> altro esempio pratico: ci sono programmi che generano file non di solo testo, ma che li mandano comunque su stdout 21:39 <@valhalla> ad esempio, ci sono programmi che su stdout mandano un file pdf, o un'immagine, in questi casi li si deve redirigere più o meno per forza 21:39 <@valhalla> diego71: ok, passa pure l'altra domanda 21:39 <@diego71> < gioque1> mi chiedevo a questo punto: ma gli exit status dei comandi.. come vanno considerati? STDOUT o STDERR? 21:40 <@diego71> scusate 21:40 <@diego71> la stanchezza 21:40 <@valhalla> ok, allora proseguo 21:40 <@valhalla> fin'ora abbiamo visto come mandare stdout o stderr su un file, in modo simile si pu`o prendere stdin da un file 21:41 <@valhalla> c'è ad esempio il comando head che stampa le prime righe di un file 21:41 <@valhalla> di default, come file prende lo stdin, ma noi possiamo passargli un file usando ``<`` 21:41 <@valhalla> ad esempio: head -n 10 < calendario_2014.txt 21:41 <@valhalla> stampa a schermo le prime 10 righe del calendario 21:42 <@valhalla> e poi c'è il programma duale che stampa le ultime righe, ad esempio ``tail -n 9 < calendario_2014.txt`` 21:43 <@valhalla> ``<``, ``>`` e ``2>`` possono essere combinati sulla stessa riga, ad esempio ``tail -n 9 < calendario_2014.txt > inizio_calendario.txt`` 21:43 <@valhalla> domande? 21:43 <@diego71> si 21:43 <@diego71> < MrPan> si può prendere lo stdin, ad esempio, da un file CSV o simili? o solo TXT ? 21:44 <@valhalla> per la shell non c'è differenza, il file potrebbe essere qualunque cosa, un CSV, un'immagine, un pdf 21:44 <@valhalla> poi deve essere il programma ad essere in grado di capire cosa fare di quel file 21:45 <@valhalla> ci sono ad esempio programmi che prendono da stdin un'immagine, la convertono in altro formato e la buttano su stdout: in quei casi tipicamente sia stdin che stdout saranno presi da dei file, con le redirezioni 21:45 <@valhalla> altre domande? 21:45 <@diego71> no 21:46 <@valhalla> fin qui ancora non abbiam combinato più programmi tra di loro 21:46 <@valhalla> che era quel che avevo promesso all'inizio :) 21:46 <@valhalla> il modo in cui si possono combinare pi`u programmi è tramite le "pipes" 21:47 <@valhalla> ovvero, oltre a redirigere stdin, err e out su file, si può far sì che lo stdout di un programma finisca sullo stdin di un'altro programma 21:47 <@valhalla> ad esempio, ``cal -y 2014 | head -n 18 | tail -n 8`` 21:48 <@valhalla> il primo programma, cal, stampa il nostro solito calendario, questo calendario viene passato a head che lo prende e ne stampa sul suo stdout solo le prime 18 righe, e questo stdout a sua volta viene passato a tail che ne stampa solo le ultime 8 21:48 <@valhalla> il risultato è di stampare le 8 righe centrali (che se non ho sbagliato a contare sono aprile, maggio e giugno :) 21:48 <@valhalla> domande? 21:49 <@diego71> si 21:49 <@diego71> < tiziano> esiste un modo sul terminale per evidenziare in modo differente quello che proviene da stout o da sterr? 21:49 <@valhalla> che io sappia l'unico modo è redirigere uno dei due da qualche altra parte 21:49 <@valhalla> alre domande 21:49 <@valhalla> ? 21:49 <@diego71> no 21:50 <@valhalla> un esempio pratico nella vita reale di tutto ciò è la risposta ad una domanda di due lezioni fa: 21:51 <@valhalla> se si ha un programma con un output discretamente lungo, lo si può passare a less usando le pipe: ``ls /usr/bin | less`` 21:52 <@valhalla> domande? 21:52 <@diego71> no 21:53 <@valhalla> nella dispensa ho messo qualche altro esercizietto che usa questi comandi 21:53 <@valhalla> ad esempio: c'è un comando "split" che prende un file e lo divide in pezzi di dimensione fissa 21:53 <@valhalla> split -l 10 calendario_2014.txt 21:54 <@valhalla> divide il nostro file in pezzi da 10 righe l'uno 21:54 <@valhalla> (file che si chiamano xaa xab xac e xad) 21:54 <@valhalla> a quel punto se volessimo rileggere tutto quanto con less, ma vedendoli tutti assieme, potremmo usare 21:54 <@valhalla> cat xaa xab xac xad | less 21:55 <@valhalla> mentre per ripristinare il file completo ``cat xaa xab xac xad > calendario_ricostituito.txt`` 21:55 <@valhalla> domande? 21:55 <@diego71> si 21:55 <@diego71> < gioque1> se io faccio cd < nomecartella e nel file nomecartella ho il nome della cartella dove voglio andare... perchè non funziona? 21:56 <@valhalla> perch'e il comando cd si aspetta che il nome della cartella dove andare sia un parametro, non si aspetta che gli venga passato nello stdin 21:56 <@valhalla> altre domande? 21:56 <@diego71> no 21:57 <@diego71> < JulesX> solo su man "nomecomando" si vede se un programma accetta stdin o out? 21:57 <@valhalla> fondamentalmente sì, lo si scopre dalla documentazione del programma 21:57 <@valhalla> che potrebbe essere man, ma anche sito web o simili 21:57 <@valhalla> altre domande? 21:58 <@diego71> sembra di no 21:58 <@valhalla> ok 21:58 <@valhalla> confesso che in questa lezione un po' ho barato: la maggior parte dei comandi moderni non ha bisogno di ``<`` perché se gli si passa un nome di file legge da quello anziché dallo stdin 21:59 <@valhalla> però serviva per illustrare la cosa, prima di passare alle pipe 21:59 <@valhalla> in compenso ``>`` e ``2>`` vengono usati ampiamente tutt'ora, come dicevo negli esempi primi 21:59 <@valhalla> altre domande? 21:59 <@diego71> si 21:59 <@diego71> < gioque1> nel caso un comando richieda l'intervendo dell'utente e io ho rediretto stdout e stderr su un file... come si comporta il sistema? 22:00 <@valhalla> in generale, in quel caso il programma manderebbe la richiesta di intervento sul file dove sono stati rediretti stdout e stderr 22:01 <@valhalla> per`o continuerebbe a ricevere input dallo stdin, per cui se si sa quale sia l'input richiesto lo si pu`o dare "alla cieca" 22:02 <@valhalla> se invece ad essere rediretto è lo stdin, il comando prenderebbe le risposte dal file anziché dalla tastiera 22:02 <@valhalla> e questo in effetti è un esempio pratico che pu`o capitare: salvare le risposte (magari per un tool di configurazione) in un file e far prendere lo stdin del programma da quel file 22:03 <@valhalla> (non è privo di rischi, dato che assume che il programma chieda sempre le stesse cose, ma di tanto in tanto capita di farlo) 22:03 <@valhalla> altre domande? 22:03 <@diego71> zi 22:03 <@diego71> < JulesX> quindi "2>" equivale a " > " 22:03 <@valhalla> no, ``2>`` redirige solo lo stderr, ``>`` redirige solo lo stdout 22:04 <@diego71> < JulesX> " > " equivale al pipe " | " 22:05 <@valhalla> no, ``>`` manda lo stdout su un file del quale si precisa il nome 22:05 <@valhalla> ``|`` invece manda lo stdout ad un altro programma 22:05 <@valhalla> se ci si sbaglia, si fanno cose amene 22:06 <@valhalla> tipo ``cal -y > less`` 22:06 <@valhalla> anziché lanciare il comando less, crea un file di nome less con dentro il calendario 22:07 <@valhalla> farlo nella directory in cui è presente l'eseguibile che si vorrebbe lanciare, in questo caso riscriverebbe l'eseguibile 22:07 <@valhalla> (da cui amenità ed eventualmente bestemmie) 22:07 <@valhalla> altrimenti detto: state attenti :) 22:07 <@valhalla> altre domande? 22:07 <@diego71> < Raffa> tra i caratteri '>' '<' '|' ed eventuali opzioni '-x' ecc. come vengono considerati gli spazi? 22:08 <@valhalla> ci sono casi in cui potrebbero essere opzionali, ma di solito ci vogliono, e quindi nel dubbio si mettono 22:08 <@valhalla> domanda successiva? 22:08 <@diego71> < tiziano> è possibile inviare stdout sia su file che su terminale? 22:08 <@valhalla> sì, c'è un comando apposta per farlo (in effetti mi viene in mente adesso che potevo inserirlo) 22:09 <@valhalla> il comando ``tee`` prende lo stdin e lo scrive sia sul file che gli si passa come parametro che sul suo stdout 22:09 <@valhalla> ad esempio: ``cal -y | tee altro_calendario.txt`` 22:09 <@valhalla> e poi potete vedere il file altro_calendario.txt (ad esempio con less) 22:10 <@valhalla> altre domande? 22:10 <@diego71> < aldagaau> se il simbolo > significa "scrivi.txt", a cosa significa ">" significa "scrivi su", mentre "<" significa "leggi da" 22:11 <@diego71> < rasalgethi> ma come fa il programma a prendere un stdin da un file e sapere quale prendere e quando? 22:12 <@valhalla> il programma di per se non sa che lo stdin arriva da un file o dalla tastiera 22:12 <@valhalla> è il sistema a prendere il file che si è indicato con "<" e passarlo al programma 22:12 <@valhalla> che si è indicato dopo "<" 22:12 <@valhalla> (o meglio, la shell, non il sistema in generale) 22:13 <@valhalla> altre domande? 22:13 <@diego71> < polva> è possibile "leggere" il file stdout di una sessione di terminale? nel senso... lo stdout è una "variabile" che si riempie e si svuota immediatamente in base al comando corrente oppure costituisce una specie di "log" che si può leggere successivamente? mi è venuto in mente perchè dicevate che è trattato tipo un file... 22:13 <@valhalla> è trattato tipo un file dal programma, ma non passano dall'hard disk o simili 22:14 <@valhalla> quindi no, stdin, stdout e stderr di un processo vengono creati e distrutti assieme al processo stesso, non ne rimangono tracce 22:14 <@valhalla> se lo si vuole leggere in futuro, bisogna salvarlo esplicitamente 22:14 <@valhalla> altre domande? 22:14 <@diego71> < Raffa> quindi si può dirottare il file anche verso la stampante come sfaceva col dos ex dir > prn ? 22:15 <@valhalla> in teoria sì, in pratica facendolo non è assolutamente detto che la stampante lo riconosca come file da stampare e lo stampi come si deve 22:16 <@valhalla> sotto dos i file in questione erano di solo testo e le stampanti erano fatte per prendere testo e stamparlo pari pari 22:17 <@valhalla> adesso che sia file che stampanti sono un pochettino più complesse, servono in mezzo dei programmi che traducano le cose 22:17 <@valhalla> c'è un comando, lpr, che serve per richiamare il sistema di stampa e mandare file alla stampante, e quello pu`o essere usato facendogli leggere da stdin 22:18 <@valhalla> ad esempio, ``ls | lpr`` manda alla stampante di default il testo che ha stampato ls 22:18 <@valhalla> altre domande? 22:18 <@diego71> < gioque1> usando < (leggi da file X) esiste una maniera per fargli leggere una riga specifica? 22:19 <@valhalla> non nella shell, si usano head e tail per selezionare la riga 22:19 <@valhalla> la shell quando redirige redirige tutto 22:20 <@valhalla> ma se in mezzo si mettono dei comandi che selezionano delle righe, al programma finale arriverà solo la selezione 22:20 <@valhalla> ad esempio: ``head -3 < calendario_2014.txt | tail -1 | less`` selezionrà la terza riga 22:21 <@valhalla> altre domande? 22:21 <@diego71> < erio> quindi...history > history.txt mi genera un file con tutti i comandi della shell fino a qui.... 22:22 <@valhalla> sì 22:22 <@valhalla> (tutti quelli salvati: history salva solo un certo numero di comandi e poi dimentica i più vecchi) 22:22 <@valhalla> altre domande? 22:23 <@diego71> < samuele76> ...quindi un comando tipo "apt-get install nome_programma > log_di_installazione.txt " mi crea un file con tutto l'output che esce dopo il comando? 22:23 <@valhalla> (e se qualcuno si chiedesse cos'è history, è un comando che stampa i comandi dati in precedenza) 22:23 <@valhalla> in linea di principio sì, ma non ricordo se apt-get install stampa su stdout o stderr 22:24 <@valhalla> (nel caso si deve adattare > o 2>) 22:24 <@valhalla> mi dicono dalla regia che giustamente su stdout vanno i messaggi di routine, mentre gli errori veri e propri vanno su stdout 22:24 <@valhalla> ehm, su stderr, ovviamente 22:24 <@valhalla> altre domande? 22:25 <@diego71> JulesX> come mai gli da un valore negativo a head? 22:25 <@valhalla> non è un valore negativo, è un'opzione 22:25 <@valhalla> solo che al posto di essere composta da trattino + lettera head prende trattino + numero come numero di righe 22:26 <@diego71> < JulesX> l'input da tastiera si può passarlo in anticipo? aptitude safe-upgrade < y? 22:26 <@valhalla> così cerca di prendere l'input da un file che si chiama "y" nella directory corrente 22:27 <@valhalla> se si ha un file che si chiama "y" e che contiene tante volte la riga "y↵" funziona, ma è meglio usare l'apposito comando ``yes`` 22:28 <@valhalla> che stampa sullo stdout y seguito da ritorno a capo, in continuazione 22:28 <@valhalla> (se l'avete lanciato, ctrl-c per fermarlo) 22:28 <@valhalla> (poi rimane la domanda se sia veramente il caso di farlo, o se sia il caso di stare a leggere le domande, visto poi che aptitude va lanciato da root e pu`o fare danni) 22:28 <@valhalla> altre domande? 22:29 <@valhalla> ah, il comando yes a quel punto richiede una pipe, non una redirect 22:29 <@valhalla> ovvero: ``yes | aptitude safe-upgrade`` 22:29 <@valhalla> altre domande? (stavolta davvero) 22:29 <@diego71> < TaumatirgoDubbio> Serve la "n"? C'e' differenza tra il comando head -n 10 e head -10? perche' prima era stata usata una -n 18 mentre ultimamente si usa "head -3 " 22:29 <@valhalla> -n è il comportamento standard di head, presente da sempre 22:30 <@valhalla> -[numero] è una scorciatoia che c'è nelle versioni "recenti" di head, e mi è scappato :) 22:30 <@valhalla> (dove però con "recenti" si intende "sotto linux da decenni") 22:31 <@valhalla> (sotto altri sistemi unix -[numero] potrebbe non esserci) 22:31 <@valhalla> altre domande? 22:31 <@diego71> aspetto un paio di minuti per vedere se qualcuno gli viene in mente qualcosa 22:31 <@valhalla> ok 22:31 <@diego71> < polva> scrivere "less calendario_2014.txt | head -3 | tail -1" o "head -3 < calendario_2014.txt | tail -1 | less" è equivalente giusto? valhalla ha scelto l'altra forma per comodità o c'è un'altra ragione? 22:32 <@valhalla> iniziare con less calendario_2014.txt non funziona: less non stampa semplicemente sullo stdout ma suddivide in pagine aspettandosi comandi dall'utente 22:32 <@valhalla> se al posto di less si usa cat (che legge file e li stampa sullo stdout) pu`o funzionare: 22:33 <@valhalla> ``cat calendario_2014.txt | head -3 | tail -1`` 22:33 <@valhalla> ma facendo così si lancia un comando in più, e si impiega leggermente più tempo 22:33 <@valhalla> (ce ne si accorge se lo si deve per qualche motivo ripetere millemila volte) 22:34 <@valhalla> aggiungere il ``| less`` alla fine serve poi per poter andare avanti e indietro nel calendario, e si pu`o attaccare ad entrambi i casi 22:34 <@valhalla> altre domande? 22:36 <@valhalla> fine della terza lezione, ci vediamo tra una settimana per la quarta