summaryrefslogtreecommitdiff
path: root/src/corsi/2014-linea_di_comando
diff options
context:
space:
mode:
Diffstat (limited to 'src/corsi/2014-linea_di_comando')
-rw-r--r--src/corsi/2014-linea_di_comando/index.txt2
-rw-r--r--src/corsi/2014-linea_di_comando/log-lezione_6-raw.log191
-rw-r--r--src/corsi/2014-linea_di_comando/log-lezione_6.log175
3 files changed, 368 insertions, 0 deletions
diff --git a/src/corsi/2014-linea_di_comando/index.txt b/src/corsi/2014-linea_di_comando/index.txt
index 56f601d..5302d92 100644
--- a/src/corsi/2014-linea_di_comando/index.txt
+++ b/src/corsi/2014-linea_di_comando/index.txt
@@ -20,6 +20,8 @@
file: log-lezione_5.log
file: log-lezione_5-raw.log
file: riga_di_comando-lezione_6.tar.xz
+ file: log-lezione_6.log
+ file: log-lezione_6-raw.log
/restindex
uservalues
diff --git a/src/corsi/2014-linea_di_comando/log-lezione_6-raw.log b/src/corsi/2014-linea_di_comando/log-lezione_6-raw.log
new file mode 100644
index 0000000..76ccde8
--- /dev/null
+++ b/src/corsi/2014-linea_di_comando/log-lezione_6-raw.log
@@ -0,0 +1,191 @@
+21:04 <@valhalla> e iniziamo come al solito scaricando il materiale:
+21:04 <@valhalla> wget http://www.lifolab.org/corsi/2014-linea_di_comando/riga_di_comando-lezione_6.tar.xz
+21:04 <@valhalla> tar -x -v -f riga_di_comando-lezione_6.tar.xz
+21:05 <@valhalla> questa sera parliamo di controllo dei processi
+21:05 <@valhalla> (dimenticavo all'inizio il solito cd $DIRECTORY_SOLITA
+21:06 <@valhalla> e dopo aver scaricato e scompattato prepariamo come sempre lo spazio per fare esercizi: ``cd lezione_6 && mkdir esercizi``
+21:06 -!- pigro [~Luca@87.18.59.215] has joined #lifo
+21:06 <@valhalla> (che come ricordate dalla volta scorsa, vi fa creare la directory esercizi solo se siete riusciti ad entrare nella dir lezione_6)
+21:06 <@valhalla> e poi ``cd esercizi``
+21:06 -!- taumaturgo [5d93b0b8@gateway/web/freenode/ip.93.147.176.184] has joined #lifo
+21:07 -!- JulesX [~lorenzo@adsl-ull-106-115.51-151.net24.it] has joined #lifo
+21:07 <@valhalla> la maggior parte dei comandi che abbiamo visto le altre volte finiva subito, quindi veniva lanciata, si aspettava la fine e poi si lanciava il comando successivo
+21:07 <@valhalla> per`o ovviamente non tutti i programmi sono così
+21:08 -!- fiera [~fiera@87.13.255.234] has joined #lifo
+21:08 <@valhalla> alcuni stanno attivi a lungo perché elaborano dati, altri lanciano un'interfaccia grafica e stanno attivi finché non sono stati chiusi, ad esempio
+21:08 <@valhalla> per fare gli esempi, invece, stasera usiamo un comodo comando che se ne sta fermo ad aspettare per un tot di secondi: sleep
+21:09 <@valhalla> ad esempio, ``sleep 5`` si ferma per 5 secondi e poi finisce
+21:09 <@valhalla> normalmente questo blocca la shell che state usando: questo perché il comando è in "foreground"
+21:10 <@valhalla> ovvero, mentre gira quello è lui a prendersi l'input su stdin
+21:10 <@valhalla> e in ogni momento in una shell può esserci solo un comando in foreground
+21:11 <@valhalla> ci possono però essere più comandi in "background", che non hanno modo di ottenere input, ma continuano a girare fino a che non hanno finito lasciando la shell libera
+21:11 -!- delfino1983 [~Alex83@host155-139-dynamic.252-95-r.retail.telecomitalia.it] has joined #lifo
+21:11 -!- delfino1983 [~Alex83@host155-139-dynamic.252-95-r.retail.telecomitalia.it] has quit [Changing host]
+21:11 -!- delfino1983 [~Alex83@unaffiliated/delfino1983] has joined #lifo
+21:12 <@valhalla> un modo per mandare un programma in background è mettere & alla fine del comando (cosa che avevamo visto alla prima lezione, e vi avevo promesso spiegazione)
+21:12 <@valhalla> ad esempio, possiamo dare il comando ``sleep 100 &`` e subito dopo vediamo che la shell è libera, e ad esempio possiamo usare il comando ``jobs`` per vedere che programmi stanno girando in quella shell
+21:13 <@valhalla> vediamo che il nostro sleep 100 è in status Running, ma noi abbiamo la shell a disposizione
+21:14 <@valhalla> vedo che ci sono domande, passatemele pure
+21:15 <@diego71> < pigro> il numero visualizzato da jobs ?? il pid del job?
+21:15 <@valhalla> no, è il numero di job in quella shell
+21:15 <@valhalla> di PID invece parliamo dopo, e vediamo come si fa a vederlo
+21:17 <@valhalla> nel frattempo, sleep dovrebbe aver finito, e se lanciamo ancora ``jobs`` vediamo che viene segnato come "Done"
+21:17 <@valhalla> e poi sparisce del tutto
+21:18 <@valhalla> adesso per comodità facciamo andare due comandi alla volta: mettendo una serie di comandi tra parentesi tonde si fa partire una nuove shell che esegue quei programmi, e poi possiamo mandare il tutto in background, ad esempio
+21:18 <@valhalla> ``(sleep 60 ; date) &``
+21:18 <@valhalla> ancora ``jobs`` e vediamo che sta andando un job con tutti e due i comandi
+21:18 <@valhalla> in questo modo, quando sleep ha finito vediamo stampare cose, e ci accorgiamo subito che ha finito
+21:19 <@valhalla> mentre un programma è in foreground, possiamo passargli dei segnali
+21:19 <@valhalla> che i programmi per unix riconoscono e agiscono di conseguenza
+21:21 <@valhalla> con Ctrl-C si passa il segnale SIGINT, che interrompe il programma
+21:21 <@valhalla> i programmi poi possono intercettare questi segnali e non farsi interrompere subito, ma ad esempio chiudersi come si deve, ma dipende dal programma
+21:21 <@valhalla> ad esempio, lanciamo ``(sleep 100 ; echo "sleep")``, poi premiamo Ctrl-C
+21:22 <@valhalla> e con jobs possiamo controllare che non è rimasto niente, il processo è stato fermato
+21:22 <@valhalla> domande fin qui?
+21:23 <@valhalla> ok, proseguo
+21:23 <@valhalla> un altro segnale utile è SIGSTOP, che invece interrompe il processo senza chiuderlo
+21:23 <@valhalla> e poi lo si pu`o far riprendere
+21:24 <@valhalla> come se lo si mettesse in pausa
+21:24 <@valhalla> ad esempio ``(sleep 100 ; echo "sleep")`` poi premete Ctrl-Z
+21:24 <@valhalla> e con ``jobs`` potete vedere che c'è quel processo che risulta "Stopped"
+21:25 <@valhalla> finché lo lasciate lì non fa niente, non fa neanche passare i 100 secondi prima di chiudersi
+21:25 -!- albertux [~Icedove@dynamic-adsl-78-14-226-4.clienti.tiscali.it] has joined #lifo
+21:25 <@valhalla> però ci sono dei comandi coi quali si può far riprendere un processo; con ``fg`` gli si dice di tornare in foreground e ricominciare a funzionare
+21:26 <@valhalla> oppure, (per provare potete reinterrompere con Ctrl-Z un'altra volta)
+21:26 <@valhalla> con ``bg`` si manda il processo bloccato in background, e lo si fa riprendere
+21:27 <@valhalla> questo è il modo in cui si mandano in background dei processi se si è dimenticato di mettere & alla fine del comando, ad esempio
+21:27 <@valhalla> con ``jobs`` potete sempre vedere che avete un processo in background, e dopo un po' finalmente vi stamperà "sleep"
+21:27 <@valhalla> domande?
+21:28 <@diego71> < gioque> che differenza c'?? tra sleep 100; echo "sleep" e (sleep 100; echo sleep)
+21:28 <@valhalla> se si scrive ``sleep 100; echo "sleep"`` i due comandi vengono lanciati in successione dalla shell in cui si sta lavorando
+21:28 <@valhalla> con le parentesi invece viene aperta una nuova shell ed è lei a lanciare in successione i due comandi
+21:28 <@valhalla> col vantaggio che li si pu`o trattare come una cosa unica
+21:29 <@valhalla> nel nostro caso per mandarli in foreground/background, ma anche ad esempio per leggere lo stdout di tutti uno dopo l'altro
+21:29 -!- albertux [~Icedove@dynamic-adsl-78-14-226-4.clienti.tiscali.it] has quit [Client Quit]
+21:30 <@valhalla> se si scrivesse solo ``sleep 100; echo "sleep" &`` sarebbe solo l'echo ad essere messo in background, sleep rimarrebbe in foreground
+21:30 <@valhalla> altre domande?
+21:31 <@valhalla> proseguo
+21:31 <@valhalla> un'altro modo che abbiamo di mandare segnali ai processi è il comando kill
+21:33 <@valhalla> di default anche lui manda il segnale SIGINT, mentre con l'opzione ``-9`` manda il segnale SIGKILL, che non può essere intercettato dai programmi e li fa chiudere ad ogni costo
+21:34 <@valhalla> ad esempio, possiamo lanciare un paio di comandi in background: ``(sleep 100 ; echo "primo") &`` e poi ``(sleep 100 ; echo "secondo") &``
+21:34 <@valhalla> ``jobs`` per vedere che ci sono
+21:34 <@valhalla> e poi con ``kill %`` possiamo mandare il segnale SIGINT al secondo dei due
+21:34 <@valhalla> e aspettando vedremo che solo il primo sarà arrivato a completamento
+21:36 <@valhalla> (altre domande?
+21:37 <@valhalla> < tiziano> cosa significa il carattere % in kill %?
+21:37 <@valhalla> sta per "ultimo processo"
+21:37 <@valhalla> lo si può usare anche con fg e bg
+21:38 <@valhalla> oltre a % e basta si pu`o anche usare %<numero> e si lavora sul job con quel numero (come viene stampato dal comando jobs
+21:39 <@valhalla> ad esempio, ``(sleep 100 ; echo "primo") &`` ``(sleep 100 ; echo "secondo") &`` e poi ``kill %1`` ucciderà il primo dei due, e lascerà andare il secondo
+21:39 <@valhalla> altre domande?
+21:39 <@valhalla> vado avanti
+21:40 <@valhalla> un altro comando utile è ps, che stampa i processi in corso, e di default stampa non solo i processi della shell in corso, ma quelli del *terminale*
+21:41 <@valhalla> ad esempio, mettiamoci un po' di roba con ``sleep 100 &`` ripetuto un paio di volte
+21:41 <@valhalla> e poi ``ps``
+21:41 <@valhalla> di default quello mostra il PID del processo, che era stato citato prima
+21:42 <@valhalla> ovvero, un identificativo univoco del processo su *tutto* il sistema
+21:42 <@valhalla> [ditemi sul canale di là per favore se mi state leggendo]
+21:42 -!- diego_ [~diego@81-174-50-202.v4.ngi.it] has joined #lifo
+21:43 -!- diego_ [~diego@81-174-50-202.v4.ngi.it] has quit [Client Quit]
+21:44 <@valhalla> dicevo, il PID non è univoco nel tempo: dopo un certo numero riparte a prendere i numeri rimasti liberi da processi che sono stati chiudi
+21:44 <@valhalla> ma in ogni momento ci sarà un solo processo con quel PID
+21:45 <@valhalla> usando l'opzione ``-f`` di ps si hanno un po' più di dettagli utili
+21:46 <@valhalla> e in particolare UID, ovvero l'utente con i cui permessi sta girando quel processo e le opzioni con cui era stato lanciato il comando
+21:47 <@valhalla> doamnde?
+21:47 <@diego71> pigro> che differenza c'?? tra PID e PPID?
+21:47 <@valhalla> PPID è il PID del processo padre del processo elencato
+21:47 <@valhalla> ovvero del processo che ha fatto partire il processo in questione
+21:48 <@valhalla> con questo possiamo anche vedere la differenza tra ``sleep 100 ; echo "uno"`` e ``(sleep 100 ; echo "due")``
+21:49 <@valhalla> ad esempio se facciamo ``sleep 100 ; echo "uno"
+21:49 <@valhalla> ``
+21:50 <@valhalla> poi ctrl-z per sospenderlo, e poi ps
+21:50 <@valhalla> vediamo che ci sono una bash, sleep e il ps appena lanciato
+21:51 <@valhalla> (poi usiamo fg per far tornare attivo lo sleep, o bg per mandarlo in background, cos`i va avanti
+21:51 <@valhalla> se invece scriviamo ``(sleep 100 ; echo "due")``, poi sempre ctrl-z per fermarlo
+21:52 <@valhalla> a quel punto con ``ps`` vediamo che ci sono due bash, uno sleep e poi ps
+21:52 <@valhalla> e anzi, se usiamo ps -f vediamo che il parent della seconda bash e del ps è la prima bash
+21:52 <@valhalla> mentre sleep ha come parent la seconda bash
+21:52 <@valhalla> altre domande?
+21:54 <@valhalla> ok, dovrei aver finito il backlog delle domande a cui avevo detto rispondo dopo
+21:54 <@valhalla> se manca qualcosa, perfavore rifatela
+21:54 <@valhalla> intanto vado avanti dicendo che:
+21:54 <@valhalla> il PID pu`o essere usato anche come parametro di kill, per mandare segnali a processi non necessariamente sulla stessa shell
+21:55 <@valhalla> ad esempio, diamo il solito ``sleep 100 &``
+21:55 -!- delfino1983 [~Alex83@unaffiliated/delfino1983] has quit [Quit: Sto andando via]
+21:55 <@valhalla> vediamo che ci stampa il numero di job tra parentesi e dopo il suo pid
+21:55 <@valhalla> possiamo controllare che lo sia con ps
+21:55 <@valhalla> e poi possiamo ucciderlo con ``kill $PID``
+21:55 <@valhalla> dove ovviamente al posto di $PID metterete il numero visto prima
+21:56 <@valhalla> per trovare il PID di processi che non conoscete si usa sempre ps
+21:56 <@valhalla> con ``ps -e -f`` si vedono tutti i processi del sistema
+21:56 <@valhalla> anzi, meglio ``ps -e -f | less`` :)
+21:57 <@valhalla> oppure ``ps -e -f | grep $NOME_DEL_PROGRAMMA_CHE_VI_SI_E_PIANTATO`` :)
+21:58 <@valhalla> oppure in qualche caso è utile ``-u $NOME_UTENTE`` al posto di ``-e`` per vedere solo i processi di qualche utente
+21:58 <@valhalla> domande?
+22:00 <@diego71> < pigro> se per errore invio il kill al PPID
+22:00 <@valhalla> pigro: uccidi il PPID (e a catena di solito anche tutti i suoi figli)
+22:01 <@valhalla> a meno che si cerchi di killare un processo di qualche altro utente, nel qual caso lo si può fare solo se si è root
+22:01 <@valhalla> altre domande
+22:01 -!- DD3my [~DD3my@unaffiliated/dd3my] has quit [Quit: Sto andando via]
+22:01 <@diego71> < gioque> per mettere in pause (tipo ctrl+z) un processo che non sia l'ultimo? (tipo se ho tre jobs e volgio mettere in stato stopped [non killed] il n 2 come faccio?)
+22:01 -!- popi [4f06ae61@gateway/web/freenode/ip.79.6.174.97] has joined #lifo
+22:02 <@valhalla> porti in foreground il processo che vuoi stoppare con ``fg %2`` (ad esempio), e poi usi ctrl-z
+22:02 <@valhalla> altre domande?
+22:03 <@diego71> < polva> valhalla, c'era quella domanda su come distinguere tra shell e processo
+22:03 <@valhalla> in che senso distinguere tra shell e processo?
+22:04 <@diego71> < polva> riposto: ! valhalla ha detto che usare le parentesi fa avviare una nuova shell. a me si avvia sempre nella stessa. parte solo un altro comando
+22:04 <@valhalla> avevamo visto l'esempio prima che con ps faceva vedere che tra i processi attivi c'era una nuova bash
+22:05 <@valhalla> dalle 21:49 in poi nel log
+22:05 <@valhalla> non si apre un nuovo *terminale*, solo una nuova bash all'interno nello stesso terminale, se era questo il tuo dubbio
+22:05 <@valhalla> altre domande?
+22:07 <@diego71> < tiziano> che segnale viene emesso esattamente con ctrl-z?
+22:07 <@valhalla> SIGSTOP
+22:08 <@valhalla> ultimo comando per la serata, il comando ``top``
+22:08 <@valhalla> vi fa vedere i processi attivi in ordine di risorse usate, e aggiornandosi in tempo reale
+22:09 <@valhalla> di default ordina per chi sta usando più CPU
+22:09 <@valhalla> per i dettagli del significato dei vari campi pagina di manuale, che sennò ci vorrebbe una lezione intera
+22:09 <@valhalla> ma se avete il computer piantato, è probabile che il colpevole sia uno dei primi nomi che saltano fuori :)
+22:10 <@valhalla> e adesso possiamo proseguire con le domande rimaste
+22:10 <@valhalla> (ah, poi q per uscire da top)
+22:11 <@diego71> < pigro> a me prima non mi faceva il kill di un processo che era stoppato
+22:11 <@valhalla> questo perché SIGINT è un segnale che il processo può elaborare
+22:11 <@valhalla> di default quello che fa è uscire subito
+22:11 <@valhalla> ma potrebbe anche fare qualcosa prima
+22:12 <@valhalla> e se è stoppato, non pu`o neanche fare l'elaborazione "ah, un SIGSTOP, allora esco"
+22:12 <@valhalla> ehm, SIGINT, non SIGSTOP
+22:12 <@valhalla> sorry
+22:12 <@valhalla> (nell'ultima riga)
+22:12 <@valhalla> altre domande?
+22:13 <@valhalla> < MrPan> htop è una versione "potenziata" del comando top ?
+22:13 <@valhalla> pi`u o meno sì, nel senso che è un programma che fa cose simili
+22:13 -!- DD3my [~DD3my@unaffiliated/dd3my] has joined #lifo
+22:14 <@valhalla> però top c'è di default nei sistemi, htop va eventualmente installato
+22:14 <@valhalla> altre domande?
+22:15 <@valhalla> < gioque> se io ho messo subito in pausa con ctrl+z un processo es (sleep 10; echo "test") e faccio fg di dopo 10 secondi mi scrive subito test, è normale o dovrebbe aspettarmi 10 secondi?
+22:15 <@valhalla> no, dovrebbe aspettarti 10 secondi
+22:16 <@valhalla> per`o quei 10 secondi comprendono il tempo impiegato a mettere in pausa il processo dopo averlo lanciato
+22:16 <@valhalla> e quelli da quando fai fg fino a quando stampa
+22:17 <@valhalla> uhm, per`o in effetti ho appena provato, esce subito
+22:18 <@valhalla> <@diego71> gioque: probabilmente ricordavo male io, la sleep aspetta 10 secondi a prescindere da ^Z
+22:19 <@valhalla> la pagina di manuale in effetti non lo dice
+22:19 <@valhalla> (ed è anche vero che nella vita reale no `e che lo si usi in questo modo)
+22:20 <@diego71> < stefano_> leggendo il man mi chiedevo cosa volesse dire: "<Left> force a screen redraw (if necessary)"
+22:20 <@valhalla> significa che se si preme il tasto "freccia a sinistra" il programma top ridisegna lo schermo
+22:21 <@valhalla> cosa che di solito fa ogni tot secondi, ma se premi lo fa nel momento in cui hai premuto
+22:22 <@diego71> < erio> sleep 10 ; echo "OK". Poi ctrl Z e poi fg ...per?? non mi stampa "ok"
+22:22 <@valhalla> in realtà te l'ha stampato quando hai fatto ctrl-z, perché non avendo le () attorno hai sospeso il primo processo (lo sleep) e quindi il secondo (l'echo) è partito
+22:22 <@valhalla> altre domande?
+22:23 -!- aldagaau [~Alain@host40-234-dynamic.50-79-r.retail.telecomitalia.it] has left #lifo []
+22:24 <@diego71> < polva> una domanda teorica. mi sfugge come mai sia necessario invocare un'altra bash per far fare due operazioni insieme.
+22:24 <@diego71> ok, ti rispondo io
+22:24 <@diego71> la comodita' e' che hai un solo processo figlio che fa tutti i comandi uno dopo l'altro
+22:25 <@diego71> quindi se fai per esempio ^Z stoppi tutta la sequenza, invece che solo il primo come nel caso di erio
+22:26 <@valhalla> e per poter raggruppare il tutto assieme ti serve un processo che abbia un numero, quindi si lancia un processo bash
+22:27 <@valhalla> altre domande?
+22:28 <@valhalla> allora, come gi`a detto all'inizio
+22:28 <@valhalla> il corso con stasera è finito, nel materiale c'è un file approfondimenti.rst con link ad un paio di documenti utili
+22:29 <@valhalla> in particolare, gli Appunti di Informatica Libera contengono fondamentalmente TUTTO :)
+22:29 <@valhalla> mentre bash guide for beginners e poi advanced bash scripting guide sono utili per approfondire l'argomento shell
+22:29 <@valhalla> settimana prossima faremo una serata dedicata a domande e risposte
+22:30 <@valhalla> così se qualcuno ha qualche domanda arretrata che gli è venuta in mente tra una serata e l'altra può farla
+22:32 <@valhalla> e detto questo, chiudo e mi metto a preparare i log
diff --git a/src/corsi/2014-linea_di_comando/log-lezione_6.log b/src/corsi/2014-linea_di_comando/log-lezione_6.log
new file mode 100644
index 0000000..be152e6
--- /dev/null
+++ b/src/corsi/2014-linea_di_comando/log-lezione_6.log
@@ -0,0 +1,175 @@
+21:04 <@valhalla> e iniziamo come al solito scaricando il materiale:
+21:04 <@valhalla> wget http://www.lifolab.org/corsi/2014-linea_di_comando/riga_di_comando-lezione_6.tar.xz
+21:04 <@valhalla> tar -x -v -f riga_di_comando-lezione_6.tar.xz
+21:05 <@valhalla> questa sera parliamo di controllo dei processi
+21:05 <@valhalla> (dimenticavo all'inizio il solito cd $DIRECTORY_SOLITA
+21:06 <@valhalla> e dopo aver scaricato e scompattato prepariamo come sempre lo spazio per fare esercizi: ``cd lezione_6 && mkdir esercizi``
+21:06 <@valhalla> (che come ricordate dalla volta scorsa, vi fa creare la directory esercizi solo se siete riusciti ad entrare nella dir lezione_6)
+21:06 <@valhalla> e poi ``cd esercizi``
+21:07 <@valhalla> la maggior parte dei comandi che abbiamo visto le altre volte finiva subito, quindi veniva lanciata, si aspettava la fine e poi si lanciava il comando successivo
+21:07 <@valhalla> per`o ovviamente non tutti i programmi sono così
+21:08 <@valhalla> alcuni stanno attivi a lungo perché elaborano dati, altri lanciano un'interfaccia grafica e stanno attivi finché non sono stati chiusi, ad esempio
+21:08 <@valhalla> per fare gli esempi, invece, stasera usiamo un comodo comando che se ne sta fermo ad aspettare per un tot di secondi: sleep
+21:09 <@valhalla> ad esempio, ``sleep 5`` si ferma per 5 secondi e poi finisce
+21:09 <@valhalla> normalmente questo blocca la shell che state usando: questo perché il comando è in "foreground"
+21:10 <@valhalla> ovvero, mentre gira quello è lui a prendersi l'input su stdin
+21:10 <@valhalla> e in ogni momento in una shell può esserci solo un comando in foreground
+21:11 <@valhalla> ci possono però essere più comandi in "background", che non hanno modo di ottenere input, ma continuano a girare fino a che non hanno finito lasciando la shell libera
+21:12 <@valhalla> un modo per mandare un programma in background è mettere & alla fine del comando (cosa che avevamo visto alla prima lezione, e vi avevo promesso spiegazione)
+21:12 <@valhalla> ad esempio, possiamo dare il comando ``sleep 100 &`` e subito dopo vediamo che la shell è libera, e ad esempio possiamo usare il comando ``jobs`` per vedere che programmi stanno girando in quella shell
+21:13 <@valhalla> vediamo che il nostro sleep 100 è in status Running, ma noi abbiamo la shell a disposizione
+21:14 <@valhalla> vedo che ci sono domande, passatemele pure
+21:15 <@diego71> < pigro> il numero visualizzato da jobs ?? il pid del job?
+21:15 <@valhalla> no, è il numero di job in quella shell
+21:15 <@valhalla> di PID invece parliamo dopo, e vediamo come si fa a vederlo
+21:17 <@valhalla> nel frattempo, sleep dovrebbe aver finito, e se lanciamo ancora ``jobs`` vediamo che viene segnato come "Done"
+21:17 <@valhalla> e poi sparisce del tutto
+21:18 <@valhalla> adesso per comodità facciamo andare due comandi alla volta: mettendo una serie di comandi tra parentesi tonde si fa partire una nuove shell che esegue quei programmi, e poi possiamo mandare il tutto in background, ad esempio
+21:18 <@valhalla> ``(sleep 60 ; date) &``
+21:18 <@valhalla> ancora ``jobs`` e vediamo che sta andando un job con tutti e due i comandi
+21:18 <@valhalla> in questo modo, quando sleep ha finito vediamo stampare cose, e ci accorgiamo subito che ha finito
+21:19 <@valhalla> mentre un programma è in foreground, possiamo passargli dei segnali
+21:19 <@valhalla> che i programmi per unix riconoscono e agiscono di conseguenza
+21:21 <@valhalla> con Ctrl-C si passa il segnale SIGINT, che interrompe il programma
+21:21 <@valhalla> i programmi poi possono intercettare questi segnali e non farsi interrompere subito, ma ad esempio chiudersi come si deve, ma dipende dal programma
+21:21 <@valhalla> ad esempio, lanciamo ``(sleep 100 ; echo "sleep")``, poi premiamo Ctrl-C
+21:22 <@valhalla> e con jobs possiamo controllare che non è rimasto niente, il processo è stato fermato
+21:22 <@valhalla> domande fin qui?
+21:23 <@valhalla> ok, proseguo
+21:23 <@valhalla> un altro segnale utile è SIGSTOP, che invece interrompe il processo senza chiuderlo
+21:23 <@valhalla> e poi lo si pu`o far riprendere
+21:24 <@valhalla> come se lo si mettesse in pausa
+21:24 <@valhalla> ad esempio ``(sleep 100 ; echo "sleep")`` poi premete Ctrl-Z
+21:24 <@valhalla> e con ``jobs`` potete vedere che c'è quel processo che risulta "Stopped"
+21:25 <@valhalla> finché lo lasciate lì non fa niente, non fa neanche passare i 100 secondi prima di chiudersi
+21:25 <@valhalla> però ci sono dei comandi coi quali si può far riprendere un processo; con ``fg`` gli si dice di tornare in foreground e ricominciare a funzionare
+21:26 <@valhalla> oppure, (per provare potete reinterrompere con Ctrl-Z un'altra volta)
+21:26 <@valhalla> con ``bg`` si manda il processo bloccato in background, e lo si fa riprendere
+21:27 <@valhalla> questo è il modo in cui si mandano in background dei processi se si è dimenticato di mettere & alla fine del comando, ad esempio
+21:27 <@valhalla> con ``jobs`` potete sempre vedere che avete un processo in background, e dopo un po' finalmente vi stamperà "sleep"
+21:27 <@valhalla> domande?
+21:28 <@diego71> < gioque> che differenza c'?? tra sleep 100; echo "sleep" e (sleep 100; echo sleep)
+21:28 <@valhalla> se si scrive ``sleep 100; echo "sleep"`` i due comandi vengono lanciati in successione dalla shell in cui si sta lavorando
+21:28 <@valhalla> con le parentesi invece viene aperta una nuova shell ed è lei a lanciare in successione i due comandi
+21:28 <@valhalla> col vantaggio che li si pu`o trattare come una cosa unica
+21:29 <@valhalla> nel nostro caso per mandarli in foreground/background, ma anche ad esempio per leggere lo stdout di tutti uno dopo l'altro
+21:30 <@valhalla> se si scrivesse solo ``sleep 100; echo "sleep" &`` sarebbe solo l'echo ad essere messo in background, sleep rimarrebbe in foreground
+21:30 <@valhalla> altre domande?
+21:31 <@valhalla> proseguo
+21:31 <@valhalla> un'altro modo che abbiamo di mandare segnali ai processi è il comando kill
+21:33 <@valhalla> di default anche lui manda il segnale SIGINT, mentre con l'opzione ``-9`` manda il segnale SIGKILL, che non può essere intercettato dai programmi e li fa chiudere ad ogni costo
+21:34 <@valhalla> ad esempio, possiamo lanciare un paio di comandi in background: ``(sleep 100 ; echo "primo") &`` e poi ``(sleep 100 ; echo "secondo") &``
+21:34 <@valhalla> ``jobs`` per vedere che ci sono
+21:34 <@valhalla> e poi con ``kill %`` possiamo mandare il segnale SIGINT al secondo dei due
+21:34 <@valhalla> e aspettando vedremo che solo il primo sarà arrivato a completamento
+21:36 <@valhalla> (altre domande?
+21:37 <@valhalla> < tiziano> cosa significa il carattere % in kill %?
+21:37 <@valhalla> sta per "ultimo processo"
+21:37 <@valhalla> lo si può usare anche con fg e bg
+21:38 <@valhalla> oltre a % e basta si pu`o anche usare %<numero> e si lavora sul job con quel numero (come viene stampato dal comando jobs
+21:39 <@valhalla> ad esempio, ``(sleep 100 ; echo "primo") &`` ``(sleep 100 ; echo "secondo") &`` e poi ``kill %1`` ucciderà il primo dei due, e lascerà andare il secondo
+21:39 <@valhalla> altre domande?
+21:39 <@valhalla> vado avanti
+21:40 <@valhalla> un altro comando utile è ps, che stampa i processi in corso, e di default stampa non solo i processi della shell in corso, ma quelli del *terminale*
+21:41 <@valhalla> ad esempio, mettiamoci un po' di roba con ``sleep 100 &`` ripetuto un paio di volte
+21:41 <@valhalla> e poi ``ps``
+21:41 <@valhalla> di default quello mostra il PID del processo, che era stato citato prima
+21:42 <@valhalla> ovvero, un identificativo univoco del processo su *tutto* il sistema
+21:42 <@valhalla> [ditemi sul canale di là per favore se mi state leggendo]
+21:44 <@valhalla> dicevo, il PID non è univoco nel tempo: dopo un certo numero riparte a prendere i numeri rimasti liberi da processi che sono stati chiudi
+21:44 <@valhalla> ma in ogni momento ci sarà un solo processo con quel PID
+21:45 <@valhalla> usando l'opzione ``-f`` di ps si hanno un po' più di dettagli utili
+21:46 <@valhalla> e in particolare UID, ovvero l'utente con i cui permessi sta girando quel processo e le opzioni con cui era stato lanciato il comando
+21:47 <@valhalla> doamnde?
+21:47 <@diego71> pigro> che differenza c'?? tra PID e PPID?
+21:47 <@valhalla> PPID è il PID del processo padre del processo elencato
+21:47 <@valhalla> ovvero del processo che ha fatto partire il processo in questione
+21:48 <@valhalla> con questo possiamo anche vedere la differenza tra ``sleep 100 ; echo "uno"`` e ``(sleep 100 ; echo "due")``
+21:49 <@valhalla> ad esempio se facciamo ``sleep 100 ; echo "uno"
+21:49 <@valhalla> ``
+21:50 <@valhalla> poi ctrl-z per sospenderlo, e poi ps
+21:50 <@valhalla> vediamo che ci sono una bash, sleep e il ps appena lanciato
+21:51 <@valhalla> (poi usiamo fg per far tornare attivo lo sleep, o bg per mandarlo in background, cos`i va avanti
+21:51 <@valhalla> se invece scriviamo ``(sleep 100 ; echo "due")``, poi sempre ctrl-z per fermarlo
+21:52 <@valhalla> a quel punto con ``ps`` vediamo che ci sono due bash, uno sleep e poi ps
+21:52 <@valhalla> e anzi, se usiamo ps -f vediamo che il parent della seconda bash e del ps è la prima bash
+21:52 <@valhalla> mentre sleep ha come parent la seconda bash
+21:52 <@valhalla> altre domande?
+21:54 <@valhalla> ok, dovrei aver finito il backlog delle domande a cui avevo detto rispondo dopo
+21:54 <@valhalla> se manca qualcosa, perfavore rifatela
+21:54 <@valhalla> intanto vado avanti dicendo che:
+21:54 <@valhalla> il PID pu`o essere usato anche come parametro di kill, per mandare segnali a processi non necessariamente sulla stessa shell
+21:55 <@valhalla> ad esempio, diamo il solito ``sleep 100 &``
+21:55 <@valhalla> vediamo che ci stampa il numero di job tra parentesi e dopo il suo pid
+21:55 <@valhalla> possiamo controllare che lo sia con ps
+21:55 <@valhalla> e poi possiamo ucciderlo con ``kill $PID``
+21:55 <@valhalla> dove ovviamente al posto di $PID metterete il numero visto prima
+21:56 <@valhalla> per trovare il PID di processi che non conoscete si usa sempre ps
+21:56 <@valhalla> con ``ps -e -f`` si vedono tutti i processi del sistema
+21:56 <@valhalla> anzi, meglio ``ps -e -f | less`` :)
+21:57 <@valhalla> oppure ``ps -e -f | grep $NOME_DEL_PROGRAMMA_CHE_VI_SI_E_PIANTATO`` :)
+21:58 <@valhalla> oppure in qualche caso è utile ``-u $NOME_UTENTE`` al posto di ``-e`` per vedere solo i processi di qualche utente
+21:58 <@valhalla> domande?
+22:00 <@diego71> < pigro> se per errore invio il kill al PPID
+22:00 <@valhalla> pigro: uccidi il PPID (e a catena di solito anche tutti i suoi figli)
+22:01 <@valhalla> a meno che si cerchi di killare un processo di qualche altro utente, nel qual caso lo si può fare solo se si è root
+22:01 <@valhalla> altre domande
+22:01 <@diego71> < gioque> per mettere in pause (tipo ctrl+z) un processo che non sia l'ultimo? (tipo se ho tre jobs e volgio mettere in stato stopped [non killed] il n 2 come faccio?)
+22:02 <@valhalla> porti in foreground il processo che vuoi stoppare con ``fg %2`` (ad esempio), e poi usi ctrl-z
+22:02 <@valhalla> altre domande?
+22:03 <@diego71> < polva> valhalla, c'era quella domanda su come distinguere tra shell e processo
+22:03 <@valhalla> in che senso distinguere tra shell e processo?
+22:04 <@diego71> < polva> riposto: ! valhalla ha detto che usare le parentesi fa avviare una nuova shell. a me si avvia sempre nella stessa. parte solo un altro comando
+22:04 <@valhalla> avevamo visto l'esempio prima che con ps faceva vedere che tra i processi attivi c'era una nuova bash
+22:05 <@valhalla> dalle 21:49 in poi nel log
+22:05 <@valhalla> non si apre un nuovo *terminale*, solo una nuova bash all'interno nello stesso terminale, se era questo il tuo dubbio
+22:05 <@valhalla> altre domande?
+22:07 <@diego71> < tiziano> che segnale viene emesso esattamente con ctrl-z?
+22:07 <@valhalla> SIGSTOP
+22:08 <@valhalla> ultimo comando per la serata, il comando ``top``
+22:08 <@valhalla> vi fa vedere i processi attivi in ordine di risorse usate, e aggiornandosi in tempo reale
+22:09 <@valhalla> di default ordina per chi sta usando più CPU
+22:09 <@valhalla> per i dettagli del significato dei vari campi pagina di manuale, che sennò ci vorrebbe una lezione intera
+22:09 <@valhalla> ma se avete il computer piantato, è probabile che il colpevole sia uno dei primi nomi che saltano fuori :)
+22:10 <@valhalla> e adesso possiamo proseguire con le domande rimaste
+22:10 <@valhalla> (ah, poi q per uscire da top)
+22:11 <@diego71> < pigro> a me prima non mi faceva il kill di un processo che era stoppato
+22:11 <@valhalla> questo perché SIGINT è un segnale che il processo può elaborare
+22:11 <@valhalla> di default quello che fa è uscire subito
+22:11 <@valhalla> ma potrebbe anche fare qualcosa prima
+22:12 <@valhalla> e se è stoppato, non pu`o neanche fare l'elaborazione "ah, un SIGSTOP, allora esco"
+22:12 <@valhalla> ehm, SIGINT, non SIGSTOP
+22:12 <@valhalla> sorry
+22:12 <@valhalla> (nell'ultima riga)
+22:12 <@valhalla> altre domande?
+22:13 <@valhalla> < MrPan> htop è una versione "potenziata" del comando top ?
+22:13 <@valhalla> pi`u o meno sì, nel senso che è un programma che fa cose simili
+22:14 <@valhalla> però top c'è di default nei sistemi, htop va eventualmente installato
+22:14 <@valhalla> altre domande?
+22:15 <@valhalla> < gioque> se io ho messo subito in pausa con ctrl+z un processo es (sleep 10; echo "test") e faccio fg di dopo 10 secondi mi scrive subito test, è normale o dovrebbe aspettarmi 10 secondi?
+22:15 <@valhalla> no, dovrebbe aspettarti 10 secondi
+22:16 <@valhalla> per`o quei 10 secondi comprendono il tempo impiegato a mettere in pausa il processo dopo averlo lanciato
+22:16 <@valhalla> e quelli da quando fai fg fino a quando stampa
+22:17 <@valhalla> uhm, per`o in effetti ho appena provato, esce subito
+22:18 <@valhalla> <@diego71> gioque: probabilmente ricordavo male io, la sleep aspetta 10 secondi a prescindere da ^Z
+22:19 <@valhalla> la pagina di manuale in effetti non lo dice
+22:19 <@valhalla> (ed è anche vero che nella vita reale no `e che lo si usi in questo modo)
+22:20 <@diego71> < stefano_> leggendo il man mi chiedevo cosa volesse dire: "<Left> force a screen redraw (if necessary)"
+22:20 <@valhalla> significa che se si preme il tasto "freccia a sinistra" il programma top ridisegna lo schermo
+22:21 <@valhalla> cosa che di solito fa ogni tot secondi, ma se premi lo fa nel momento in cui hai premuto
+22:22 <@diego71> < erio> sleep 10 ; echo "OK". Poi ctrl Z e poi fg ...per?? non mi stampa "ok"
+22:22 <@valhalla> in realtà te l'ha stampato quando hai fatto ctrl-z, perché non avendo le () attorno hai sospeso il primo processo (lo sleep) e quindi il secondo (l'echo) è partito
+22:22 <@valhalla> altre domande?
+22:24 <@diego71> < polva> una domanda teorica. mi sfugge come mai sia necessario invocare un'altra bash per far fare due operazioni insieme.
+22:24 <@diego71> ok, ti rispondo io
+22:24 <@diego71> la comodita' e' che hai un solo processo figlio che fa tutti i comandi uno dopo l'altro
+22:25 <@diego71> quindi se fai per esempio ^Z stoppi tutta la sequenza, invece che solo il primo come nel caso di erio
+22:26 <@valhalla> e per poter raggruppare il tutto assieme ti serve un processo che abbia un numero, quindi si lancia un processo bash
+22:27 <@valhalla> altre domande?
+22:28 <@valhalla> allora, come gi`a detto all'inizio
+22:28 <@valhalla> il corso con stasera è finito, nel materiale c'è un file approfondimenti.rst con link ad un paio di documenti utili
+22:29 <@valhalla> in particolare, gli Appunti di Informatica Libera contengono fondamentalmente TUTTO :)
+22:29 <@valhalla> mentre bash guide for beginners e poi advanced bash scripting guide sono utili per approfondire l'argomento shell
+22:29 <@valhalla> settimana prossima faremo una serata dedicata a domande e risposte
+22:30 <@valhalla> così se qualcuno ha qualche domanda arretrata che gli è venuta in mente tra una serata e l'altra può farla
+22:32 <@valhalla> e detto questo, chiudo e mi metto a preparare i log