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

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