mercoledì 5 dicembre 2007

BlackMailer

La nuova generazione di virus ricattatori.

Questa sembra essere la nuova frontiera dei virus: Costringere gli utenti ad accettare l'infezione, del proprio sistema, punendo chi non vuole cedere.
Questa nuova schiera di malware sfrutterebbe la debolezza del primo, e forse fondamentale, servizio storicamente offerto dalla rete; la E-Mail. La stessa debolezza intrinseca, del protocollo SMTP, che rende, già oggi, tanto difficile proteggersi dallo Spam. Qui non è un discorso di bachi di un particolare software.

Questi ingeniosi software userebbero chi è già infetto per intasare la mail di chi ancora resiste. L'unica maniera che uno ha, a questo punto, di poter tornare ad usare liberamente la sua casella è lasciarsi infettare; in questo modo il "virus" segnalerà agli altri infetti la vostra resa e questi non vi seccheranno più. Adesso anche voi, nuovi infetti, intaserete le mailbox dei "sani". Vi faccio notare che con questa tecnica non v'è antivirus che regga, siete voi, infatti, ad accettare l'installazione del virus.

La mole di traffico prodotta da questi malware potrebbe, inoltre, creare problemi alla rete stessa.

Per ora questo software è stato creato solo in un laboratorio, dove si studiano le debolezze dei sistemi informatici, ma la realizzazione di un analogo, a scopo "pratico", non è troppo difficile.

Per saperne di più: http://sicurezza.html.it/articoli/leggi/2450/il-virus-perfetto/1/.
Mi sono reso conto che ho scritto questo post in maniera barbina... perdonatemi! Chiedo umilmente scusa!

sabato 1 dicembre 2007

Il culo delle Mucche...


Per la serie "la madre degli idioti è sempre gravida" e "la realtà supera qualsiasi immaginazione"; ecco come un Premio Nobel e un Primo Ministro si dedicano alle scorreggie del bestiame:
Il premio Nobel Barry J. Marshall ha progettato un catalizzatore anale da innestare nell' ano degli animali per abbattere le emissioni gassose, mentre il primo ministro australiano John Howard ha proposto l' innesto di condutture a tenuta stagna che dall' ano degli animali portino le emissioni direttamente ai rigassificatori più vicini.
Da Wikipedia, L'enciclopedia libera. alle 20:13, 1 Dicembre 2007 http://it.wikipedia.org/w/index.php?title=Flatulenza&oldid=12502724

Vabbè che parte dell'effetto serra a da attribuirsi anche alle flatulenze degli animali da allevamento... ma catalizzare il culo delle Vacche mi pare troppo! Povere Bestie! Con tutto quello che immettiamo in atmosfera con le fabbriche e tutto il resto preoccuparsi delle perne degli animali lo trovo ridicolo e inutile, scorreggiano come hanno sempre fatto e sempre faranno! Ed è giusto che sia così!

Per quello che riguarda la malsana proposta del Primo Ministro Australiano, io vorrei ricordargli che anche lui le molla... e, prima di procedere ad "intubare" tutto il bestiame di un continente, sarebbe giusto fare un esperimento/prova... visto che l'idea e sua potrebbe provare lui per primo il guinzaglio anale che la sua mente geniale ha partorito...

Meditiamo ragazzi... meditiamo...

Debian etch - XFCE4 - gnome-screensaver

Da un poco di tempo ho adottato Debian etch come SO principale. Di default questa distribuzione usa GNOME come Desktop-Manager. Niente da ridire su GNOME, per carità, ma preferisco sempre XFCE di cui mi sono innamorato lavorando su macchine datate. Sulla "Vecchia Signora" (SlackWare) XFCE era installato di default. Su Debian si installa in un lampo:
:~$ apt-get update
:~$ apt-get install xfce4
Per il sistema base, se vogliamo proprio tutto, ed io lo consiglio, allora aggiungiamo un:
:~$ apt-get install xfce4-goodies
Ovviamente essendo loggati come root.
Mi sono accorto poi che XFCE così installato non avviava nessun gestore di screensavers. Perché, mi son detto, andare a installare roba nuova quando ne ho già uno pronto sull'hd? E ho deciso di usare quello di GNOME.
I file eseguibili che ci interessano sono 2:
  • /usr/bin/gnome-screensaver
  • /usr/bin/gnome-screensaver-preferences
Il primo è il demone (o drago!?:-)) che effettivamente gestisce lo screensaver, il secondo è il tool grafico di GNOME che configura il primo (ma lo si capiva dal nome!).

Avviamo il gestore:
Per far partire gnome-screensaver all'avvio della sessione XFCE usiamo xfce4-autostart-editor:
:~$ xfce4-autostart-editor
Ci apparirà una semplice interfaccia grafica.
Clicchiamo su Aggiungi e compiliamo i campi che ci vengono presentati: i primi due (Nome e Descrizione) sono puramente descrittivi, potete quindi inserire quello che vi pare, il terzo (Comando) invece è il comando da eseguire, inseriremo quindi: /usr/bin/gnome-screensaver .
Clicchiamo su OK e vedremo apparire una nuova voce sulla lista delle applicazioni all'avvio. A questo punto clicchiamo su Chiudi e dedichiamoci ad "altro".

Launcher per le "preferenze"
:
Adesso non ci resta che creare un nuovo launcher sul pannello per gnome-screensaver-preferences. Tasto destro del mouse sul pannello e scegliamo "Add new item". Doppio click su "Launcher". Completiamo i campi. Come al solito l'unica cosa fondamentale è che il campo Comando sia impostato ad /usr/bin/gnome-screensaver-preferences . Confermiamo tutto e siamo a cavallo!

giovedì 29 novembre 2007

I Processi

Questo è un argomento che non riguarda solamente Unix, e derivati, ma l'informatica in generale. Ormai tutti, o quasi, i sistemi operativi sono multitasking, e quindi gestiscono i processi.
Cercherò di essere il più possibile chiaro per chiunque, a costo anche di commettere qualche imprecisione.

Programma:
Prima di addentrarci oltre ci viene utile, per poi capirci meglio, darci una "definizione" di cos'è un programma. Possiamo considerare un programma come: una sequenza, logicamente ordinata, di semplici operazioni, che un calcolatore è in grado di eseguire, che descrive un modo per ottenere un dato output partendo da un dato input.
Ad un informatico questa definizione balorda farebbe venire la pelle d'oca per la sua imprecisione. In realtà a noi non serve, per il momento, una definizione "assoluta" e rigorosa di programma. Ci basta arrivare ad un punto di partenza comune per poi continuare il nostro discorso. A questo punto ci viene in aiuto il famoso discorso della ricetta, che poi ci porteremo dietro per continuare a capirci. Consideriamo il programma come una ricetta di cucina. La ricetta/programma è un'entità statica, se ne stà lì, sul suo foglio che potremmo paragonare al file o alla scheda perforata, ad aspettare che qualcuno la esegua. A questo punto noi che seguiamo/eseguiamo la ricetta potremmo essere paragonati al sistema/calcolatore. Se la ricetta comprendesse delle uova, una frittata ad esempio, noi potremmo pensare queste uova come dei dati. Notiamo che le uova non stanno sul foglio, infatti la ricetta ci dice che ci servono dei dati del tipo uovo, i dati veri sono le uova che noi estraiamo dal frigo. Notiamo anche che noi, per fare la frittata, non mettiamo le uova (uova dato effettivo intento, quelle fisiche) nel foglio della ricetta e, come per magia, ne esce una frittata. Noi, che siamo il sistema, prendiamo le uova e seguiamo le istruzioni della ricetta. La ricetta è una serie di istruzioni, logicamente ordinate, che noi seguiamo per produrre, a partire dal nostro input uova, il nostro output frittata.
Il programma è come una ricetta di cucina.

Il Time Sharing:
Letteralmente la "condivisione del tempo". A livello umano sembra una cosa tanto ovvia da sembrare assurda e insensata.
Un calcolatore (o computer, come preferite) è composto da diverse parti:
  • Processore (ALU)
  • Memoria (RAM)
  • Dispositivi esterni o periferiche
Nei dispositivi esterni vanno a cadere anche: dischi rigidi, schermi, floppy, lettori ottici, schede audio, ecc... Insomma non solo la "roba" che stà al di fuori del case. Tutti i computer sono infatti basati su uno stesso schema: La macchina di Von Neumann. Anche se in questa astrazione si elencano a volte anche le unità di Input/Output, la macchina è costituita nel suo intimo solo da processore e memoria. La forza di questa macchina è proprio nella sua semplicità!

Non perdiamoci e vediamo di focalizzare il problema dei tempi. Non tutte le parti del calcolatore sono veloci allo stesso modo: il primato spetta al processore, poi viene la memoria (solo RAM intendiamo) e infine tutte le periferiche. Anche se fra le varie periferiche ci possono essere notevoli differenze di velocità per il processore questo non conta. Qualsiasi periferica, anche la più veloce, è talmente lenta rispetto al cuore della macchina che non differenza.

Vediamo ora cosa un programma quando gira:
  • dei calcoli sui dati che ha a disposizione
  • Acquisisce dati (Input).
  • Emette dei dati (Output).
  • Scrive e legge dalla Memoria (RAM).
Fare dei calcoli massivi vuol dire fruttare bene la macchina. Leggere e scrivere dalla memoria "rallenta" un poco le operazioni ma è ancora accettabile e comunque indispensabile (gli informatici potrebbero avere da ridire; avete ragione ma certo non scrivo ste robe per voi!). Le operazioni di Input/Output sono talmente lente da costringere il processore a tempi morti scandalosi. Queste pause forzate sono talmente lunghe che il processore potrebbe tranquillamente eseguire la parte di calcolo di un'altro programma o più. Ed ecco l'ideona. Sospendere l'esecuzione di un programma in attesa di I/O e cominciare, o continuare, l'esecuzione di uno che invece deve sfruttare a pieno la CPU.

Ecco cosa si intende per Time Sharing: lo sfruttamento intelligente e massimizzato del tempo della CPU. Questo rendimento alto lo si ottiene facendo eseguire ad un processore un certo numero di programmi contemporaneamente. Ovviamente una singola CPU esegue il codice di un programma alla volta, ma cambia programma ogni volta che quello che stà eseguendo richiede un lento I/O. Più programmi condividono la stessa CPU.
e.g.: in questo momento 109 programmi si stanno dividendo il tempo della mia CPU. Stò fruttando le capacità del processore ad un 15% scarso. Non ho un supercomputer, anzi!
Torniamo al nostro esempio della ricetta culinaria:
Stiamo eseguendo la ricetta/programma "pastasciutta". Ad un certo punto ci troviamo ad eseguire l'operazione "fare bollire l'acqua". Se non adottassimo il Time Sharing staremmo li a girarci i pollici davanti alla pentola sul fuoco per buoni 20 minuti. Tempo sprecato visto che noi dopo dobbiamo eseguire la ricetta "frittata". Allora decidiamo di puntare il timer del forno e di dedicarci alle nostre uova. Tanto in 20 minuti ci portiamo bene avanti con la frittata. Poi, al suonare del timer, buttiamo la pasta e mescoliamo e ci tocca "aspettare" ancora, allora andremo avanti con la frittata. Oggi vanno tanto di moda i programmi televisivi dedicati alla cucina, osservate uno chef dei tanti che appaiono in TV e vedrete che realizza un Time Sharing molto spinto.

Processo:
Adesso però ci serve fare una distinzione fra programma e "programma in esecuzione". Se prima davamo in pasto alla CPU un programma alla volta questa distinzione non aveva senso. Adesso invece dobbiamo distinguere tra la sequenza di istruzioni presente sul disco (o su un supporto qualsiasi) e quell'entità, attiva e vitale, che gira sul sistema di cui il programma è una parte. Sia ben chiaro che la distinzione non è mera filosofia informatica, ci sono delle precise necessità tecniche che ci portano a farla:
  • Il "set" di dati che un "programma in esecuzione" si porta appresso.
  • Il "punto" dell'esecuzione al quale siamo arrivati.
  • Quale input e quale output ci ha costretti a cambiare programma.
Questa è una lista volutamente semplicistica, ma già rende l'idea.
Ed ecco che con il Time Sharing compare una nuova entità: il processo. Da ora in poi non parleremo più di "programma che gira" su un sistema, ma di processo che, girando sul sistema, esegue un programma. Ad ogni processo è associato un programma da eseguire. Il sistema gestisce i processi. Un processo è composto da molte altre cose oltre che dal programma. Per fare un esempio i dati. Vi sarà capitato sicuramente di eseguire due processi che usano lo stesso programma. Capita spesso con i browser web. Se vi trovate con una marea di finestre aperte dello stesso programma avete davanti agli occhi un esempio di molti processi, uno per finestra, che eseguono lo stesso programma. Infatti sul disco avete un solo file eseguibile del vostro browser preferito. Allora cosa cambia? Cambia l'indirizzo web che avete specificato (input) e la pagina che il browser vi mostra (output). A questo punto è legittimo, e giusto, pensare che i vari processi eseguano lo stesso programma trattando però un set di dati diversi. Ed è importante che il sistema operativo si ricordi quale processo a chiesto la tale pagina, sarebbe fastidioso digitare su una finestra e vedere che la pagina si apre su un'altra a caso. Eppure se ci si riferisse al programma non si avrebbe modo di distinguere le sue varie istanze in esecuzione. Ma questa è già un visione paradossalmente ottimistica. In realtà le cose sono ben più complesse. Ogni processo è ad un punto diverso dell'esecuzione del programma, anche se il programma è lo stesso. Bisogna anche che un processo si ricordi dove è arrivato ad eseguire il programma.

Ritorniamo in cucina:
Quando il timer del forno suona dobbiamo ricordarci che eravamo arrivati al punto "butare la pasta nell'acqua", ad esempio, e non a quello "aggiungere sale".
Se stiamo anche cucinando due frittate diverse, una con gli spinaci e una con piselli e tonno (che vada giù na roba del genere?), dobbiamo ricordarci quali sono gli ingredienti che associamo ad una esecuzione e quali all'altra della stessa ricetta, onde evitare di fare macelli all'istruzione comune: "aggiungere gli ingredienti a vostra scelta".

Scendere nei particolari di cosa , e come, un processo richiederebbe molto tempo e molte parole. Per arrivare fin nell'intimo di come si realizza il Time Sharing bisognerebbe partire da lontano ed affrontare un sacco di problemi. Basti sapere che ancora oggi si cercano vie nuove e sempre più efficaci. Non tutti i sistemi usano la stessa identica filosofia/metodologia. Non mi sembra il caso ora. Spero comunque che siamo riusciti a farci un'idea generale.

martedì 27 novembre 2007

Time to leave!

Sta volta voglio affrontare l'uso di un comando/programma di Unix che alcuni potrebbero considerare un poco anacronistico. Stò parlando di leave. Un programmino che gira in background e che ci aiuta a non perdere la cognizione del tempo. In sostanza leave è una sveglia/timer.

Si può settare leave per avvisarci ad una data ora o fra un tot di tempo.
:~&leave +15
Per ricordarci di andarcene fra 15 minuti.
:~&leave 2115
Per ricordarci che dobbiamo sortire alle 21:15.
Se dovessimo invocare leave senza argomenti sarebbe lui stesso a chiederci esplicitamente quando avvertirci.
:~$ leave
When do you have to leave?
La maniera per rispondere è la stessa con cui passare i parametri direttamente a linea di comando. La conferma dell'avvenuto avvio di leave sarà, in tutti i casi, sempre una cosa del tipo:
Alarm set for Tue Nov 27 20:00. (pid 6124)
Mi sembra che non ci sia nulla da spiegare!
Una volta settato leave lascierà l'utente libero di lavorare, alla shell ovviamente, fino a 5 minuti prima dell'ora X. A cinque minuti partirà il primo avviso. Ad 1 minuto il secondo. All'ora X e ogni minuto successivo leave disturberà l'user ricordandogli che deve andarsene. Solo dopo 10 minuti dallo scadere del timer leave si cheterà!

I mesaggi di leave:
You have to leave in 5 minutes.
Just one more minute!
Time to leave!
[...]
That was the last time I'll tell you. Bye.
Dopo lo scadere certe versioni/implementazioni ripetono sempre "Time to leave!" altre invece si sbizzarriscono con messaggi più vari.

Bisogna ricordarsi che leave è un programma/processo "normale" e quindi dipende dall padre. Insomma, se chiudete la shell da cui lo avete avviato chiudete anche lui, inoltre non usa files per memorizzare le impostazioni che quindi sono "labili".
Certe versioni/implementazioni usano accompagnare i messaggi anche con il suono della campanella di sistema (beep). A parole sembra una vaccata ma vi giuro che funziona... stressa da morire!

leave usa un modo abbastanza singolare per interpretare gli orari che gli passate, mi spiego meglio; se siamo di pomeriggio e diamo un comando del tipo:
:~$ leave 0830
Alarm set for Tue Nov 27 20:30. (pid 7071)
leave non intende "0830" come le otto e trenta minuti del mattino successivo ma come le otto e mezza della sera stessa (le venti insomma). Lo si capisce anche dall'output di conferma.

Non tutti i sistemi, ormai, adottano leave nella installazione "standard".
Nel caso di Debian etch si può seguire la più canonica delle vie:
:~$apt-get update
:~$apt-get install leave

venerdì 23 novembre 2007

Google: dopo la rete la luna!

Google e X PRIZE Foundation stanziano un totale di 130milioni di dollari per la migliore missione lunare robotica privata.

Tutti possono partecipare al concorso e spedire il loro robottino sulla superfice della luna. Ovvio che sono richieste delle prestazioni minime per avere accesso ai premi. C'è tempo fino al 2012 o, se per allora nessuno avesse soddisfatto BigG & CO, anche fino al 2015. Il problema è: chi ha i soldi per tentare un'impresa del genere?

Se pensate che stia scherzando: http://www.googlelunarxprize.org/lunar/intl/ita/.

Tra gli obbiettivi "secondari" della missione anche quello di filmare/fotografare i rottami/residui delle missioni Apollo!

Vi pare poco?

giovedì 22 novembre 2007

screen: terminale multitasking!

Unix (ed i sistemi Unix-Like) è un sistema operativo multitasking e multiutente. L'interfaccia utente "preferenziale" di Unix è una Shell che gira su un terminale. La Shell è un'interfaccia a caratteri del tipo "linea di comando". Passi che più utenti si possono collegare contemporaneamente al sistema attraverso terminali, ma come fà un singolo utente a far girare più programmi sulla sua shell? Oggi come oggi, nell'era della finestra, sembra impossibile vero? Forse a qualcuno anche inutile!? Avvio il mio bel Server X col mio Desktop/Window Manager preferito e sono a cavallo!... e se mi devo connettere da remoto con ssh ad esempio?!? Situazione, questa, che emula bene l'uso dei vecchi terminali fisici. Nessun problema, una soluzione è screen!

Una delle "sciccherie" di screen è prorio quella di fornirci un terminale multitasking. Cioè un terminale in cui possiamo eseguire più programmi contemporaneamente. Passando dall'uno all'altro senza problemi e, sopratutto, senza interrompere il loro funzionamento.

Screen lavora a sessioni. Una sezione di screen può contenere diversi programmi in esecuzione (processi). Una sezione "nasce" con una chiamata a screen. Una sezione "muore" con la chiusura dell'ultimo processo ad essa associato.
Screen avvia una nuova sessione quando lo si chiama specificando un programma da avviare o senza nessun parametro (in questo caso avvia una istanza della shell di default *).
:~$screen
Avvio una finestra contenente una shell.
:~$screen joe
Avvio una finestra contenente joe.
Consideriamo screen come un gestore di finistre a tutto schermo. Ogni finestra contine un programma. Una sessione contiene più finestre (almeno una).
Passo successivo, necessario prima di passare ad un poco di pratica, è capire la relazione tra sessione e soket. Chiariamoci da subito che questa nomenclatura è propria di screen e, quindi, può risultare ingannevole:
  • Soket: ciò che screen chiama soket è in relatà, per il SO, una PIPE con nome.
  • Sessione: una sessione di screen non è altro che un processo del SO che esegue screen.
Fatti i dovuti chiarimenti ora continuiamo ad usare la terminologia di screen. Per screen ogni sessione è associata ad un socket. Questo fatto è necessario per un uso più avanzato di screen di quello che voliamo fare noi, almeno per ora. Tuttavia dovremo comunque conoscere questo aspetto per poter controllare le sessioni che andiamo ad avviare. Allora, schematizzando:
1 soket=>1 sessione=> N finestre=> N programmi.
Per ragioni di sicurezza evitate sempre di abbandonare il sistema con sessioni di screen aperte. Chiudetele tutte se lasciate la macchina accessa, e sopratutto se rimane connessa alla rete. Screen è molto potente ma comporta dei rischi. Questo non deve scoraggiare il suo uso ovviamente. Per ora teniamoci a mente che screen non realizza soltanto un terminale multitasking.

Passiamo alla pratica:
Abbiamo visto due maniere per avviare screen. Per ora, onde evitare confusioni, useremo quella con parametro. Usiamo un programma "vistoso", tipo mc, per aiutarci.
:-$screen mc
A prima vista è tutto come se avessimo avviato normalmente mc. Ora però premiamo ctrl+a e successivamente d. Vedremo che torniamo alla shell di "partenza" con questo output:
:~$ screen mc
[detached]
:~$
Che cosa è successo?
  • Abbiamo, tramite il primo comando, avviato una sessione di screen nella quale la prima finestra contiene un mc.
  • Abbiamo usato un comando interattivo di screen per distaccare la sessione dal terminale.
Questo secondo punto merita delle spiegazioni. Per "comandare" le finestre di screen non si usa il mouse ma la tastiera. Per impartire a screen un comando lo si deve "avvertire" prima. Avvertirlo significa specificare che l'input è per lui e non per il programma che gira nella finestra. Per "avvertire" screen che stiamo per impartirgli un comando si usa la combinazione di tasti ctrl+a **. A questo punto diamo il comando d che sta per "detach", è un poco come mettere in pausa un'intera sessione. Cioè come accontonarla temporanemente. Mentre la sessione è staccata, e noi quindi non stiamo lavorando in nessuna finastra, il nostro mc continua a girare indisturbato; se fosse un wget continuerebbe a scaricare ad esempio. Qui già si possono intuire altre potenzialità di screen.

Ora concentriamoci sulle soket, dovremmo averne una a questo punto. Come faccimao a controllare?
:~$screen -ls
oppure
:~$screen -list
Ci dovrebbe apparire un otput del tipo:
There is a screen on:
4596.pts-0.stellascura (Detached)
1 Socket in /var/run/screen/S-mesillo.
Analiziamo in particolare la seconda riga. Questa descrive la maniera di nominare le soket/sessioni di screen. Dobbiamo leggerla come:
[pid di screen].[terminale a cui è attaccata la sessione].[hostname] ([stato])
Chiariamo alla menopeggio il concetto di attaccato e staccato per una sessione rispetto ad un terminale. Quando una sessione è attaccata ad un terminale vuol dire che una delle sue finestre lo "occuperà". Sò che è riduttivo e in parte inesatto ma per ora vediamola così. Ricordiamoci che un processo (programma) può benissimo continuare a girare anche quando è staccato da un terminale.

Adesso abbiamo la nostra sessione distaccata e vorremmo riattaccarla. Per fare ciò si usa l'opzione -r, che può essere accompagnata da parametro oppure no. Se si usa r senza parametro screen attaccherà al terminale in uso la prima sessione disponibile. Nel nostro caso v'è n'è una solamente quindi ci và più che bene.
:~$screen -r
Se, invece, avessimo più sessioni potremmo usare un comando del tipo:
:-$screen -r 4596.pts-0.stellascura
o se volessimo usare solo il pid della sessione:
:-$screen -r 4596
potremmo, addirittura, specificare solo il nome del terminale. Screen è "intelligente" e, se non forniamo informazioni ambigue (eg.: due sessioni con lo stesso terminale), riesce spesso a capire cosa vogliamo.
A questo punto vedremo riapparire il nostro mc. Chiudiamolo e vedremo un output a shell del tipo:
:~$ screen -r
[screen is terminating]
mesillo@stellascura:~$ screen -list
No Sockets found in /var/run/screen/S-mesillo.

mesillo@stellascura:~$
Il successivo controllo delle soket ci dirà che nessuna sessione è apera.
Vediamo ora come dare un nome alle sessioni per meglio riconoscerle senza doversi ricordare i pid.
:~$screen -S pippo mc
L'opzione in questione è -S con la S maiuscola. Ora distacchiamo la sessione e controlliamo le soket attive. Osserveremo un otput del tipo:
There is a screen on:
8652.pippo (Detached)
1 Socket in /var/run/screen/S-mesillo.
Possiamo riattacare la sessione con:
:~$screen -r pippo
Credo che con molte sessioni attive sia comoda questa possibilità.

Ora è il momento di aggiungere delle nuove finestre alla nostra sessione. Per farlo usiamo il comando interattivo c quindi premiamo ctrl+a e c. Ci apparirà una shell (quella di default *), in una nuova finestra, attraverso la quale possiamo avviare il programma che preferiamo. Per comodità di chi scrive ammettiamo di avviare joe.
Possiamo spostarci da una finestra all'altra con diversi comandi. Tenete conto che screen tratta le finestre come se fossero inserite in una lista. Ogni finestra ha il suo numero. La prima che avete avviato sarà la numero 0, la seconda la numero 1, ecc... . La lista è ciclica, ossia dopo l'ultima finestra si torna alla prima e, di conseguenza, prima della prima c'è l'ultima.
Fatte le dovute premesse ecco la lista dei comandi.
  • n: ci si sposta alla finestra successiva.
  • p: ci si sposta alla finestra precedente.
  • n: (dove n è un numero da 0 a 9) ci si sposta alla finestra numero n.
Quindi, nel nostro esempio: con p torniamo a mc, con n andiamo a joe, con 0 ancora a mc e con 1 a joe di nuovo. Ben s'intende che, essendo questi comandi dinamici, vanno tutti, e sempre, preceduti da ctrl+a.

Chiudere una finestra non è difficile, basta chiudere il programma, o la shell (exit), che essa contiene. Quando chiudiamo l'ultima finestra di una sezione terminiamo anche la sezione stessa ed il suo soket scompare.

Ora sappiamo:
  • Avviare una sezione (con nome anche).
  • Creare delle finestre.
  • Muoverci tra le finestre.
  • Chiudere le finestre e le sessioni.
  • Staccare una sessione.
  • Controllare le sessioni aperte.
  • Attaccare una sessione.
Abbiamo visto solo parte delle funzioni di screen. Ed abbiamo imparato a sfruttarlo solo in maniera base. Infatti screen è uno strumento potente quasi al limite del pericoloso a volte. Parte delle potenzialità di screen si sono certamente intuite fin qui, ma per ora ci accontentiamo del nostro bravo terminale multitasking!

Teniamo sempre a mente che screen altera un poco il comportamento dei programmi. Basti pensare al fatto che si impadronisce della combinazione ctrl+a. Alle volte è anche costretto a modificare, anche se solo in modo temporaneo, l'otput dei programmi per avvisarci di qualcosa. Proprio per ovviare a questi problemi screen prevede l'uso di file di configurazione che, volendo, ne alterano, anche di molto, il comportamento per poterlo adattare alle varie esigenze. Per ora però non vado oltre. Se non resistite alla curiosità non vi resta che dare un man screen.



Utenti Debian etch: potrebbe capitare che sulla vostra distribuzione screen non sia incluso di default... il procedimanto per installarlo è quello canonico!
:~$su
passwd:
:~$apt-get update
:~$apt-get install screen
Non dovrebbe nemmeno chiedervi di risolvere delle dipendenze.

(*)Controllare la shell di default:
:~$echo $SHELL
(**) Dovessimo mai passare al programma nella finestra proprio ctrl+a basterebbe usare ctrl+a e a.