Riga di comando: materiale lezione 3

4 files changed, 507 insertions, 1 deletions

diff --git a/src/corsi/2014-linea_di_comando.txt b/src/corsi/2014-linea_di_comando.txt
index 24ad1a8..1011223 100644
--- a/src/corsi/2014-linea_di_comando.txt
+++ b/src/corsi/2014-linea_di_comando.txt
@@ -77,11 +77,14 @@ grazie alla documentazione sia preinstallata (manpages) che online.
 ~~~~~~~~~~
 
 * Pipe e redirezioni
+* `log della lezione 3 <2014-linea_di_comando/log-lezione_3.log>`_
+* `materiale della lezione 3 <2014-linea_di_comando/riga_di_comando-lezione_3.tar.xz>`_
 
 11 febbraio
 ~~~~~~~~~~~
 
-TBA
+* Variabili
+* Valori di uscita
 
 18 febbraio
 ~~~~~~~~~~~
diff --git a/src/corsi/2014-linea_di_comando/index.txt b/src/corsi/2014-linea_di_comando/index.txt
index 27fccbc..0856911 100644
--- a/src/corsi/2014-linea_di_comando/index.txt
+++ b/src/corsi/2014-linea_di_comando/index.txt
@@ -11,6 +11,8 @@
       file: log-lezione_2.log
       file: log-lezione_2-raw.log
       file: riga_di_comando-lezione_3.tar.xz
+      file: log-lezione_3.log
+      file: log-lezione_3-raw.log
    /restindex
 
    uservalues
diff --git a/src/corsi/2014-linea_di_comando/log-lezione_3-raw.log b/src/corsi/2014-linea_di_comando/log-lezione_3-raw.log
new file mode 100644
index 0000000..2a22293
--- /dev/null
+++ b/src/corsi/2014-linea_di_comando/log-lezione_3-raw.log
@@ -0,0 +1,260 @@
+21:01 <@valhalla> Benvenuti a tutti anche stasera :)
+21:02 -!- tafaRU [~Alex@87.253.117.217] has joined #lifo
+21:02 -!- giocat [~giocat@host206-112-dynamic.8-87-r.retail.telecomitalia.it] has joined #lifo
+21:02 -!- valhalla changed the topic of #lifo to: LIFO - Laboratorio Informatico Free ed Open - 4 febbraio: terza lezione riga di comando http://lifolab.org/corsi/2014-linea_di_comando.html - http://lifolab.org - http://social.gl-como.it/profile/lifo - domande su #lifo-domande
+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 -!- mediechions1 [~mediechio@host47-168-dynamic.60-82-r.retail.telecomitalia.it] has joined #lifo
+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:04 -!- mediechions1 [~mediechio@host47-168-dynamic.60-82-r.retail.telecomitalia.it] has quit [Client Quit]
+21:05 -!- polva [~polva@host33-135-dynamic.43-79-r.retail.telecomitalia.it] has joined #lifo
+21:05 <@valhalla> Stasera iniziamo a parlare veramente di cose che caratterizzano la riga di comando e la rendono potente
+21:05 -!- mediechions1 [~mediechio@host47-168-dynamic.60-82-r.retail.telecomitalia.it] has joined #lifo
+21:05 <@valhalla> ovvero, iniziamo a combinare pi`u comandi per fare cose che i singoli comandi non fanno
+21:05 -!- gioque1 [~gioque@host79-234-dynamic.7-79-r.retail.telecomitalia.it] has joined #lifo
+21:05 -!- fabrixxm [~fabio@host102-100-dynamic.60-82-r.retail.telecomitalia.it] has left #lifo []
+21:06 -!- lucmon71 [~luca@net-2-37-154-144.cust.vodafonedsl.it] has joined #lifo
+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 -!- mrcast [~mrcast@host119-67-dynamic.40-79-r.retail.telecomitalia.it] has joined #lifo
+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 -!- mrcast [~mrcast@host119-67-dynamic.40-79-r.retail.telecomitalia.it] has left #lifo []
+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:43 -!- aceraspireoned15 [~aceraspir@46.249.82.109] has quit [Quit: Ex-Chat]
+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 -!- odeeno [~odeeno@94.163.155.90] has joined #lifo
+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 <? (repetita juvant ;-)
+22:11 <@valhalla> ">" 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 -!- malo [~malo@217.203.128.134] has quit [Quit: Sto andando via]
+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 -!- odeeno [~odeeno@94.163.155.90] has quit [Ping timeout: 246 seconds]
+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 -!- rupperto [~rupperto@net-93-145-188-233.cust.dsl.teletu.it] has quit [Quit: Sto andando via]
+22:20 -!- thefantaman [~fanta@dynamic-adsl-78-14-186-85.clienti.tiscali.it] has quit [Quit: Sto andando via]
+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:26 -!- jack83 [~Icedove@host142-13-dynamic.31-79-r.retail.telecomitalia.it] has joined #lifo
+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
diff --git a/src/corsi/2014-linea_di_comando/log-lezione_3.log b/src/corsi/2014-linea_di_comando/log-lezione_3.log
new file mode 100644
index 0000000..dc8c55c
--- /dev/null
+++ b/src/corsi/2014-linea_di_comando/log-lezione_3.log
@@ -0,0 +1,241 @@
+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 <? (repetita juvant ;-)
+22:11 <@valhalla> ">" 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