Bash on Melabit

Come controllare lo spazio occupato sul Mac con il Terminale: gli strumenti grafici

Tue, 16 May 2023 06:00:00 +0000

Nel post di qualche giorno fa ho presentato du, un comando per il Terminale che consente di visualizzare lo spazio occupato sul disco da una data cartella e da tutte le cartelle contenute al suo interno. Se la cartella in questione è la vostra Home, potrete usare du per visualizzare rapidamente lo spazio occupato da tutti i vostri file ed eventualmente intervenire per cancellare o spostare ciò che non vi serve.

Il comando du può essere usato anche per visualizzare le dimensioni delle cartelle al di fuori della Home che contengono il sistema operativo, i file di supporto, le applicazioni e così via, ma per farlo dovete disporre di un account amministrativo e premettere a du il solito comando sudo, che vi fa diventare l’amministratore onnipotente del sistema. Finché vi limitate a guardare non c’è nessun pericolo, ma non provate a cancellare i file al di fuori dalla vostra Home a meno che non sappiate esattamente cosa state facendo.

Interfacce testuali

Il comando du è installato di default in macOS e va usato nel Terminale spostandosi nella cartella di interesse con cd ed eseguendo du seguito dagli opportuni switch. In alternativa, si può aggiungere alla fine del comando il percorso completo della cartella che ci interessa, come ho fatto qui,

ma personalmente trovo più comodo spostarmi prima nella cartella di interesse e poi eseguire du.

Con un minimo di pratica controllare una o l’altra cartella a colpi di cd e du è velocissimo, in particolare grazie alle funzioni di autocompletamento già presenti in bash e diventate ancora più efficienti in zsh (che da alcuni anni è la shell di default di macOS).

Tuttavia, mi rendo conto che molti utenti sono intimiditi dal Terminale e dalla necessità di inserire i comandi a mano. Pertanto, in questa seconda parte voglio presentare alcuni strumenti dotati di un’interfaccia testuale o grafica, che consentono di eseguire le stesse operazioni di du in modo più comodo e interattivo, mantenendo sempre un livello di efficienza ben maggiore rispetto a quanto è consentito dal Finder.

Disk Usage Analyzer

Primo fra tutti dua, ovvero Disk Usage Analyzer, che nella sua forma di normale comando da Terminale è più o meno un clone semplificato di du. Ma dua cambia pelle quando viene usato in modo interattivo, facendo cioè seguire il comando principale dal sottocomando interactive (o più semplicemente i),

% dua interactive

che disegna sul Terminale una interfaccia utente testuale che permette di muoversi fra una directory e l’altra tramite i tasti freccia (oppure, per gli adepti di vi, anche con i tasti j/k/l/h). Il tasto q permette di uscire dall’applicazione e il tasto ? richiama l’help in linea, con la spiegazione degli altri comandi disponibili.

Il modo più semplice per installare dua sul Mac è tramite Homebrew, il “gestore di pacchetti mancati per macOS” di cui ho scritto parecchio alcuni anni fa. Installare Homebrew è un attimo, basta eseguire nel Terminale (chi vuole informazioni più dettagliate può dare una occhiata qui)

% /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Homebrew installerà un nuovo comando brew, che permetterà a sua volta di installare non solo dua,

% brew install dua-cli

ma anche un gran numero di altri pacchetti e strumenti utili per lo sviluppo e la gestione del sistema che girano prevalentemente nel Terminale.

Homebrew ha parecchie altre funzioni interessanti, che meritano di essere discusse in un articolo specifico.

NCurses Disk Usage

NCurses Disk Usage, ovvero ncdu, è un’applicazione molto simile alla versione interattiva di dua, ma questa volta la sua interfaccia testuale è realizzata tramite la notissima libreria ncurses.

Per installare ncdu basta eseguire,

% brew install ncdu

che installerà automaticamente anche la libreria ncurses se non è già presente sul Mac.

Ad ogni avvio ncdu scansiona il contenuto della cartella di cui deve calcolare le dimensioni, una processo che con le cartelle più grosse può durare anche diversi secondi,

e solo alla fine dell’analisi mostra l’interfaccia testuale del programma (dua invece fa il contrario, prima mostra l’interfaccia e poi esegue la scansione).

Lo schema di colori di default di ncdu è poco azzeccato, ma basta eseguire

% ncdu --color dark

per utilizzare una combinazione di colori decisamente migliore (questione di gusti, naturalmente).

Dust

Dust è focalizzato su una cosa sola: mostrare quali sono le cartelle che occupano più spazio all’interno della cartella di lavoro, quali sono le sottocartelle più grandi contenute all’interno di queste, e così via.

Anche dust si installa con Homebrew,

% brew install dust

e come ncdu scansiona l’intera cartella di lavoro all’avvio, per poi mostrare i risultati con un istogramma che riporta la dimensione relativa delle cartelle più grandi rispetto alla cartella che le contiene (ecco perché il totale non fa 100%).

Una lunga serie di switch permette di modificare il comportamente di dust o di renderlo più simile a du. Ad esempio, eseguendo

% dust -t

dust mostra lo spazio occupato da ciascun tipo di file,

una cosa molto utile per individuare rapidamente gli eventuali file inutili che occupano molto spazio.

Un’altro switch utile è -r,

% dust -r

che inverte l’ordine di visualizzazione delle barre dell’istogramma, che ora vengono mostrate più razionalmente dalla più grande alla più piccola.

Interessante, infine, lo switch -L

% dust -L

che permette di seguire i collegamenti simbolici.

Nel mio caso specifico questa opzione potrebbe mostrare oltre al contenuto del disco principale, anche le cartelle presenti sul disco esterno, che sono collegate al disco principale proprio attraverso una serie di collegamenti simbolici. Dico potrebbe, perché dopo che dust ha indicizzato più di 160 milioni di file, zsh decide che ne ha abbastanza e uccide il processo. Nessun problema, invece, se provo ad analizzare direttamente il disco esterno.

Evidentemente oltre un certo limite dust ha delle difficoltà a seguire in modo efficiente i collegamenti simbolici. Peccato!

Go Disk Usage

Go Disk Usage, cioè gdu, come è evidente già dal nome è sviluppato in Go, un linguaggio di programmazione di casa Google, e si installa con il solito Homebrew

% brew install gdu

Anche gdu all’avvio fa la solita scansione preliminare della cartella di cui deve calcolare le dimensioni e solo alla fine mostra la sua interfaccia testuale,

che già alla prima occhiata sembra più rifinita di quella di dua e ncdu. Anche la scelta dei colori mi pare più azzeccata. L’uso dei tasti freccia per spostarsi da una cartella all’altra (in aggiunta ai soliti j/k/l/h alla vi), e l’help in linea compatto ma molto chiaro, richiamabile in ogni momento con il tasto ?, rendono l’uso del programma molto più intuitivo rispetto agli altri (provare per credere).

Ammetto che prima di provarlo non avevo delle grosse aspettative, invece gdu ha dimostrato fin da subito di essere un gran bel programma.

Cosa scegliere?

In effetti non c’è bisogno di scegliere, tutte le utility appena descritte consumano pochissimo spazio e possono convivere tranquillamente sul Mac, scegliendo di volta in volta quella che ci aggrada di più.

Ma se dovessi fare una classifica metterei al primo posto Go Disk Usage, che funziona benissimo, è veloce quanto basta, permette di muoversi con grande facilità fra una cartella e l’altra e, concedetemelo, ricorda pure l’indimenticabile Norton Commander dei tempi del DOS e il suo clone moderno, Midnight Commander, che per anni ed anni è stato una presenza costante sui miei computer.

Menzione d’onore per dust, che fa una cosa sola ma la fa davvero molto bene.

Interfacce grafiche

E se il Terminale proprio non vi va proprio giù e volete usare a tutti i costi uno strumento con una interfaccia grafica? Anche qui in teoria c’è solo l’imbarazzo della scelta, ma alla fine (spoiler!) il vincitore è solo uno, e con un bel distacco.

GrandPerspective

Che dire di GrandPerspective? Che funziona bene, che è facile da usare, che ha una interfaccia grafica chiara e flessibile e infine che può essere scaricato gratuitamente da SourceForge oppure, pagando la cifra irrisoria di 3 caffè, anche dall’AppStore.

GrandPerspective mostra i file contenuti nella cartella selezionata al momento dell’esecuzione,

utilizzando la tecnica delle treemap (mappe ad albero), che ha una storia che risale a più di trent’anni fa e che è stata implementata per la prima volta su un… scommettiamo che lo sapete?

Se provo ad analizzare la cartella contenente i post di questo blog (la stessa cartella che ho usato nella prima parte di questo articolo), ottengo un risultato piuttosto banale,

dove il file più grosso è .DS_Store, che gestisce la disposizione dei file nelle finestre del Finder, mentre tutti gli altri file hanno dimensioni microscopiche che vanno dai 4 ai 24 kB. Sulla sinistra, in un altro colore, sono messi in evidenza i file contenuti nella cartella annidata TODO.

Cliccando sull’icona Info in alto a destra, si apre una finestra contenente parecchie informazioni utili sulla cartella analizzata, tramite la quale è anche possibile modificare in modo interattivo, tramite la scheda Display, la palette di colori usata per la visualizzazione dei dati e il metodo di attribuzione dei colori stessi.

Ma usare GrandPerspective su una cartella piccola e poco strutturata come questa non ha molto senso. Mi basta però ripetere l’analisi sulla mia Home per ottenere l’immagine seguente, molto più interessante, dove è evidente che il file di gran lunga più grande è uno degli ultimi aggiornamenti dell’iPhone.

Quando la cartella in esame contiene tanti file di tipologia diversa diventa molto utile poter cambiare le modalità di visualizzazione dei file, una cosa facilissima da fare in GrandPerspective tramite la finestra Info > Display. Questo ad esempio è quello che ottengo se scelgo di colorare i risultati in base al tipo di file.

Inutile spendere troppe altre parole, GrandPerspective è davvero un gran bel programma e lo consiglio senza riserve.

DaisyDisk

DaisyDisk costa 11.99 euro, una cifra in sé più che onesta ma che sembra comunque un po’ sproporzionata rispetto a GrandPerspective, e la versione trial scaricata dal sito richiede di essere attivata via email prima di poter essere usata.

Il programma utilizza una modalità di visualizzazione diversa rispetto a quella di GrandPerspective, che assomiglia ad un grafico a torte agli steroidi, dove ogni cerchio concentrico rappresenta un livello di cartelle annidate. All’avvio DaisyDisk propone di scansionare uno dei dischi collegati al Mac, ma tramite il menu Action si può anche decidere di analizzare una singola cartella.

Anche se il metodo di visualizzazione di DaisyDisk è graficamente più bello di quello di GrandPerspective, nei fatti è molto meno efficace sia da navigare che da analizzare. Se a questo si aggiunge il prezzo più alto, trovo davvero poche ragioni per sceglierlo rispetto al concorrente.

OmniDiskSweeper

OmniDiskSweeper in teoria non supporta le versioni più recenti di macOS, ma l’ultima versione disponibile (la 1.14) gira senza problemi in Monterey. Come DaisyDisk, all’avvio OmniDiskSweeper propone di analizzare uno dei dischi collegati al Mac, ma tramite il menu File è possibile scansionare anche le singole cartelle.

In ogni caso, OmniDiskSweeper è solo una versione graficamente più gradevole di du, e se a questo si aggiunge il fatto che non viene più sviluppato da tempo, mi pare che abbia poco senso continuare ad usarlo.

Non è finita qui

E per finire, qualche breve cenno per alcuni software di analisi del contenuto del disco che si trovano facilmente su internet ma che, secondo me, sono meno interessanti.

Dude where are my bytes, ovvero duc (mi sfugge il senso dell’acronimo ma non importa) è un programma grafico per il Terminale che si installa con il solito Homebrew insieme ad un bel numero di librerie di supporto. Purtroppo non c’è verso di farlo funzionare dal Terminale, e pare che il problema non riguardi solo macOS ma anche Linux. In più il metodo di visualizzazione usato da duc assomiglia molto a quello di DaisyDisk (che non mi piace), per cui non mi pare che abbia senso perdere tempo per provare ad usarlo.
Space Gremlin, si trova sull’App Store e utilizza una modalità di visualizzazione dei file molto simile a quella di GrandPerspective. Ma non viene aggiornato da almeno 8 anni, per cui potrebbe servire solo a chi ha un Mac d’epoca su cui gira una vecchia versione di macOS.
PurpleTree, disponibile anch’esso sull’AppStore alla modica cifra di 2.99 euro. Sembra bello, ma le informazioni sul programma sono molto scarse, il sito dello sviluppatore è irraggiungibile, c’è una sola recensione di un anno fa e il programma stesso non viene aggiornato da 1 anno. Posso fidarmi a dare in pasto i miei file ad un programma così?
SquirrelDisk è open source e multipiattaforma, una cosa che io apprezzo sempre moltissimo, ma che in questo caso impedisce di ottimizzare il programma per il sistema operativo in uso. Anche graficamente non è il massimo, francamente non vedo il motivo di usarlo sul Mac.
Space Radar, altro programma multipiattaforma, è scritto in Electron, una cosa che è di per se una garanzia di scarsa efficienza. E in effetti è proprio così, perché Space Radar si blocca tanto spesso da diventare irritante. Peccato, perché se fosse più stabile potrebbe diventare una alternativa interessante a GrandPerspective.

JDiskReport richiede Java, che non è disponibile sul mio Mac su cui ho installato da poco Monterey da zero, né ho voglia di doverlo installare solo per provare JDiskReport. Se qualcuno l’ha fatto può scrivere le sue impressioni nei commenti.

Conclusioni

Finisce qui questa lunga carrellata alle prese con du e affini. Analizzare lo spazio occupato dai nostri file sul Mac è una operazione che non si fa ogni giorno, ma quando serve (e prima o poi servirà) è bene essere preparati e sapere quale strumento usare.

Serve per conoscere meglio il vostro computer, ma serve anche per evitare di ritrovarsi nella stessa spiacevole situazione di un collega (ed amico) della settimana scorsa, con il computer bloccato per mancanza di spazio sul disco e una scadenza urgente da rispettare a tutti i costi. Meglio, molto meglio, non dover ripetere la sua esperienza.

Come controllare lo spazio occupato sul Mac con il Terminale

Wed, 03 May 2023 06:00:00 +0000

Il Terminale di macOS è l’applicazione installata di default su tutte le versioni di macOS per accedere alla shell, l’interfaccia a linea di comando del sistema operativo. La maggior parte dei comandi della shell è identica in tutti i sistema operativi basati su UNIX, che oggi sono principalmente Linux e macOS. Una cosa che ci permette di usare gli stessi comandi su questi due sistemi operativi, così come sulle varie incarnazioni disponibili di BSD Unix e perfino su Windows, almeno dopo aver installato il Windows Subsystem for Linux.

Del Terminale di macOS ho scritto parecchie volte su questo blog. Riguardando i vecchi post ho ritrovato questa introduzione all’uso del Terminale e ai suoi comandi principali che mi pare ancora attuale, a parte il fatto che nel frattempo la shell di default di macOS è diventata zsh al posto di bash. Ma questo cambiamento dovrebbe essere quasi trasparente per l’utente finale, dato che zsh è una versione estesa e compatibile quasi al 100% di bash (le principali differenze fra le due shell sono elencate qui e, in termini più tecnici, anche qui).

Oggi però voglio andare oltre i soliti, un po’ noiosi, comandi di base e proporre un comando poco conosciuto ma che può fare comodo nella gestione giornaliera del Mac.

Una premessa: tanti utenti del Mac sono spaventati dal Terminale, magari vorrebbero usarlo ma temono di far danni. Non è il caso di questo comando, che al massimo può produrre delle lunghe liste di file, ma non può in nessun modo danneggiare il sistema (in ogni caso, per danneggiare un sistema operativo come macOS bisogna usare il Terminale in modo davvero scriteriato).

Altra premessa: per non rendere l’esposizione troppo pesante suppongo che chi legge sappia cos’è una shell o qual è la cartella Home (o Inizio) di un utente. Chi ha bisogno di un ripasso, può trovare qui una breve spiegazione dei concetti principali relativi a macOS e al Terminale.

Quanto spazio occupano i miei file?

Questa è una preoccupazione ricorrente in chi ha un disco di capacità ridotta (i 256 GB di spazio sui modelli base di MacBook Air/Pro e Mini sono davvero troppo pochi), oppure un disco grande ma ormai pieno di file.

Il comando base per sapere quanto spazio occupano i file presenti sul Mac è du (ovvero disk usage), che riporta la dimensione (in blocchi) della cartella corrente e di tutte le cartelle contenute al suo interno.

Ad esempio, se voglio vedere quanto spazio occupano i sorgenti in Markdown di tutti i post di questo blog, mi sposto con cd nella cartella ~/Documents/Articoli\ Mac/Blog/posts del mio Mac (zsh riporta il nome della cartella corrente immediatamente prima del simbolo del prompt %) ed eseguo du, ottenendo

dove il . indica per convenzione la cartella corrente, che a sua volta contiene la cartella TODO dove, come è facilmente immaginabile, conservo i post in lavorazione. La dimensione totale occupata dai miei post è di 7080 blocchi, di cui 160 blocchi sono utilizzati da TODO.

Comandi e interruttori

Usare du così com’è ha poco senso, perché la dimensione in blocchi può essere significativa per un esperto di hardware ma non è facilmente comprensibile per la maggior parte degli utenti, abituati a ragionare in termini di kilobyte, megabyte e gigabyte.¹

Meglio quindi aggiungere a du lo switch --si, con il quale du riporta le dimensioni delle cartelle in kB, MB o GB, scegliendo l’unità migliore in base alle dimensioni di ciascuna cartella. Con --si, 1 kB equivale a 1000 byte, 1 MB a 1000 kB e così via, proprio come fa il Finder. Se vogliamo che le dimensioni siano espresse utilizzando i tradizionali multipli di 1024 dobbiamo utilizzare lo switch -h al posto di --si, ma sul Mac non ha molto senso.

Se eseguo il comando du --si nella cartella ~/Documents/Articoli\ Mac/Blog/posts ora ottengo,

da cui si nota che i quasi 450 file Markdown contenuti in questa cartella occupano appena 3.6 MB e potrebbero stare tranquillamente in 3 floppy disk (eh sì, usare un formato testo per scrivere documenti è sempre molto efficiente).

I comandi del Terminale includono spesso uno o più _switch_, cioè delle opzioni che modificano il comportamento del comando per adattarlo alle necessità dell'utente. Gli switch sono indicati da un trattino seguito da una lettera e, a volte, da un parametro che può essere un numero o una stringa. Ad esempio, il comando `ls -a` mostrerà anche i file nascosti, mentre il comando `shutdown -r now` riavvierà immediatamente il computer. Nel caso in cui si debbano utilizzare più di uno switch, è possibile definirli singolarmente, come ad esempio in `ls -a -l`, oppure inserirli tutti insieme dopo il trattino, come in `ls -al`. Gli switch più complessi possono essere indicati anche da due trattini seguiti da una stringa e dagli eventuali parametri, come lo switch `--si` appena visto.

Altri switch utili del comando du sono:

-a: calcola lo spazio occupato non solo dalle cartelle ma anche dai file contenuti al loro interno.

Ad esempio, se provo ad eseguire du a partire dalla mia Home ottengo una lista di più di 60.000 cartelle, ma se uso du -a la lista cresce fino a comprendere quasi mezzo milione di file e cartelle (del comando collegato wc ho già scritto un bel po’ di tempo fa, qui serve a contare il numero di righe riportate da du).
-d seguito da un numero: definisce il livello di visualizzazione delle cartelle tramite il numero associato allo switch. Ad esempio, -d 1 mostrerà solo le cartelle di primo livello, cioè quelle contenute nella cartella di partenza, mentre -d 2 mostrerà anche le cartelle contenute all’interno delle cartelle di primo livello, e così via.

Se provo ad eseguire du -d 1 nella mia Home ottengo,

da cui si capisce immediatamente che le cartelle che occupano più spazio sono Music e Library (c’è da dire che la mia Home è molto più grande, perché la maggior parte dei file si trova su un disco esterno collegato alla Home tramite dei collegamenti simbolici, ma questa è un’altra storia). Se avessi bisogno di fare spazio sul disco saprei subito dove concentrarmi, invece di perdere tempo ad esaminare minuziosamente tutte le cartelle elencate di default da du.
-t seguito da un numero: definisce la dimensione minima che deve avere una cartella per essere visualizzata. Non è comodissimo, perché la dimensione va specificata in byte, però permette di filtrare rapidamente le cartelle più grandi, come in questo caso in cui ho scelto di visualizzare solo le cartelle più grandi di 1 MB (ovvero 1000000 byte).
-I seguito dal percorso di una cartella fra virgolette: permette di escludere la cartella specificata dal conteggio dello spazio occupato. È possibile usare una espressione regolare per escludere più cartelle in un solo colpo.

Ad esempio, -I "Library", esclude la sola cartella Library, oppure -I "D*" esclude tutte le cartelle che iniziano con il punto o infine, come è mostrato qui sotto, -I ".[a-z]" che esclude dalla visualizzazione tutte le cartelle il cui nome inizia con il punto seguito da una lettera maiuscola o minuscola (sono le cosiddette cartelle nascoste che contengono i file di configurazione di certe applicazioni e che in genere non sono molto grandi).
-k, -m, -g: forzano du a riportare tutte le dimensioni rispettivamente in kB, MB o GB. Analogamente ad -h, le dimensioni sono espresse in multipli di 1024. Se sulla stessa riga di comando si inserisce più di uno switch dimensionale, -g, -h, -k, -m e --si, viene utilizzato solo l’ultimo specificato.

Questi switch servono soprattutto quando si vogliono ordinare le directory in base alle dimensioni, inviando l’output di du al comando sort -n -r, come nell’esempio qui sotto (dato che con questi switch 1 GB corrisponde a 1024 MB, i valori riportati qui sotto sono leggermente diversi rispetto a quelli dell’immagine precedente che usa --si, e quindi i multipli di 1000).

Ma ne vale la pena?

Ma perché usare du quando abbiamo a disposizione il Finder? Prima di tutto perché il Terminale è molto più efficiente, con il Finder possiamo esaminare una sola cartella alla volta, il Terminale invece ci permette di analizzare lo stato un gran numero di cartelle tutte insieme, spostandosi molto più velocemente fra una cartella e l’altra rispetto a quanto sia possibile fare con il Finder.

Un altro vantaggio non da poco è la possibilità di salvare su un file l’output del comando du, in modo da poterlo esaminare con calma in un editor di testo, o magari perché vogliamo tenere traccia dello stato delle cartelle nel corso del tempo. Ad esempio potrei salvare nel file du.txt sul Desktop l’elenco completo delle cartelle contenute in Home,

per poi esaminarlo con calma con TextMate o BBEdit, oppure direttamente nel Terminale a colpi di awk, grep e sed e di espressioni regolari (ma questo richiederebbe almeno un articolo a sé stante).

Infine, abbiamo appena scoperto che il Finder non è molto affidabile quando si tratta di calcolare lo spazio occupato in un disco formattato in APFS, per cui meglio sentire un’altra campana. In questo caso specifico, il Finder mi dice che la mia Home occupa 130.7 GB

mentre secondo du sono solo 128 GB. Non è una grande differenza, però c’è da chiedersi chi ha ragione.

Se queste considerazioni non bastano a convincervi, nel prossimo post troverete delle soluzioni alternative utili a visualizzare rapidamente lo spazio occupato sul vostro disco. A presto!

Inoltre, il numero di blocchi riportati da du varia a seconda del sistema operativo e della configurazione del file system, rendendo ancora più difficile la comprensione della dimensione effettiva dei file. ↩︎

Buon Natale dal Terminale

Wed, 25 Dec 2019 00:00:00 +0000

C’è gente che con il Terminale sarebbe in grado di far volare un Boeing. Oppure che sa costruire un alberello di Natale pieno di lucine colorate, come questo.

Se lo volete anche voi, vi basta aprire il Terminale ed eseguire

$ curl https://raw.githubusercontent.com/sergiolepore/ChristBASHTree/master/tree-EN.sh | bash

oppure, se preferite la versione tradotta in italiano,

$ curl https://raw.githubusercontent.com/sabinomaggi/ChristBASHTree/master/tree-IT.sh | bash

(come sempre il $ rappresenta il prompt del terminale e non fa parte del comando).

Buon Natale!!!

Script per tutti i giorni: lo script è il comando

Fri, 12 Apr 2019 18:00:00 +0000

Nelle puntate precedenti abbiamo visto come scrivere dei semplici script in bash o in awk che risolvono un problema assai specifico, è vero, ma che possono anche costituire una buona base di partenza per affrontare argomenti più complessi (i link alle puntate precedenti si trovano alla fine dell’articolo).

In particolare, nella terza puntata abbiamo imparato come rendere i nostri script quasi indistinguibili dai normali comandi del Terminale: (1) si aggiunge in testa allo script lo shebang, cioè la sequenza di caratteri #!, seguita dal percorso completo al programma da utilizzare per eseguire lo script,¹ (2) si usa il comando chmod per rendere lo script eseguibile (almeno) all’utente attuale del Mac,

$ chmod u+x nomescript

dove nomescript è il nome generico dello script che vogliamo rendere eseguibile (ad esempio lo script convert_title.sh della terza puntata).

Il “quasi” di prima dipende dal fatto che, anche con queste modifiche, ogni volta che eseguiamo lo script dobbiamo indicare esplicitamente la directory dove si trova. Ad esempio, se ci siamo spostati con cd nella directory che contiene nomescript, per eseguirlo script dobbiamo scrivere

$ ./nomescript

premettendo quindi al nome dello script il percorso (./) alla directory corrente.

Invece, quando eseguiamo uno dei comandi del sistema operativo, ci basta scrivere il nome del comando nel Terminale e il sistema operativo (o più precisamente la shell che stiamo usando, che in genere è bash)² va a cercare il programma sul disco rigido e lo esegue senza troppi problemi.

Qual’è il meccanismo che permette alla shell di sapere in quale directory si trovano i comandi che eseguiamo nel Terminale? Esiste un modo per replicare questo comportamento anche per i nostri script, rendendoli praticamente indistinguibili dai comandi intrinseci del sistema operativo?

Variabili di ambiente

In realtà non c’è niente di sofisticato o di particolarmente intelligente in quello che fa la shell. La chiave di tutto sta nelle variabili di ambiente di bash, delle variabili speciali usate fra l’altro per specificare le impostazioni di lavoro della shell. Se lanciamo il Terminale ed eseguiamo il comando

$ env

otterremo un lungo elenco con tutte le variabili di ambiente definite da bash, che per convenzione vengono scritte in maiuscolo. Fra queste spiccano HOME, che definisce il percorso alla cartella Home dell’utente che sta usando il Mac, USER che riporta il nome account (o nome breve) dell’utente, e PWD che contiene il percorso alla directory in cui ci troviamo (percorso che, come già visto, si può ricavare con il comando pwd, ma guarda la combinazione).

Se siamo interessati solo ad una particolare variabile di ambiente, possiamo stamparla con echo seguito dal nome della variabile di ambiente, che però deve essere preceduto dal simbolo $. Ad esempio

$ echo $HOME

stampa nel Terminale il valore della variabile di ambiente HOME.

Fra tutte le variabili di ambiente elencate da env, quella che ci interessa di più in questo momento è PATH, che contiene una serie di percorsi di directory separati dal simbolo :. Nella configurazione di default il valore del PATH è

$ echo $PATH
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

Shell e PATH

È proprio il PATH che permette alla shell di trovare da sola i comandi di sistema. Ogni volta che eseguiamo un comando nel Terminale, la shell lo cerca nelle directory indicate nel PATH, esaminandole una dopo l’altra nell’ordine in cui sono scritte. Se trova il comando lo esegue immediatamente, senza preoccuparsi di esaminare le directory successive, altrimenti dà un errore di command not found.

Di conseguenza, l’ordine in cui sono elencati i percorsi nel PATH è importante. Questa particolarità può essere sfruttata per sostituire un comando del sistema operativo con una versione più recente, senza però cancellare il comando originale: se il comando originale è situato in /usr/bin o in /bin, basta installare la versione aggiornata in una directory del PATH che precede queste due directory, come ad esempio /usr/local/bin (che nei sistemi Unix serve proprio per installare il software “locale” non gestito direttamente dal sistema operativo).³

La seconda conseguenza è che, se modifichiamo il PATH aggiungendo altre directory in testa o in fondo all’elenco originale, possiamo obbligare la shell a cercare i comandi anche in queste nuove directory non presenti nella configurazione di default. Che è proprio quello che ci serve.

Prima di andare avanti una avvertenza FONDAMENTALE. Possiamo aggiungere senza troppi problemi delle nuove directory al PATH di default, ma non dobbiamo MAI MAI MAI rimuovere le directory presenti nella configurazione originale del PATH, in particolare le quattro directory /usr/bin:/bin:/usr/sbin:/sbin (leggetele ad alta voce e notate l’assonanza). Cancellare per errore una di queste directory dal PATH significa non poter più usare il Mac, o perlomeno dover usare degli strumenti non alla portata di tutti per rimettere a posto le cose.

Siete avvertiti!!!

Modificare il PATH

Per aggiungere (o rimuovere) delle directory al PATH di default del nostro Mac dobbiamo modificare con un editor di testo (non con un wordprocessor!) il file .bashrc situato nella nostra HOME. Questo introduce una piccola complicazione, perché il file ~/.bashrc è un file nascosto, non accessibile direttamente dal Finder.

Se usiamo emacs o vi possiamo aprire .bashrc direttamente dal Terminale. Ci basta spostarci nella HOME

$ cd ~

ed eseguire

$ emacs .bashrc

oppure

$ vi .bashrc

Se questi editor ci sembrano troppo difficili da usare (e lo sono!), possiamo usare nano che, come emacs e vi, si trova installato di default su ogni Mac

$ nano .bashrc

Anche se nano è un editor piuttosto limitato rispetto ai due mostri sacri, è molto comodo per modificare velocemente i file di sistema senza dover affrontare una lunga fase di apprendimento.

Se invece preferiamo usare un editor grafico come BBEdit, TextMate, Atom o simili, la procedura esatta per aprire un file nascosto dipende dall’editor scelto.

Alcuni editor permettono di installare un comando di Terminale con cui lanciare l’editor dalla linea di comando: mate per TextMate, atom e bbedit per… lo sapete già. Anche con questi editor, quindi, possiamo aprire .bashrc dal Terminale con uno dei comandi seguenti

$ mate .bashrc 
$ atom .bashrc
$ bbedit .bashrc

Con BBEdit e TextMate, la finestra di apertura file dispone di un tasto Opzioni con il quale si può decidere di mostrare (e quindi di aprire) anche i file nascosti

Ma il metodo più generale per modificare un file nascosto con un editor grafico è quello di usare il comando open dal Terminale

$ cd ~
$ open -a "TextMate" .bashrc

dove l’opzione -a permette di specificare l’applicazione con cui aprire il file indicato.

Qualunque sia il metodo utilizzato, alla fine ci ritroveremo con il file .bashrc pronto per essere modificato. Tutto quello che dobbiamo fare è aggiungere questa linea alla fine di .bashrc

export PATH=$PATH:~/Development

che istruisce la shell di andare a cercare i comandi da eseguire nel Terminale anche nella directory ~/Development, dove abbiamo deciso di salvare tutti gli script che sviluppiamo.

Una volta fatta questa semplice modifica, salviamo il file .bashrc e usciamo dall’editor. Chiudiamo e riapriamo il Terminale per costringere la shell a rileggere il file .bashrc (oppure eseguiamo il comando $ source ~/.bashrc senza chiudere il Terminale) e proviamo di nuovo ad eseguire nomescript, ma questa volta senza premettere il percorso alla directory dove si trova

$ nomescript

Questa volta lo script funzionerà senza bisogno di aiutini, proprio come se fosse un normale comando di sistema. Per verificare che tutto funzioni come descritto possiamo provare ad eseguire uno degli script della terza o della quinta puntata.

Ma non è ancora finita…

Bisogna ammetterlo, aggiungere al $PATH una directory qualunque come ~/Development può andar bene per fare delle prove veloci, ma non è per niente elegante. Sarebbe molto meglio adeguarsi alle convenzioni di Unix, secondo le quali i programmi eseguibili devono trovarsi in una directory denominata bin.

Niente di più facile, possiamo creare facilmente una directory bin nella nostra HOME

$ cd
$ mkdir bin

e decidere di tenere gli script in fase di sviluppo nella directory ~/Development, per poi spostarli (o meglio copiarli) in ~/bin quando sono pronti per essere usati. Naturalmente dovremo modificare di conseguenza il file .bashrc, aggiungendo alla fine del file

export PATH=$PATH:~/bin

al posto di export PATH=$PATH:~/Development visto sopra.

Non ci piace vedere con il Finder la directory bin nella HOME? Possiamo nasconderla con facilità, basta solo eseguire dal solito Terminale il comando

$ chflags hidden ~/bin

(il comando duale $ chflags nohidden ~/bin rende di nuovo visibile la directory).

Conclusioni

Per i più pigri che non vogliono andare a rileggere le puntate precedenti per provare le novità descritte nell’articolo, ecco un semplice script in bash che mostra la data e l’ora corrente nel formato standard Unix e in una forma molto più dettagliata (e per una volta anche nella nostra lingua)

#!/bin/bash

year=`date +%Y`
month=`date +%B`
day=`date +%d`
hour=`date +%H`
minute=`date +%M`
second=`date +%S`
dayofyear=`date +%j`
weekday=`date +%A`

echo `date`
echo -n "Oggi è $weekday $day $month $year, "
echo -n "il $dayofyear-esimo giorno dell'anno, "
echo "e sono le ore $hour:$minute:$second"

Copiamo lo script nell’editor preferito, salviamolo in ~/bin (o in ~/Development) con il nome data_estesa, rendiamolo eseguibile con chmod e proviamo che funzioni come previsto

$ data_estesa
Fri Apr 12T17:28:00:50 CEST 2019
Oggi è Venerdì 12 Aprile 2019, il 102-esimo giorno dell'anno, e sono le ore 17:28:50

E per oggi è davvero tutto.

Articoli precedenti

Per leggere gli articoli precedenti della serie basta cliccare sui link qui sotto.

Prima puntata, Script per tutti i giorni: semplici modifiche alle stringhe di testo
Seconda puntata, Script per tutti i giorni: dalla linea di comando al programma
Terza puntata, Script per tutti i giorni: shell e parametri
Quarta puntata, Script per tutti i giorni: ricapitoliamo
Quinta puntata, Script per tutti i giorni: entra in scena awk

Sul Mac uno script in bash richiede il percorso /bin/bash, uno in awk puro /usr/bin/awk, mentre uno nella ormai veneranda versione 2.7 di python installata di default in macOS richiede /usr/bin/python (ma ci vuol poco ad installare python3 con Homebrew o Conda). ↩︎
Ma ci sono anche zsh, ksh, tcsh, fish, solo per menzionare le shell più note. ↩︎
È esattamente quello che fa Homebrew, uno strumento utilissimo (di cui ho scritto parecchio su questo blog) che utilizza /usr/local/bin per installare un gran numero di strumenti software provenienti dal mondo Linux e non disponibili su macOS, oppure per aggiornare a versioni più recenti quelli, normalmente piuttosto datati, forniti da Apple insieme al sistema operativo. ↩︎

Script per tutti i giorni: entra in scena awk

Mon, 18 Feb 2019 18:00:00 +0000

– Tastiera A.W.K., Viscount Instruments.

Nelle prime tre puntate di questa serie abbiamo imparato a scrivere uno script in bash per trasformare una stringa di testo in modo che segua delle convenzioni ben determinate a priori (qui i link alla prima, seconda e terza puntata).

In questo caso particolare, la stringa risultante dalla trasformazione deve essere scritta tutta in minuscolo e non deve contenere apostrofi o altri caratteri speciali, a parte il trattino usato come separatore di parole. L’idea è quella di usare questa stringa, insieme alla data di pubblicazione del post, per dare un nome standard e facilmente rintracciabile al file Markdown che contiene il testo del post stesso, utilizzando il formato YYYY-MM-DD-titolo-del-post.md, dove YYYY indica l’anno, MM il mese e DD il giorno di pubblicazione.

L’approccio seguito finora è utile per imparare i fondamenti della programmazione in bash, ma manca decisamente di praticità. Partire dal titolo e dalla data di pubblicazione presenti nell’intestazione del post per arrivare al nome completo del file richiede un certo lavoro di copia e incolla fra l’editor, il Finder e il Terminale, e gli errori sono sempre in agguato.

Quello che ci vuole è uno script che renda il processo completamente automatico, rinominando il file Markdown a partire dal contenuto del documento stesso.¹

Si potrebbe benissimo fare anche con bash, ma perché complicarsi la vita quando c’è uno strumento fatto apposta per analizzare ed estrarre dei dati dai file di testo?

AWK, questo sconosciuto

AWK è un linguaggio di programmazione interpretato sviluppato negli anni ‘70 presso i Bell Labs, il famosissimo centro di ricerca americano che ci ha dato il transistor, il laser, Unix e il C (e moltissimo altro). AWK è stato sviluppato da Alfred Aho, Peter Weinberger e Brian Kernighan, tre grandi studiosi di computer science, fra i quali spicca il terzo, coautore insieme a Dennis Ritchie di The C Programming Language, il volume di riferimento sul linguaggio C, noto anche semplicemente come “K&R” dai cognomi dei due autori.

Alla base di AWK c’è l’idea di elaborare un file di testo una riga alla volta, controllando che la riga in esame soddisfi una o più condizioni prestabilite ed eseguendo le azioni programmate per ciascuna di queste condizioni

    condizione #1: {azione #1}
    condizione #2: {azione #2}
    ...
    condizione #N: {azione #N}

Per AWK un file di testo è costituito da un certo numero di righe (record), ciascuna delle quali è suddivisa in uno o più campi (field), separati fra loro da un separatore di campo, che di default è lo spazio ma che può essere modificato a piacere. Per riferirsi a ciascun campo AWK usa le variabili speciali $1, $2 e così via, dove il numero indica la posizione del campo all’interno della riga. La variabile $0 contiene l’intera riga corrente.

Tutto qui? Più o meno. C’è (quasi) solo da aggiungere che AWK prevede due azioni speciali opzionali, racchiuse fra i blocchi BEGIN {...}, END {...}, che servono per eseguire le operazioni preliminari e conclusive necessarie per il buon funzionamento del programma, ad esempio per definire il separatore di campo. Un programma completo in AWK ha quindi una struttura di questo tipo,

    BEGIN { istruzione
            istruzione
            ....
          }
    
    condizione #1: { istruzione
                     istruzione
                     ....
                   }
    condizione #2: { istruzione
                     istruzione
                     ....
                   }

    ...
    condizione #N: { istruzione
                     istruzione
                     istruzione
                     ....
                   }

     END { istruzione
           istruzione
           ....
         }

dove come già detto i blocchi BEGIN {...}, END {...} sono opzionali.

Nonostante la fama dei suoi autori, AWK è poco utilizzato, molto meno di quanto meriterebbe, i programmatori del mondo UNIX preferiscono usare strumenti più semplici ma meno potenti come sed (che abbiamo già incontrato nelle puntate precedenti) o il declinante perl, un linguaggio di manipolazione di file di testo perfetto per i programmatori che mitizzano Tafazzi.

AWK invece ha il giusto equilibrio di potenza e semplicità d’uso ed è uno strumento perfetto se gli si chiede di fare quello per cui è stato ideato, elaborare informazioni strutturate contenute in file di testo.

Per fortuna AWK è installato di default in macOS e in Linux, oltre che in tutti i sistemi operativi basati su UNIX che si trovano in giro, per cui per provarlo basta lanciare il Terminale ed eseguire il comando awk. In realtà ci sono in giro almeno due versioni diverse di AWK. In macOS è installato awk liscio, la versione del linguaggio definita dai tre autori originali nel volume The AWK programming language. Su Linux, invece, si trova in genere gawk, una implementazione del linguaggio della Free Software Foundation pienamente compatibile con awk, a cui sono state aggiunte alcune estensioni piuttosto utili. Installare gawk su macOS è facile per chi usa Homebrew, dal Terminale

$ brew install gawk

Da ora in poi per semplicità farò cadere la distinzione fatta finora fra AWK, il linguaggio di programmazione, e awk, l’interprete del linguaggio, usando sempre e solo il termine awk per riferirmi ad entrambi.

Un programma banale in awk

Per avere una idea di cosa può fare awk, ecco un piccolissimo (e rozzo) programma di esempio,

BEGIN { FS = ","
        OFS = ", "
      }

$1 ~ /Violanda/ { $1 = "Jolanda" }
                { print $2, $1, $3, $6, $4, $5 }

che applicato ad un elenco di indirizzi come questo,

NOME,COGNOME,INDIRIZZO,LOCALITA,PROVINCIA,CAP
Massino,Nardini,Via Roma 8,Grana,AT,14031
Primo,Sabbatini,Via C. Cattaneo 50,Cala di Volpe,SS,07020
Giuseppe,Marino,Via C. Alberto 75,Barni,CO,22030
Ivano,Costa,Via Guantai Nuovi 29,Ischia,NA,80077
Margherita,Davide,Via Nuova Agnano 83,Rufina,FI,50068
Daphne,Lettiere,Via R. Conforti 67,Castel Di Ieri,AQ,67020
Violanda,Lori,Via A. Manzoni 101,Parona,PV,27020
Luigia,Cremonesi,Via Castelfidardo 145,Cittadella Del Capo,CS,87020
Fiore,Mucciano,Via Valpantena 120,Buccino Stazione,SA,84020
Sandra,Greco,Via Pisanelli 140,Castiglione D'Adda,LO,26823

scambia la posizione del nome e del cognome e sposta il CAP prima della Località in tutte le righe del file. Già che c’è, corregge anche il nome sbagliato “Violanda” e lo trasforma in “Jolanda”. Nella riga #5, $1 ~ /Violanda/ è la condizione, e {$1 = "Jolanda"} l’azione relativa, mentre nella riga #6 la condizione è vuota e quindi l’azione conseguente {print $2, $1, $3, $6, $4, $5} si applica a tutte le righe del file. Il blocco BEGIN {...} serve per definire il carattere (o i caratteri) che separa i campi contenuti in ciascuna riga letta o scritta dal programma: la variabile predefinita FS è il separatore dei campi del file di input (quello letto dal programma), OFS è il separatore dei campi delle righe stampate dallo script.

Per provarlo, copiate il programma in un editor e salvatelo come swap.awk, poi copiate la lista di indirizzi e salvatela come address.csv (meglio se salvate i due file nella cartella ~/Development, ricordate?). Infine lanciate il Terminale, eseguite il comando

$ awk -f swap.awk address.csv

e vedete cosa viene fuori. Provate a cambiare OFS e a vedere che succede.

Domanda 1: Come si fa a lanciare lo script senza dover premettere il comando awk?

Domanda 2: Se si rimuove la variabile FS dal blocco BEGIN{...} lo script continua a funzionare correttamente?

Ma basta con awk. Questo articolo non vuole essere una introduzione al linguaggio ma vuole solo mostrare come si può risolvere con AWK il problema che ci sta a cuore. Chi volesse è approfondire la conoscenza del linguaggio può consultare i volumi e le guide online riportate in bibliografia.

Rinominare automaticamente un post

E finalmente eccoci al programma awk che rinomina da solo il file Markdown di un post in base al titolo e alla data contenuti nei metadati del documento, che contengono, fra l’altro, il titolo, la data di pubblicazione, la categoria e i tag associati al post stesso.

BEGIN { FS = " "
        OFS = "-"
        EXT = ".md"
      }

$1 ~ /[Dd]ate:/   { date = $2 }
$1 ~ /[Tt]itle:/  { title = ""
                    for (i = 2; i <= NF; i++) {
                        title = title FS tolower($i)
                    }
                  }

END { newfilename = date OFS title
      gsub("[[:cntrl:]]", "", newfilename)
      gsub("[\"]+", "", newfilename)
      gsub("[\.,;:!\?&\$]+", "", newfilename)
      gsub("[-| ]+", "-", newfilename)
      newfilename = newfilename EXT
      system("mv " FILENAME " " newfilename)
    }

Riassumo brevemente cosa fa il programma, chi non fosse interessato può saltare direttamente al prossimo paragrafo. La prima condizione $1 ~ /[Dd]ate/ cerca la stringa date: (indifferentemente in minuscolo o maiuscolo) nel primo campo di tutte le righe del post e quando la trova assegna il secondo campo, corrispondente alla data, alla variabile date. La seconda condizione fa lo stesso per il titolo e lo assegna alla variabile title. Poiché il titolo è distribuito su un numero imprecisato di campi (ricordo che il separatore di campo FS è lo spazio), viene utilizzato un ciclo for per leggere ed aggiungere in successione a title tutti i campi della riga successivi al primo. Il numero di campi presenti nella riga del titolo è contenuto nella variabile di sistema NF, aggiornata automaticamente dall’interprete ogni volta che viene letta una nuova riga. La parte finale del programma, racchiusa nel blocco END {...}, si occupa di definire la variabile newfilename, contenente il nuovo nome da assegnare al file, e di trasformarla secondo le regole desiderate. La variabile newfilename contiene inizialmente (riga #12) la data e il titolo letti nel post, separati da un trattino (il valore di OFS). Nelle quattro righe successive viene utilizzata la funzione gsub per rimuovere da questa variabile tutti i caratteri indesiderati (caratteri di controllo, virgolette, punteggiatura) e per sostituire spazi e trattini (anche multipli) con un trattino singolo. Alla riga #17 viene aggiunta l’estensione definita in EXT, mentre l’ultima riga del blocco effettua una chiamata al sistema operativo per rinominare effettivamente il file, utilizzando un’altra variabile di sistema, FILENAME, che contiene il nome originale del file Markdown su cui sta operando lo script.

Salviamo il programma nella solita cartella Development con il nome setpostname.awk. Per provarlo dobbiamo avere anche un file Markdown contenente nell’intestazione (header) almeno i metadati relativi al titolo e alla data. Possiamo prendere la prima parte di questo post,

---
layout: post  
title: "Script per tutti i giorni: entra in scena awk"  
author:	Sabino Maggi  
date: 2019-02-18T18:00:00  
categories:  
  - programmazione  
tags:  
  - awk  
  - bash  
  - editor  
  - gawk  
  - perl  
  - script  
  - terminale  
comments: true  
sidebar: true  
toc: true  
published: 2019-02-18T18:00:00  
slug:  

---

Nelle prime tre puntate di questa serie abbiamo imparato a scrivere uno script in `bash` per trasformare una stringa di testo in modo che segua delle  convenzioni ben determinate a priori (qui i link alla [prima](https://melabit.wordpress.com/2018/11/23/script-per-tutti-i-giorni-semplici-modifiche-alle-stringhe-di-testo/), [seconda](https://melabit.wordpress.com/2018/12/05/script-per-tutti-i-giorni-dalla-linea-di-comando-al-programma/) e [terza](https://melabit.wordpress.com/2018/12/30/script-per-tutti-i-giorni-shell-e-parametri/) puntata).

In questo caso particolare,...

e salvarlo con un nome qualsiasi nella stessa cartella Development. Poiché la fantasia fa difetto, chiamiamolo articolo.md. A questo punto lanciamo il Terminale, spostiamoci nella cartella Development

$ cd ~/Development

e lanciamo lo script in awk con il comando

$  /usr/bin/awk -f setpostname.awk articolo.md

e voilà, il file articolo.md viene rinominato automaticamente in 2019-02-18-script-per-tutti-i-giorni-entra-in-scena-awk, che è esattamente quello che volevamo. Nota per i più curiosi: dato che awk ha bisogno di sapere sia il nome dello script contenente i comandi che quello del file da elaborare, si usa l’opzione -f per indicare esplicitamente lo script con i comandi.

Perché uso l’intero percorso /usr/bin/awk per richiamare awk? Semplicemente perché voglio essere sicuro di utilizzare l’interprete awk presente di default in macOS e non la versione estesa installata tramite Homebrew, che funziona in modo leggermente diverso e darebbe degli avvertimenti poco incomprensibili, pur riuscendo lo stesso a rinominare correttamente il file.

Conclusioni

Ormai siamo quasi a posto con la rinominazione automatica di un post in Markdown (che poi in effetti è solo una scusa per gettare le basi e per poter affrontare script complessi e più utili). Manca solo un piccolissimo dettaglio, che può far diventare questo script del tutto indistinguibile dai comandi standard del sistema operativo e che sarà l’argomento della prossima puntata.

Bibliografia

Alfred Aho, Brian Kernighan, Peter Weinberger, The AWK programming language, Addison-Wesley, 1988.
Arnold Robbins, Gawk: Effective AWK Programming, Edition 4.2, 2018.
Sculpting text with regex, grep, sed, awk, emacs and vim.
Wikibooks, An Awk Primer.
Bruce Barnett, Awk a Tutorial and Introduction.
Tutorials Point, Awk Tutorial.

Una cosa che io trovo bellissima anche dal punto di vista diciamo così, filosofico, e che mi ricorda i bellissimi articoli di Douglas Hofstadter su Le Scienze sui testi autoreferenziali. ↩︎

Script per tutti i giorni: shell e parametri

Sun, 30 Dec 2018 18:00:00 +0000

– Foto: Trammell Hudson su Flickr.

Lo script di conversione del titolo di un post mostrato alla fine della puntata precedente è diventato ormai quasi “utilizzabile”. Mancano solo un paio di tocchi finali, che vedremo nel corso di questa terza parte.

Una casa per i programmi

Prima di proseguire è bene decidere una volta per tutte dove salvare gli script che stiamo sviluppando. Non so voi, ma io preferisco usare una cartella dedicata allo scopo invece di buttare tutto dove capita. In tutti gli articoli di questa serie gli script in fase di sviluppo saranno salvati nella cartella Development, situata all’interno della cartella Home (o Inizio) dell’utente che ha effettuato il login (la cartella Home è quella rappresentata dall’icona di una casetta). Ovviamente siete liberi di usare un altro nome e un’altra posizione sul disco rigido, ma dovrete ricordarvi di modificare di conseguenza i percorsi dei comandi.

Già che ci siamo, creiamo subito la cartella Development. Se usate il Finder non ho bisogno di dirvi come si fa, se invece usate il Terminale basta eseguire i comandi

$ cd ~
$ mkdir Development

dove il primo comando, cd ~ (ma su macOS e varie versioni di Linux è sufficiente il semplice cd) ci fa spostare nella nostra Home, mentre il secondo comando crea la nuova directory Development. Nelle shell Unix come bash, il simbolo tilde ~ (che si scrive premendo ALT-5) indica la Home dell’utente.

Volendo potremmo anche eseguire semplicemente

$ mkdir ~/Development

che crea la directory desiderata con un unico comando.

Qualche breve nota generale. In questo contesto i termini script o programma sono equivalenti e li userò indifferentemente. Lo stesso vale per directory e cartella. Io preferisco il primo, ma so benissimo che, da quando esistono le interfacce grafiche, il termine “cartella” è diventato di uso molto più comune. Nel seguito cercherò di usare “cartella” nel testo discorsivo degli articoli e “directory” quando si tratterà di riferirsi ai comandi di bash e al Terminale. Infine, il simbolo $ prima di ogni comando è il cosiddetto prompt e serve ad indicare che stiamo interagendo con il Terminale; non fa parte dei comandi e quindi non deve mai essere inserito quando scriviamo un comando nel Terminale.

Andare con le proprie gambe

Nella puntata precedente siamo arrivati ad usare uno dei tanti editor di testo disponibili su macOS per inserire queste righe di codice

string="La privacy al tempo dell'Internet of Things: gran finale"
 
fix_string=$(echo $string | tr "[:upper:]" "[:lower:]")
fix_string=$(echo $fix_string | sed "s/'/ /g")
fix_string=$(echo $fix_string | sed "s/[[:punct:]]//g")
fix_string=$(echo $fix_string | sed "s/ /-/g")
 
converted_string=$fix_string
echo $converted_string

Ora possiamo salvare lo script nella cartella ~/Development/, dandogli un nome significativo che ci aiuti a ricordare anche in un secondo momento cosa fa il programma. Molto meglio quindi usare un nome come convert_title.sh piuttosto che un criptico SCCUSIFJ.sh, anche se profuma tanto di DOS e di anni ‘80.

Nei sistemi Unix come macOS l’estensione .sh non è indispensabile ma ci aiuta a capire al volo che il file è uno script della shell (da cui .sh). È possibile usare altre estensioni come .shell, .script, .cmd o perfino .bat, per il sistema operativo non cambia nulla.

A questo punto possiamo finalmente di eseguire lo script. Lanciamo il Terminale, spostiamoci nella cartella dove abbiamo salvato lo script

$ cd ~/Development

ed eseguiamo lo script con il comando

$ sh convert_title.sh
la-privacy-al-tempo-dell-internet-of-things-gran-finale

ottenendo, come previsto, la trasformazione della stringa definita nella string nel formato adatto a Jekyll o a Wordpress.

Per eseguire lo script dobbiamo premettere al nome del file il comando sh che indica al sistema operativo che il file in questione contiene una serie di comandi di shell, cioè di comandi che permettono di interagire con il sistema operativo stesso (attenzione, il comando sh è una cosa ben diversa dall’estensione .sh vista prima!). Con questa informazione, il sistema operativo trasferisce l’esecuzione dello script alla shell di default, che in macOS e nella maggior parte dei sistemi Linux attuali è bash. Niente però impedisce di forzare l’utilizzo di bash, scrivendo esplicitamente

$ bash convert_title.sh

al posto di sh convert_title.sh, oppure di utilizzare altre shell eventualmente disponibili nel sistema, come tcsh, ksh, zsh o fish (argomento che non verrà trattato in questa serie).

Purtroppo affidarsi alla configurazione di default del sistema può creare problemi, ad esempio perché qualcuno ha cambiato la shell di default, magari solo per fare una prova, dimenticando di ripristinare la configurazione iniziale. Per fortuna in genere queste cose non succedono per cui possiamo stare relativamente tranquilli. Però il meccanismo appena descritto non è né semplice, né tanto meno a prova di bomba.

Proviamo a semplificarci la vita con due piccole modifiche. Prima di tutto utilizziamo il comando chmod per rendere eseguibile lo script all’utente attuale del Mac

$ chmod u+x convert_title.sh

dove la u indica l’utente che sta usando il Mac e il simbolo +x significa che il file viene reso eseguibile (la x sta per eXecute). Se volessimo rimuovere questa autorizzazione, non dovremmo far altro che eseguire il comando duale

$ chmod u-x convert_title.sh`

Se invece volessimo autorizzare tutti gli utenti del Mac ad eseguire questo script, dovremmo scrivere

$ chmod a+x convert_title.sh

mentre per autorizzare solo gli utenti che fanno parte del nostro stesso gruppo di lavoro oppure tutti gli altri utenti fuori dal nostro gruppo di lavoro, dobbiamo usare rispettivamente chmod g+x convert_title.sh oppure chmod o+x convert_title.sh.

Ma queste sono finezze utili per i server a cui accedono decine e decine di utenti contemporaneamente, i Mac sono sostanzialmente macchine monoutente (o che gestiscono un numero molto ridotto di utenti), per cui chmod u+x (o al massimo chmod a+x) a noi basta e avanza.

L’altra modifica utile è quella di indicare esplicitamente al sistema operativo quale shell vogliamo utilizzare per interpretare i comandi contenuti nel nostro script. Per farlo è sufficiente aggiungere all’inizio dello dello script la sequenza di caratteri #!, il cosiddetto shebang,¹ seguita dal percorso completo al programma di shell che vogliamo usare.

Dato che qui usiamo bash, il nostro script diventa

#!/bin/bash

string="La privacy al tempo dell'Internet of Things: gran finale"
 
fix_string=$(echo $string | tr "[:upper:]" "[:lower:]")
fix_string=$(echo $fix_string | sed "s/'/ /g")
fix_string=$(echo $fix_string | sed "s/[[:punct:]]//g")
fix_string=$(echo $fix_string | sed "s/ /-/g")
 
converted_string=$fix_string
echo $converted_string

Ma come lo troviamo il percorso di bash? C’è un comando anche per questo: which seguito dal nome di un qualunque comando Unix restituisce proprio il percorso completo del comando all’interno del filesystem. Di conseguenza which bash restituisce

$ which bash
/bin/bash

che è proprio ciò che dobbiamo inserire in testa allo script subito dopo lo shebang.

Per verificarlo, basta provare a salvare lo script modificato con un nome diverso, diciamo convert_title_v2.sh e rendiamolo esegubile con il comando chmod a+x convert_title_v2.sh descritto prima.² A differenza di convert_title.sh, questo secondo script potrà essere eseguito senza dover premettere sh

$ ./convert_title_v2.sh 
la-privacy-al-tempo-dell-internet-of-things-gran-finale

Per una serie di ragioni che vedremo in una prossima puntata, dobbiamo però aiutare il sistema operativo a trovare lo script aggiungendo esplicitamente il percorso allo script da eseguire. Poiché nei sistemi Unix (e non solo), il punto . indica la cartella corrente (mentre il doppio punto .. si riferisce alla cartella che contiene la cartella corrente), scrivere ./ immediatamente prima del nome dello script equivale a dire al sistema operativo che lo script si trova nella cartella corrente, che in questo caso è la cartella dove siamo entrati all’inizio di questa puntata con il comando cd ~/Development.

Parametri sulla linea di comando

C’è ancora una cosa che non va bene. Ogni volta che vogliamo cambiare la stringa da convertire dobbiamo intervenire direttamente sullo script, modificando la variabile string. Facendo così è facile sbagliare, e in ogni caso sarebbe molto più comodo rendere lo script indipendente dai dati sui quali deve operare (in questo caso la stringa da convertire).

Non voglio entrare nei dettagli (ma ci sarà tempo per approfondire la questione), per ora basterà dire che per rendere lo script indipendente dalla stringa da trasformare è sufficiente assegnare a string il valore della variabile convenzionale $1

#!/bin/bash

string=$1

fix_string=$(echo $string | tr "[:upper:]" "[:lower:]")
fix_string=$(echo $fix_string | sed "s/'/ /g")
fix_string=$(echo $fix_string | sed "s/[[:punct:]]//g")
fix_string=$(echo $fix_string | sed "s/ /-/g")
 
converted_string=$fix_string
echo $converted_string

L’interprete bash assegna automaticamente alle variabili $1, $2, … $9, dette parametri posizionali, i valori degli argomenti dello script, cioè i valori dei parametri presenti sulla linea di comando subito dopo il nome dello script da eseguire.³ I diversi parametri sono separati da uno o più spazi, e se un parametro contiene degli spazi bisogna racchiuderlo fra virgolette, non importa se semplici ' o doppie " (però è preferibile ~~essere consistenti ed~~ evitare di mescolare i due simboli).

Salviamo lo script così modificato con il solito nome convert_title.sh e torniamo al Terminale. Ora per usare lo script dobbiamo scrivere la stringa da convertire direttamente sulla linea di comando, subito dopo il nome del file, racchiudendola fra virgolette dato che la stringa contiene degli spazi (io preferisco usare le virgolette doppie)

$ ./convert_title.sh "La privacy al tempo dell'Internet of Things: gran finale"
la-privacy-al-tempo-dell-internet-of-things-gran-finale

Naturalmente niente impedisce di trasformare stringhe molto più lunghe, come ad esempio un paragrafo di questo stesso articolo, l’unica limitazione è che la stringa non deve contenere dei caratteri di ritorno a capo

$ convert_title.sh "Purtroppo affidarsi alla configurazione di default del sistema può creare problemi, ad esempio perché qualcuno ha cambiato la shell di default, magari solo per fare una prova, dimenticando di ripristinare la configurazione iniziale. Per fortuna in genere queste cose non succedono per cui possiamo stare relativamente tranquilli. Però il meccanismo appena descritto non è né semplice, né tanto meno a prova di bomba."
purtroppo-affidarsi-alla-configurazione-di-default-del-sistema-può-creare-problemi-ad-esempio-perché-qualcuno-ha-cambiato-la-shell-di-default-magari-solo-per-fare-una-prova-dimenticando-di-ripristinare-la-configurazione-iniziale-per-fortuna-in-genere-queste-cose-non-succedono-per-cui-possiamo-stare-relativamente-tranquilli-però-il-meccanismo-appena-descritto-non-è-né-semplice-né-tanto-meno-a-prova-di-bomba

Se guardiamo attentamente il risultato della conversione notiamo come lo script non riesce a trattare correttamente i caratteri accentati, come era stato già notato esplicitamente nella prima puntata di questa serie di articoli. Per ora sarà sufficiente evitare di usare i caratteri accentati o almeno scriverli con una vocale seguita da un apostrofo, come se stessimo usando una tastiera americana.

Conclusioni (per ora)

Se togliessimo l’estensione al nome del file, lo script convert_title diventerebbe quasi indistinguibile dai comandi veri e propri del sistema operativo. Dico “quasi” perché per poterlo eseguire dobbiamo ancora premettere il percorso alla cartella corrente al nome del file. Ci sarà modo per risolvere questo (piccolo) problema, i più impazienti possono leggere qui per capire in anteprima come si fa.

La prossima volta faremo un veloce ripasso dei comandi presentati in queste prime tre puntate, utile per consolidare quanto visto finora prima di passare ad usare uno degli strumenti più potenti ma anche meno conosciuti dell’arsenale Unix.

Revisioni

30-12-2018: Corretta una imprecisione relativa al cambiamento dei permessi dei file quando la prima riga di uno script contiene lo shebang e il percorso all’interprete bash (si veda la nota 2).

Detto anche sha-bang o hashbang. ↩︎
Se la stringa #!/bin/bash è esattamente la prima riga dello script, quando salviamo lo script l’editor TextMate lo rende eseguibile da tutti gli utenti del sistema, proprio come se avessimo usato esplicitamente il comando chmod a+x .... È una particolarità del solo TextMate, tutti gli altri editor che ho provato (Atom, BBEdit, Visual Studio Code e CotEditor fra quelli grafici, nano, emacs e vim per quanto riguarda gli editor testuali) non modificano mai i permessi del file. ↩︎
Se abbiamo bisogno di più di nove parametri, dobbiamo racchiudere quelli dal decimo in poi fra parentesi graffe, scrivendo ${10}, ${11} e così via. ↩︎

Script per tutti i giorni: dalla linea di comando al programma

Wed, 05 Dec 2018 18:00:00 +0000

– Foto: Matthew Ratzloff su Flickr.

Il comando per generare automaticamente il nome del file nel formato previsto da Jekyll (o da Wordpress) dal titolo del post presentato alla fine della prima puntata potrà anche essere interessante dal punto di vista didattico ma, diciamolo, è poco pratico per essere utilizzato veramente. Bisogna lanciare il Terminale, andare a cercare il comando da qualche parte, copiarlo e incollarlo nel Terminale, cancellare il titolo preesistente e incollare il titolo del nuovo post su cui stiamo lavorando… Si fa prima a fare tutto a mano nel Finder!

Ma se lo trasformiamo in uno script, cioè in un piccolo programma eseguibile direttamente dal Terminale come un qualunque comando del sistema operativo, le cose diventano improvvisamente molto più interessanti.

Dove vai se l’editor non ce l’hai?

Per lavorare sugli script è fondamentale avere a disposizione un buon editor di testo. In macOS sono già integrati due pesi massimi, emacs e vi, eseguibili direttamente dal Terminale tramite i comandi omonimi. Fatevi un favore e non usateli.

Questi due editor, che hanno dato origine ad una vera e propria guerra di religione fra i fan dell’uno e dell’altro programma, sono perfetti per i professionisti, per chi è già esperto di programmazione ed è disposto ad affrontare una fase di apprendimento lunga e piuttosto impervia. Ma per chi è all’inizio e deve concentrarsi sull’imparare le basi e la logica della programmazione, un editor troppo complicato è più che altro un ostacolo ed una distrazione.

Molto meglio installare uno dei tanti editor grafici disponibili per macOS. Fra Atom, BBEdit, TextMate, Visual Studio Code, c’è solo l’imbarazzo della scelta. Sono tutti gratuiti (si, ora anche BBEdit è gratuito, la licenza serve per sbloccare le funzioni avanzate utili per i professionisti), sono tutti di ottima qualità (si, anche un prodotto Microsoft come Visual Studio Code può essere ottimo). Io preferisco usare TextMate e Atom – di quest’ultimo mi piace moltissimo la possibilità di sincronizzare automaticamente le impostazioni, i plugin e i temi fra tutti i computer su cui l’ho installato, che siano Mac o generici PC con Linux o Windows – però BBEdit è perfetto per i file di grosse (o meglio dire enormi) dimensioni come quelli che mi stanno capitando per le mani ultimamente. Mentre Visual Studio Code… beh, Visual Studio Code è stato una vera sorpresa sin dalla prima volta che l’ho usato.

Dalla linea di comando allo script

Lanciamo quindi l’editor che preferiamo e incolliamo l’ultima versione del comando di Terminale visto nella puntata precedente

echo "La privacy al tempo dell'Internet of Things: gran finale" | tr "[:upper:]" "[:lower:]" | sed "s/'/ /g" | sed "s/[[:punct:]]//g" | sed "s/ /-/g"

In questo comando c’è una parte variabile, la stringa “La privacy al tempo dell’Internet of Things: gran finale”, che dobbiamo cambiare ogni volta che vogliamo generare un nuovo titolo, mentre tutto il resto rimane sempre inalterato (a meno di non modificare di proposito il codice).

È sempre consigliabile separare le parti variabili del codice da quelle che rimangono sempre uguali, per evitare di alterare il programma per errore e renderlo inusabile. In questo caso, basta definire una variabile a cui viene assegnata la stringa da elaborare, usata come una specie di segnaposto nel resto del programma, e separare anche visivamente con una o più righe vuote le variabili dal resto del programma. Lo script diventa così

string="La privacy al tempo dell'Internet of Things: gran finale"

echo $string | tr "[:upper:]" "[:lower:]" | sed "s/'/ /g" | sed "s/[[:punct:]]//g" | sed "s/ /-/g"

dove la prima riga definisce la variabile string, che viene poi usata nel comando vero e proprio.

Da notare che quando si assegna una variabile in bash non si possono mettere degli spazi prima e dopo l’operatore di assegnazione =. In altre parole il nome della variabile, l’operatore e il valore della variabile devono essere scritti tutti attaccati. Inoltre, quando si usa la variabile nello script bisogna sempre anteporre il prefisso $ e scriverla come $string. Sono due particolarità di bash di cui è facile dimenticarsi quando si è abituati ad usare altri linguaggi di programmazione, a me succede anche troppo spesso.

Guardiamo ora la seconda riga. Nel comando originale da Terminale l’abbiamo scritta tutta di seguito, usando l’operatore | per trasferire il risultato di un comando al comando immediatamente successivo, che lo usa come dato di ingresso da elaborare. È una pratica che evita la creazione di troppe variabili, magari usate solo una volta, che è diventata popolare di recente in R, un linguaggio di programmazione specializzato nell’analisi statistica dei dati.

Personalmente la trovo una pratica poco lungimirante. Sarà anche comoda nel momento in cui sviluppiamo un programma, ma rende molto più difficile capire in un secondo momento quello che fa lo script. Ormai la memoria dei computer è gigantesca, possiamo benissimo sprecarne un po’ per definire qualche variabile in più.¹

Una versione riveduta del programma precedente, nella quale i risultati di ciascuna fase di elaborazione vengono salvati in una variabile diversa, può quindi essere

string="La privacy al tempo dell'Internet of Things: gran finale"

lowercase=$(echo $string | tr "[:upper:]" "[:lower:]")
del_apostr=$(echo $lowercase | sed "s/'/ /g")
del_punct=$(echo $del_apostr | sed "s/[[:punct:]]//g")
fix_spaces=$(echo $del_punct | sed "s/ /-/g")

converted_string=$fix_spaces
echo $converted_string

Qui devo ammettere di avere esagerato. Se la prima versione scritta tutta d’un fiato era difficile da leggere e da capire, usare una variabile diversa per ogni passo del programma è altrettanto estremo. Un buon compromesso potrebbe essere

string="La privacy al tempo dell'Internet of Things: gran finale"

fix_string=$(echo $string | tr "[:upper:]" "[:lower:]")
fix_string=$(echo $fix_string | sed "s/'/ /g")
fix_string=$(echo $fix_string | sed "s/[[:punct:]]//g")
fix_string=$(echo $fix_string | sed "s/ /-/g")

converted_string=$fix_string
echo $converted_string

in cui si usa una variabile (string) per la stringa da elaborare, un’altra (fix_string) per conservare i risultati intermedi ed infine un’ultima variabile (converted_string) per il risultato finale del programma.

Se si guardano attentamente le due ultime versioni dello script, si nota che ho continuato ad usare l’operatore | per inviare a sed o a tr la stringa da elaborare. Non è una contraddizione rispetto a quanto dicevo prima. Una cosa è scrivere una sequenza di quattro, cinque o più comandi collegati uno all’altro a formare una catena di montaggio inestricabile, un’altra è utilizzare ripetutamente una struttura ben definita e riconoscibile come echo $... | tr "..." oppure echo $... | sed "...".

Del resto non ci sono alternative: sia sed che tr sono fatti per operare su un file oppure in modo interattivo nel Terminale (si scrive una stringa nel Terminale, si preme Invio e sed o tr la elaborano, stampano il risultato e si mettono in attesa di una nuova stringa finché non li interrompiamo premendo CTRL-D) e l’unico modo per obbligarli a lavorare da programma e usare echo per fornirgli il dato in ingresso già bello e pronto.

Al nostro script mancano ancora due cosette per essere quasi comodo da usare, ma questo sarà l’argomento della prossima puntata.

A meno naturalmente di non avere dei grossi limiti di memoria, come succede quando si scrivono programmi per dispositivi embedded o dell’IoT, oppure di dover scrivere del codice molto efficiente per applicazioni ultrasofisticate. Ma chi è alle prese con questi problemi non ha bisogno di leggere questi articoli. ↩︎

Script per tutti i giorni: semplici modifiche alle stringhe di testo

Fri, 23 Nov 2018 18:00:00 +0000

– Foto: telwink su Flickr.

Succede più spesso di quanto mi renda conto. Devo rinominare dei file, modificare un testo o fare altri pasticci con i miei documenti. Potrei usare una delle tante applicazioni ad hoc fatte per fare proprio quello. Ma perché perdere tempo ad installare ed imparare ad usare l’ennesima applicazione se con il Terminale posso fare prima (e meglio)?

Basta qualche comando ben piazzato nel Terminale, a volte qualche piccolo script in bash o in python, e si possono fare cose bellissime con poco sforzo.

E una volta fatte, perché tenerli per se e non condividerli, magari proprio qui? L’impulso iniziale me l’ha dato Federico “frix” Morchio durante una discussione sul canale Goedel di Slack gestito dal sempre ottimo Lucio Bragagnolo (aka… oops, noto anche come Lux, Loox e tanti altri alias).

Attenzione! Questo e i futuri post sull’argomento non saranno delle introduzioni a bash, a python, al Terminale di macOS (tendo sempre a dimenticare che non si chiama più OS X!), per quelle ci sono un sacco di ottime guide in rete. Chi vuole fare in fretta può iniziare leggendo la mia piccola guida a bash di qualche anno fa, Script di shell in OS X e magari anche Compleanno con permessi, la ripresa di un vecchio post sull’ormai defunto Ping che di fatto mi ha fatto iniziare l’esperienza di blogger.

Cominciamo con un antipasto veloce, una cosa apparentemente inutile (o quasi), ma che serve a dare una idea delle potenzialità di bash e di come, partendo da un’idea semplice, si possa trasformarla a poco a poco in qualcosa di più pratico e adatto ad un uso quotidiano.

Manipolare i nomi dei file

La prima cosa che faccio quando inizio a scrivere un nuovo post è creare un file Markdown con i metadati (titolo, data di pubblicazione, categoria e tag, chi usa Jekyll o Octopress sa di cosa parlo), a cui assegno un nome temporaneo. Una volta deciso il titolo definitivo, rinomino il file in un modo più razionale, in modo che possa ritrovarlo facilmente.

Per farlo seguo la convenzione sui nomi dei file di Jekyll,¹ secondo la quale il nome del file deve essere scritto come YYYY-MM-DD-titolo-del-post.md, dove YYYY indica l’anno, MM il mese e DD il giorno di pubblicazione (espressi rispettivamente con quattro e due cifre) e parole e numeri vanno separati con un trattino invece che con uno spazio. Sembra una cosa inutilmente complicata, ma permette di tenere ordinati i file in base alla data anche quando se ne modifica il contenuto in un secondo tempo. E comunque, evitare di utilizzare gli spazi nei nomi dei file è ancora oggi la cosa più razionale da fare nei sistemi basati su Unix come macOS.

Per la data non ci sono problemi, nei metadati è già scritta nel formato giusto, per cui è sufficiente copiarla ed incollarla direttamente nel nome del file tramite il Finder. Ma il titolo? Potrei usare il Finder anche per il titolo, inserendolo dopo la data nel nome del file e sostituendo a mano gli spazi con i trattini. Però è facile sbagliare, soprattutto quando il titolo è lungo. Ancora più facile è non essere consistenti, usando ogni volta una forma leggermente diversa e mandando a pallino i vantaggi dati dall’utilizzare nomi di file ben definiti.

E poi, vuoi mettere il divertimento di farlo fare a bash?

Un pezzo alla volta

Prendiamo come esempio il titolo di un post di qualche mese fa, “La privacy al tempo dell’Internet of Things: gran finale”. Per trasformare il titolo originale in una sequenza di parole separate da trattini è sufficiente lanciare il Terminale ed eseguire il comando

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | sed "s/ /-/g"

dove echo scrive la stringa nel Terminale e la invia tramite il | (pipe) a sed, che si occupa di cercare tutti gli spazi e di sostituirli con un trattino, ottenendo

La-privacy-al-tempo-dell'Internet-of-Things:-gran-finale

Non male, ma ci sono due o tre cosette da sistemare.

Problema numero 1 (banale). Il formato di Jekyll prevede implicitamente che il nome del file sia scritto tutto in minuscolo. Personalmente trovo che questa forma sia più gradevole, ma è anche utile a semplificare e a rendere univoco l’ordinamento dei file (una fissazione, lo so, ma quando si maneggiano tantissimi file ogni giorno diventa una cosa fondamentale per lavorare meglio). Si può fare così

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | tr "[:upper:]" "[:lower:]"

dove tr trasforma i caratteri maiuscoli ([:upper:]) in minuscoli ([:lower:]), ottenendo

la privacy al tempo dell'internet of things: gran finale

Domanda #1: cosa succede se nel comando precedente si usa tr "[:lower:]" "[:upper:]"?

Problema numero 2 (importante). Nei nomi dei file è preferibile usare solo lettere non accentate, numeri e alcuni caratteri di separazione: trattino, underscore e (se proprio dobbiamo) spazio. Se possibile è meglio evitare di usare il punto, che normalmente serve per separare il nome del file vero e proprio dall’estensione (caratteristica che è stata usata parecchio per distribuire file contenti virus ma che apparivano legittimi). Tutto gli altri caratteri devono essere rigorosamente evitati, perché spesso hanno significati speciali per il sistema operativo e creano solo guai.

Per togliere la punteggiatura possiamo usare la stessa tecnica di sopra,

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | sed "s/[[:punct:]]//g"

dove in questo caso sed cerca tutti i caratteri di punteggiatura ([[:punct:]]) e li sostituisce con… niente (cioè li toglie), ottenendo in uscita

La privacy al tempo dellInternet of Things gran finale

Problema numero 3 (specifico). Il comando di prima rimuove anche gli apostrofi (che è sempre bene evitare di mettere nei nomi dei file, perché potrebbero dare problemi su sistemi operativi meno liberali di macOS).² Piuttosto che buttarli via, è preferibile però sostituirli con un trattino, usando ancora una volta sed

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | sed "s/'/-/g"

che da in uscita

La privacy al tempo dell-Internet of Things: gran finale

Mettiamo tutto insieme

Usare bash (o qualunque altra shell di Unix) è un po’ come usare il Lego dove, mettendo insieme dei piccoli mattoncini di forme e colori diversi, si può costruire una portaerei (o quasi). Con bash si prendono dei semplici comandi come quelli visti prima, si mettono nell’ordine giusto, si collega l’output di un comando con l’input di quello successivo tramite il | (pipe), e alla fine si riescono a fare delle cose anche piuttosto sofisticate.

In questo caso, il comando

$ echo "La privacy al tempo dell'Internet of Things: gran finale" | tr "[:upper:]" "[:lower:]" | sed "s/'/ /g" | sed "s/[[:punct:]]//g" | sed "s/ /-/g"

genera la stringa

la-privacy-al-tempo-dell-internet-of-things-gran-finale

pronta per essere utilizzata come nome del file.

Domanda #2: Cosa succede se cambio l’ordine dei comandi? Perché questo è l’ordine migliore per convertire un titolo nel formato desiderato?

Domanda #3: Perché nel primo sed questa volta ho sostituito l’apostrofo ' con uno spazio (mentre nella descrizione del problema numero 3 avevo usato un trattino)?

Chi ha avuto la pazienza di leggere fin qui, si starà chiedendo che senso abbia complicarsi la vita con il Terminale e con bash, quando è molto più veloce modificare il titolo a mano nel Finder.

Tutto vero, ma è altrettanto vero che il post è stato più che altro una scusa per introdurre due comandi come sed e tr, molto utili ma anche molto poco conosciuti. E poi, partendo da questa base si possono costruire delle cose molto più utili, ma questo lo vedremo la prossima volta.

Revisioni

3-12-2018: Corretta una incongruenza nel testo originale, nel quale veniva usato una volta sed e un’altra tr per rimuovere i caratteri di punteggiatura.

Che poi è praticamente la stessa convenzione che usa Wordpress per generare i nomi dei post. ↩︎
La gestione generale dei caratteri accentati nei nomi dei file è un problema molto più complesso, che è meglio rimandare ad un post specifico sull’argomento, ammesso che ci sia interesse per l’argomento. ↩︎

Script per tutti i giorni: ricapitoliamo

Tue, 30 Jan 2018 18:00:00 +0000

– Foto: Glucksman Library at Limerick su Flickr.

Prima di proseguire con questa serie dedicata alla scrittura di piccoli script in bash e affini, mi sembra utile ricapitolare i concetti principali delle prime tre puntate (qui i link alla prima, seconda e terza puntata).

Case e cartelle

Come tutti i sistemi basati su Unix, anche macOS è progettato per essere usato da più utenti, anche in contemporanea. Nella pratica non è così, nella maggior parte dei casi il Mac è usato da un solo utente e solo di rado vengono attivati degli account per più di tre o quattro utenti, però la funzionalità c’è.

Di conseguenza ciascun utente del Mac dispone di un’area personale dove salvare tutti i documenti, dati e file di configurazione, nettamente separata da quelle degli eventuali altri utenti del sistema. Non a caso quest’area personale è denominata Home, la casa dell’utente.¹

Dal punto di vista pratico l’area personale di ciascun utente è costituita da una cartella, rappresentata dall’icona di una casetta e denominata con il nome account (o nome breve), cioè con il nome utilizzato per fare il login sul Mac, che viene assegnato all’utente una volta per tutte al momento della creazione dell’account. All’interno di questa cartella principale ci sono un certo numero di cartelle standard gestite automaticamente dal sistema operativo,² ma niente impedisce di definire delle ulteriori cartelle personali. Io ad esempio uso la cartella Documenti solo per i file generati automaticamente da certe applicazioni e conservo tutti i miei documenti in alcune cartelle ben definite contenute nella mia Home, dentro le quali ci sono un gran numero di sottocartelle più specifiche.

Una delle cartelle contenute nella mia Home è Development, che uso da sempre per salvare i progetti generici relativi allo sviluppo software (quelli più strettamente collegati alla mia attività lavorativa sono altrove). Proprio per questo ho preferito salvare in questa cartella anche tutti i piccoli programmi proposti nel corso di questa serie, consigliando i lettori di fare altrettanto in modo da seguire più facilmente gli esempi riportati. Chi preferisce usare una cartella diversa dovrà ricordarsi di modificare di conseguenza i percorsi dei comandi.

Già che siamo in tema di cartelle, ribadisco quello che ho scritto nella terza puntata. I termini directory e cartella sono perfettamente equivalenti, io preferisco usare il primo ma so benissimo che nell’uso comune prevale nettamente il secondo, non a caso in tutte le interfacce grafiche l’icona che rappresenta la directory è proprio quella di una cartella di documenti. Ho deciso quindi di uniformarmi all’uso comune e usare il termine “cartella” nel testo discorsivo degli articoli, ma di continuare ad utilizzare “directory” quando il discorso si fa più tecnico, ad esempio ogni volta che tratterò di comandi dei bash e del Terminale.

Il Terminale di macOS

Chi legge i miei post sa che uso moltissimo il Terminale, l’interfaccia a linea di comando di macOS, e lo considero uno strumento insostituibile quando si tratta di eseguire compiti complessi e ripetitivi. Provate ad usare un programma con interfaccia grafica per convertire un centinaio di immagini da un formato ad un altro, sovrapponendo a ciascuna immagine una scritta variabile e poi ditemi.

In macOS il Terminale si trova nella cartella Utility, posta all’interno della cartella Applicazioni, un percorso che possiamo scrivere in modo più compatto come Applicazioni > Utility, dove il simbolo > indica il passaggio da una cartella ad un’altra contenuta al suo interno. Se lo usate spesso e vi secca doverlo andare a cercare ogni volta, aggiungetelo al Dock e vi basterà un click per lanciarlo.

La prima (o la prossima) volta che usate il Terminale fatevi un favore e cambiate un paio di cosette nella sua configurazione standard.

Innanzi tutto lanciate le Preferenze del Terminale, scegliete un profilo più gradevole di quello tutto bianco di base e rendetelo il profilo di default (io preferisco Ocean o Homebrew, ma è una questione di gusti personali). Per farlo, cliccate sull’icona Profili situata nella barra degli strumenti, selezionate dal pannello laterale sinistro il profilo che preferite e infine cliccate sul tasto Default posto proprio in fondo al pannello. Se volete provare i vari profili prima di decidere quale vi piace di più, vi basta fare un doppio click sulle anteprime situate nel pannello laterale.

Chissà perché Apple ha scelto per il Terminale una impostazione di default di appena 80 caratteri per 24 righe (80x24), forse voleva ricordarci come poteva essere lavorare sullo schermo di un Apple II (già in versione “espansa”)! Ma siamo in pieni anni 2000 e un Terminale più grande è decisamente più comodo. Per cui, una volta selezionato il profilo grafico preferito, potete cambiare le dimensioni della finestra del Terminale selezionando il pannello Finestra nell’area centrale delle Preferenze del Terminale e inserendo le dimensioni che preferite, in termini di righe e colonne. Io in genere uso finestre di Terminale da 120 colonne per 40 righe (120x40), forse mi ricorda qualcosa ma comunque mi sembra un buon equilibrio fra ingombro sullo schermo e comodità d’uso.

Se non avete idea di quanto queste dimensioni in righe e colonne si traducano in dimensioni reali sullo schermo, rilanciate il Terminale (per attivare il profilo di default) e allargate la finestra finché non diventa grande abbastanza per i vostri gusti, esattamente come fareste con qualunque altra applicazione per macOS. Per rendere queste dimensioni le nuove impostazioni di default, non dimenticate di cliccare sulla voce Utilizza impostazioni come default del menu Shell (che potrei scrivere anche come Shell > Utilizza impostazioni come default, dove il simbolo > serve in questo caso a separare le voci di menu da selezionare in sequenza).

Il prompt del Terminale

Se l’avete chiuso, lanciate di nuovo il Terminale e guardate con attenzione la finestra che appare. È praticamente vuota, tranne due brevi righe di testo. Se non avete fatto altre modifiche alla configurazione del Terminale rispetto a quelle proposte qui sopra, nella prima riga c’è la data e l’ora correnti con l’indicazione del numero del terminale virtuale correntemente aperto, ttys001, ttys002 e così via. Il Terminale di macOS, infatti, non è altro che un emulatore software dei terminali fisici con i quali, fino agli anni ‘80, ci si collegava ai grossi computer delle università o delle aziende mediante un protocollo di comunicazione seriale analogo a quello delle telescriventi. In inglese la telescrivente si chiama Teletype o TTY e l’acronimo è rimasto ancora in uso per indicare appunto i terminali, ormai diventati solo virtuali, dei sistemi Unix come Linux e macOS.

Nella seconda riga invece compare il nome del vostro Mac, quello che avete definito nel pannello Condivisione delle Preferenze di Sistema, seguito dai due punti e dal nome della directory corrente, che in questo momento dovrebbe essere la Home del vostro account, rappresentata dal simbolo tilde, ~ (in macOS la tilde si scrive premendo ALT-5). Subito dopo il nome della directory corrente c’è uno spazio, il vostro nome account e infine il simbolo del dollaro, $.

nome-computer:directory nome-account$

Questa riga si chiama il prompt del Terminale, riesce a dare parecchie informazioni utili in modo compatto e, volendo, può essere modificata a piacere (mai capito perché, però se queste cose vi piacciono potete usare questo generatore online).

Quando si descrivono i comandi della shell (che quasi sempre è bash), il prompt del Terminale viene rappresentato spesso con il solo simbolo $, tralasciando tutto quello che c’è prima. Non bisogna mai dimenticare che il $ (o l’intero prompt) serve solo a mettere in evidenza che stiamo usando il Terminale ma non fa parte dei comandi della shell, per cui non dobbiamo mai scriverlo quando interagiamo con il Terminale, magari copiando i comandi dagli articoli di questa serie.

Pillole di bash

E veniamo finalmente ad alcuni fra i comandi principali di bash. Primo fra tutti cd che permette di muoversi fra le directory del disco rigido. Il comando cd deve essere seguito dal percorso completo da seguire per arrivare alla directory desiderata, per cui

$ cd Development

ci fa passare nella cartella Development (supponendo di partire dalla Home), mentre

$ cd Music/iTunes

ci fa andare direttamente nella cartella iTunes contenuta all’interno di Music.

Se ci sentiamo persi, possiamo usare

$ cd

per tornare nella nostra Home, oppure

$ pwd

per stampare nel Terminale il percorso completo della directory in cui ci troviamo. Tutti i percorsi riportati da pwd partono dalla directory /, la radice (o root) del disco rigido,³ per cui se ci troviamo nella Home dell’utente alice, l’esecuzione di pwd restituirà

$ pwd
/Users/alice

dove, come abbiamo già visto, alice è il nome account dell’utente che ha effettuato il login sul Mac. Da notare che in macOS tutte le Home degli utenti si trovano all’interno della directory /Users, a differenza della maggior parte degli altri sistemi operativi basati su Unix (Linux e i vari BSD) che sono più banali ed usano /home.

E per sapere qual’è il nostro nome account? C’è un comando anche per questo,

$ whoami

forse scritto da qualche filosofo esistenzialista.

Con il comando cd si utilizzano spesso delle abbreviazioni molto comode: ~ che indica la nostra directory Home, . che indica la directory corrente (quella riportata da pwd) e .. che invece indica la directory che contiene la directory corrente. Se in questo momento ci troviamo nella directory ~/Music/iTunes

$ cd ..

ci fa fare un passo indietro tornando a ~/Music, mentre

$ cd ~

ci fa tornare nella nostra Home (ma basta anche il solo cd).

Un altro comando fondamentale di bash è echo, che stampa una stringa sul Terminale

$ echo "questa è una stringa"
questa è una stringa

Non è nemmeno necessario racchiudere la stringa fra virgolette, echo stamperà sul Terminale tutto ciò che viene immediatamente dopo il comando, quindi va altrettanto bene scrivere

$ echo questa è una stringa
questa è una stringa

È molto comune utilizzare echo per scrivere direttamente in un file invece che sul Terminale tramite l’operatore di redirezione >

$ echo "questa è una stringa" &#62; file.txt

Se il file file.txt non esiste, echo lo crea da zero e ci scrive dentro la stringa, altrimenti sovrascrive il contenuto precedente di file.txt e lo sostituisce con la nuova stringa. Se vogliamo che il nome del file da creare contenga degli spazi lo dobbiamo racchiudere fra virgolette, non importa se semplici o doppie

$ echo "questa è una stringa" &#62; "file con spazi.txt"

Per scrivere con echo in un file senza perdere il contenuto già esistente, dobbiamo usare l’operatore >> che aggiunge (append) una nuova stringa alla fine del file file.txt

$ echo "questa è una stringa" &#62;&#62; file.txt

Anche in questo caso, se il file file.txt non esiste echo lo crea da zero e ci scrive dentro la stringa.

Gli operatori di redirezione > e >> assomigliano moltissimo ad un altro operatore che abbiamo incontrato più volte nel corso delle puntate precedenti, il | (pipe), che serve a fare in modo che l’output di un comando venga utilizzato come input del comando successivo. Come in questo caso

$ echo "questa è una stringa" | tr "[:lower:]" "[:upper:]"
QUESTA È UNA STRINGA

dove il primo comando echo scrive una stringa e la invia a tr che a sua volta la converte in caratteri maiuscoli e stampa il risultato finale sullo schermo.

Sempre restando in tema di file, ci sono due comandi importantissimi ma piuttosto complicati, chmod e chown, che permettono rispettivamente di cambiare i permessi di lettura (r), scrittura (w) ed esecuzione (x) dei file, e di assegnare la proprietà di un file ad un determinato utente o gruppo di utenti. In questo momento non ha senso entrare nei dettagli dei due comandi, per ora basterà sapere che

$ chmod u+x script.sh

rende lo script script.sh eseguibile da parte dell’utente corrente del Mac, mentre

$ chmod u-x script.sh

rimuove l’autorizzazione precedente. Invece

$ chmod a+x script.sh

rende lo script eseguibile da tutti gli utenti e il suo contrario

$ chmod a-x script.sh

impedisce a tutti gli utenti, quindi anche a noi stessi!, di eseguire lo script in questione.

Per quanto riguarda chown

$ chown alice file.txt

rende file.txt di proprietà dell’utente alice.

I permessi di un file si possono verificare tramite ls, un comando utilizzato di continuo in una qualunque sessione del Terminale per mostrare il contenuto di una directory, cioè tutti i file e le directory (per Unix non c’è differenza) che si trovano all’interno di una directory data. La directory su cui deve operare ls va indicata subito dopo il comando, se non scriviamo niente ls mostra il contenuto della directory corrente.

Il comando ls liscio mostra il contenuto di una directory in forma di tabella, e l’unico modo per distinguere i file dalle directory è tramite l’estensione: normalmente i nomi dei file terminano con una estensione costituita da un punto e da tre lettere mentre le directory non hanno estensione (ma non è detto che sia sempre così). Ad esempio

$ ls ~
Applications  Documentation Library       My Documents  Public        Tmp
Desktop       Documents     Movies        Papers        Research      bin
Development   Downloads     Music         Pictures      Sites

elenca tutte i file e le directory contenuti nella Home del mio Mac (in effetti compaiono solo delle directory). Usato così, ls serve a poco. Molto meglio

$ ls -l

che mostra il contenuto di una directory in forma di lista invece che di tabella, riportando in più una serie di informazioni dettagliate su ciascun file (o directory).

In particolare, la prima colonna contiene una sequenza di 10 simboli – in genere -, d, r, w, x, qualche rara volta anche s o S – che ci dicono se abbiamo a che fare con un file o una directory e quali sono i permessi associati al file stesso (o alla directory).⁴ Il trattino, -, indica che il permesso corrispondente non è assegnato. I dettagli possono essere letti qui o su una qualsiasi guida introduttiva a bash, come quelle riportate nella Bibliografia qui sotto. A noi basta sapere che la d in prima posizione indica una directory e che se troviamo una x nella quarta, settima o decima posizione significa che il file è eseguibile rispettivamente dall’utente corrente, dagli utenti che fanno parte del suo stesso gruppo o infine da tutti gli utenti del Mac.

Facciamo un esempio pratico: supponiamo di aver creato nella cartella Development lo script script.sh, contenente una serie di comandi bash; appena creato lo script ha i permessi attribuiti di default a un file generico

$ ls -al script.sh 
-rw-r--r--  1 nome-account  staff  0 Jan 25T22:07:00 script.sh

e poiché non troviamo nessuna x, significa che non può essere eseguito da nessun utente. Per renderlo eseguibile dall’utente attuale del Mac

$ chmod u+x script.sh

come si vede eseguendo di nuovo ls

$ ls -al script.sh 
-rwxr--r--  1 nome-account  staff  0 Jan 25T22:07:00 script.sh

e notando che il - in quarta posizione è diventato una x. Se invece rendiamo il file eseguibile a tutti gli utenti con

$ chmod a+x script.sh

l’output di ls sarà

$ ls -al script.sh 
-rwxr-xr-x  1 nome-account  staff  0 Jan 25T22:07:00 script.sh

dove si vede che i trattini in quarta, settima o decima posizione sono diventati delle x. Per riportare tutto alla situazione iniziale

$ chmod a-x script.sh 
$ ls -al script.sh 
-rw-r--r--  1 nome-account  staff  0 Jan 25T22:07:00 script.sh

Prima di concludere questa lunghissima introduzione a bash, ecco alcuni comandi relativi alla creazione e cancellazione di file e directory. Per creare un file ci sono cento modi diversi, abbiamo già visto come farlo con echo, ma possiamo utilizzare anche il comando touch, che crea un file vuoto da utilizzare in un secondo momento, per cui

$ touch new_file.txt

crea il file vuoto new_file.txt nella directory corrente.

Per rimuovere un file si usa invece rm seguito dal nome del file, quindi

$ rm new_file.txt

cancella il file che abbiamo appena creato con touch.

Analogamente, per creare una directory si usa mkdir (abbreviazione di make directory), per rimuoverla rmdir (abbreviazione di remove directory), seguiti in entrambi i casi dal nome della directory da creare o da rimuovere

$ mkdir nuova_directory
$ rmdir nuova_directory

Anche in questo caso, se il nome della directory da creare (o da rimuovere) contiene degli spazi, deve essere racchiuso fra virgolette semplici o doppie. Per evitare errori che potrebbero essere disastrosi, si può rimuovere una directory solo se è vuota, cioè se non contiene altri file o altre directory.

Credo che per ora possa bastare…

Conclusioni

Questo articolo è cresciuto ben oltre le previsioni iniziali. Purtroppo era necessario farlo, sia per ricapitolare in modo organico le cose dette nelle prime tre puntate, sia per creare un linguaggio di base che permettesse di andare avanti più spediti, evitando di perdersi in troppi dettagli che rallentano e rendono più pesante l’esposizione. Alla prossima puntata con qualche cosa di nuovo e, spero, di interessante!

Bibliografia

I titoli su bash si sprecano. Fra questi vorrei segnalare due guide in italiano e due in inglese. Purtroppo il materiale di qualità in italiano è scarso e le traduzioni dall’inglese sono per forza di cose molto più datate delle versioni originali (lo potete notare chiaramente confrontando le date delle versioni più recenti in italiano e in inglese della guida di Cooper), per cui è quasi sempre preferibile consultare i manuali e i tutorial originali in inglese. Per fortuna l’inglese tecnico è molto comprensibile e non ci vuole molto per riuscire a leggerlo in modo fluido. Certo, se la scuola non facesse di tutto per renderlo odioso, le cose sarebbero più semplici per tutti.

Garrels, La guida di Bash per i principianti, 2008.
Cooper, Guida avanzata di scripting Bash, rev. 4.1, 2006.
Cooper, Advanced Bash-Scripting Guide, rev. 10, 2014.
Wikibooks, A Quick Introduction to Unix.

Purtroppo nella versione italiana di macOS è stata tradotta con Inizio, che non rende altrettanto bene l’idea. Io non posso soffrire il termine inizio e userò sempre Home. ↩︎
Fra cui Filmati, Immagini e Musica per i file multimediali, Download per i file scaricati da internet, Documenti per i file personali e Scrivania per i (troppi) file buttati alla rinfusa sul Desktop, cioè sulla scrivania virtuale del Mac. ↩︎
O meglio, del file system del disco rigido. Il disco rigido in sé è solo un oggetto hardware che non serve a molto finché non lo si formatta, creando una struttura dati (il file system, appunto) che possa essere utilizzata dal sistema operativo per memorizzare i file. ↩︎
In macOS possono anche essere presenti i simboli + o @ nell’undicesima posizione della colonna. ↩︎

Divertirsi con il terminale

Sun, 12 Feb 2017 06:05:00 +0000

Siete dei fanatici della linea di comando? Volete mettere alla prova la vostra conoscenza del terminale – l’interfaccia a linea di comando di Linux o di macOS/OS X – e della shell bash?

Se avete risposto ‘si’ ad entrambe le domande, fatevi un giretto su Commandline Challenge e mettete alla prova le vostre capacità, risolvendo le sfide proposte.

Alcune possibili soluzioni sono molto più involute ed intricate di quanto sarebbe normale, ma dimostrano allo stesso tempo una maestria con i comandi della shell che rasenta l’arte.

Post Scriptum. Non prendetevela con me se la vostra produttività crolla vertiginosamente dopo aver letto questo post!

Command line fun

Sun, 12 Feb 2017 06:00:00 +0000

Are you a fan of the command line? Do you wish to test your knowledge of the terminal – the command line interface of Linux or macOS/OS X – and of the bash shell?

If you answered ‘yes’ to the questions above, head your browser to Commandline Challenge and test your skills trying to solve the challenges proposed there.

Some of the possible solutions are much more convoluted than normal, but they also show a technical mastery that resembles art.

Disclaimer. It is not my fault if your productivity sinks after reading this post!

Compleanno con permessi

Sun, 18 Dec 2016 06:00:00 +0000

Oggi melabit compie tre anni. Per l’occasione ho chiesto all’amico Lux il permesso di ripubblicare un mio vecchio intervento sul suo (bellissimo) blog Ping, chiuso purtroppo con la cessazione della pubblicazione dell’edizione italiana di Macworld.

Perché pubblicare di nuovo questo articolo dopo più di sei anni?

Innanzi tutto perché quello che c’è scritto è ancora attuale e, come ha scritto a suo tempo Lux con il suo stile inimitabile, può essere utile per “avvicinarsi agli incantesimi Unix che danno vita al mondo magico di Mac OS X”, una cosa a cui tengo sempre moltissimo. Magari oggi proporrei di usare sul Mac launchd al posto di cron, anche se quest’ultimo rimane la soluzione più generica, valida su un qualunque sistema Unix.

C’è poi un motivo più personale: proprio dopo questo intervento ho cominciato a pensare che tenere un blog non fosse un’idea proprio fuori dal mondo. Ci ho messo un po’ (come sempre!) a realizzarla, ma dopo tre anni devo ammettere che è stata un’ottima decisione, le soddisfazioni non sono mancate.

Introduzione

L’articolo rispondeva all’esigenza di un lettore di Ping di cambiare automaticamente i permessi di determinati tipi di file contenuti in una cartella del Mac. Cosa ci può essere di meglio del Terminale per fare queste cose?

Ho lasciato praticamente inalterato il testo originale, limitandomi a correggere alcune imprecisioni e ad aggiungere qualche dettaglio qui e là.

Me li do io i permessi

Premessa #1: il Terminale in Mac OS X si trova in Applicazioni > Utility. Una volta lanciato può essere configurato in molti modi (tramite le Preferenze) perdendo quell’aspetto un po’ triste e troppo serioso che spaventa l’utente normale.

Dopo l’avvio, il Terminale presenta il cosiddetto prompt, che su OS X mostra tipicamente il nome del computer, la cartella dove ci si trova e il nome dell’utente. L’ultimo carattere del prompt è normalmente il $. Nel Terminale i comandi vengono inseriti dopo il simbolo $ su quella che viene definita la riga di comando e si eseguono premendo il tasto Invio.

Il Terminale di OS X esegue di default la cosiddetta shell bash, uno strumento potentissimo per interagire con il sistema operativo. La shell bash può essere usata direttamente, scrivendo i comandi uno ad uno sulla riga di comando e leggendone il risultato direttamente nel Terminale.

Oppure si possono scrivere degli script, piccoli programmi nel linguaggio di bash nei quali si inseriscono in sequenza i comandi da far eseguire alla shell, che si dimostrano molto utili per automatizzare delle operazioni che eseguiamo ripetutamente sul Mac.

Premessa #2: perché usare i comandi di bash invece di Automator o di AppleScript? Beh, innanzitutto perché bash è multipiattaforma e quindi funziona su Linux e, volendo, anche su Windows. E poi semplicemente perché bash mi piace!

Lanciamo quindi il Terminale (magari configurandolo prima, io consiglio almeno di aumentare le dimensioni della finestra a circa 100×40 per stare comodi e di scegliere un tema grafico più accattivante di quello bianco e un po’ spento di default) e iniziamo a lavorare.

Creiamo innanzi tutto una cartella ~/bin, dove il carattere ~ (tilde, ALT+5) indica per convenzione sui sistemi basati su Unix la cartella Inizio (detta anche Home) dell’utente che sta usando il computer in questo momento. Per farlo da Terminale, digitiamo (ATTENZIONE, come già detto $ indica solo l’ultimo carattere del prompt e NON va mai inserito nei comandi seguenti):

$ cd
$ mkdir bin
$ chflags hidden bin
$ cd bin

Il primo comando serve per essere sicuri di partire dalla Home, il secondo crea una nuova cartella bin nella Home, il terzo la nasconde al Finder e l’ultimo comando ci fa spostare nella cartella bin appena creata.

In teoria siamo liberi di salvare i nostri comandi bash in una qualunque cartella del Mac e possiamo anche usarne una già esistente. Ma usare la cartella bin nella nostra Home rispetta le convenzioni dei sistemi Unix e mi sembra preferibile.

A questo punto usiamo nano (un editor testuale molto semplice installato di default sul Mac) per editare lo script bash cambia_permessi, nel quale inseriremo i comandi veri e propri che ci servono per cambiare i permessi dei file contenuti nella cartella nella quale verrà eseguito lo script:

$ nano cambia_permessi

Non preoccupatevi per l’interfaccia un po’ ostica di nano, qui ci basta usare solo due comandi, CTRL+O per salvare il file editato e CTRL+X per uscire da nano. Dimenticavo: CTRL+O significa premere contemporaneamente il tasto CTRL, l’ultimo in basso a sinistra sulle tastiere Mac (nei portatili è a fianco di fn), e il tasto O. Analogamente per CTRL+X.

Torniamo al nostro file cambia_permessi. A questo punto bisognerebbe copiare a mano le linee mostrate qui sotto. Ma OS X è furbo e il copia e incolla funziona anche nella finestra del Terminale, per cui è sufficiente selezionare tutte le linee mostrate qui sotto, copiarle e poi incollarle nella finestra del Terminale dove è attivo nano:

#!/bin/bash
#
DIR=~/scansioni/
FILES=*
PERM=u+rw
#
if [ -d $DIR ]; then
	cd $DIR
	chmod -R $PERM $FILES
	cd
fi

Salviamo lo script premendo CTRL+O ed usciamo da nano con CTRL+X.

Cosa significano questi comandi? Il più importante è chmod, che cambia i permessi di tutti i file contenuti nella cartella ``~/scansioni/` in modo che siano leggibili e scrivibili dall’utente attuale del Mac. Il resto è solo roba di contorno.

Quello che è ancora più importante è che lo script è totalmente parametrico: basta cambiare i valori di DIR, FILES e PERM per adattarlo alle proprie esigenze.

Per esempio, se la cartella ~/scansioni/ contenesse vari tipi di file e si volessero cambiare i permessi dei soli file pdf lasciando gli altri file invariati, la riga FILES=* diventerebbe FILES=*.pdf.

Non è finita. Controlliamo prima di tutto di avere veramente fatto tutto bene con il comando:

$ cat cambia_permessi

che dovrebbe mostrare sullo schermo lo script appena inserito.

Per semplificarci la vita, rendiamo lo script eseguibile con il comando:

$ chmod u+x cambia_permessi

Bisogna notare che con questo comando abbiamo reso eseguibile lo script solo per l’utente attuale del Mac. I motivi li tralascio per brevità, ma credetemi, è decisamente meglio fare così.

Un ultimo passo necessario. In questo momento, per cambiare i permessi dei file nella cartella ~/scansioni/ bisogna eseguire a mano il comando dal Terminale:

$ ~/bin/cambia_permessi

(anche se, per come è configurato di default OS X, usare soltanto $ cambia_permessi, senza scrivere esplicitamente il percorso dove è salvato lo script basta e avanza).

Ciò è sicuramente molto più comodo di cambiare uno ad uno i permessi dei file, ma si può fare di meglio.

Qui entra in gioco cron, uno strumento che esegue dei comandi stabiliti dall’utente a intervalli di tempo predefiniti. Sembra una cosa un po’ cretina, ma in realtà permette di far fare al computer un mare di cose automaticamente. Purtoppo la sintassi di cron è orrenda. E questo post sta diventando troppo lungo.

Cercherò di sintetizzare ma se qualcuno è interessato posso scrivere qualcosa in proposito. (Nel frattempo l’ho fatto, chi fosse interessato può leggere questo articolo dettagliato su cron.)

Diciamo che vogliamo che ogni cinque minuti lo script cambia_permessi venga eseguito automaticamente. Dal solito Terminale dobbiamo allora eseguire i comandi:

$ export EDITOR=/usr/bin/nano
$ crontab -e

La prima riga serve ad evitare di usare l’editor preimpostato, vi, vn vero reperto archeologico che sarebbe bene dimenticare una volta per tutte. Dovrebbe invece aprirsi il solito nano, in cui dobbiamo incollare esattamente la riga seguente:

*/5 * * * * ~/bin/cambia_permessi

(prima e dopo ciascun asterisco è presente una tabulazione), eventualmente aggiungendola in coda ai comandi già presenti.

Salviamo con CTRL+O e usciamo da crontab con CTRL+X.

Ovviamente se vogliamo che lo script venga eseguito più o meno frequentemente, basta cambiare il valore */5 in, diciamo, */2 o */15 (per eseguire lo script ogni 2 o 15 minuti). Per casi più complicati basta leggere qui.

Abbiamo finito. Sembra complicato, ma credetemi, è molto più lungo da leggere (e da scrivere!) che da mettere in pratica.

Nota finale

Per chi ha paura del Terminale e soprattutto di cron, un programma potente ma, bisogna ammetterlo, ben poco user-friendly, ecco una soluzione aggiuntiva, farina di Lux.

Aggiungo solo una piccola nota per gli inesperti di Terminale che si scontrano con cron (e, su Snow Leopard, con launchd). Una scorciatoia artigianale consiste nel definire un evento ricorrente dentro iCal e, nelle informazioni relative, stabilire che in occasione dell’evento va eseguito uno script.

Molto pratica se si ha bisogno di ripetere uno script una o due volte al giorno al massimo, in tutti gli altri casi temo che finirebbe per riempire all’inverosimile il proprio Calendario, con conseguenze che francamente mi sfuggono.

Duecento

Tue, 05 Jul 2016 06:00:00 +0000

Con il post di sabato scorso siamo arrivati a 200. Due anni e mezzo di melabit e duecento post, in media uno ogni quattro giorni e mezzo. Non male, se si considerano i tanti impegni di ogni giorno, che mi impediscono di dare una periodicità più serrata al blog.

Poiché questo in fondo è un blog dedicato alla programmazione e ai sistemi operativi (anche se me ne dimentico spesso), invece di celebrare l’evento preferisco prendere la palla al balzo e descrivere alcuni semplici comandi di Terminale, che userò per fare una piccola analisi dei post scritti finora.

Lancio il Terminale (chi segue con continuità il blog dovrebbe sapere come fare, per gli altri il Terminale si trova in Applicazioni > Utility) e mi sposto nella cartella (directory) che contiene tutti i miei post,

$ cd ~/cartella/del/blog/

Per prima cosa voglio controllare di aver scritto veramente 200 post.

Sin dall’inizio ho deciso di usare per i nomi dei file sorgenti dei post il formato anno-mese-giorno-titolo-separato-da-trattini.md, dove anno-mese-giorno indica la data di pubblicazione, ad esempio 2016-07-05 per questo post, e .md è l’estensione standard dei documenti scritti in Markdown, il linguaggio di formattazione per il web che uso per scrivere questi post. La cartella contiene altri file e cartelle, ma solo i post completi hanno il nome in questo formato. Per contare i post contenuti nella cartella mi basta quindi eseguire il comando,

$ ls 20*.md | wc

che con ls (list) elenca tutti i file il cui nome inizia con il secolo corrente e termina con il suffisso .md. L’output di ls viene inviato tramite il simbolo | (pipe) ad un ulteriore comando del Terminale (in realtà della shell bash, ma oggi non voglio essere troppo pignolo), wc (word count), che conta il numero di linee, parole e caratteri (e volendo anche di byte) di un file o, come in questo caso, dell’output del comando precedente.

La risposta del Terminale è

201     202    8704

dove il primo numero rappresenta il numero di linee dell’output di ls, cioè il numero dei file elencati da ls che rispettano le specifiche stabilite dal comando (e di conseguenza il numero dei post).

Il Terminale quindi mi dice che finora ho scritto 201 post. 201? Certo, i post sono 201 perché nella lista c’è anche questo post (potrei fare in modo da non considerarlo, ma renderebbe tutto inutilmente più complicato).

C’è però un dettaglio che non torna. Il secondo numero, 202, indica il numero di parole dell’output di ls. Poichè, come già notato, il nome dei file è nel formato anno-mese-giorno-titolo-separato-da-trattini.md, che per wc equivale ad una parola singola, i primi due numeri restituiti da wc dovrebbero essere identici. Se il Terminale indica che c’è una parola in più, significa che uno dei file contiene nel nome (per sbaglio) uno spazio al posto del trattino.

Per cercare il file in questione, eseguo questa volta

$ ls 20*.md | grep " "

inviando l’output di ls a grep, uno dei tool più importanti del Terminale, che serve per cercare una o più stringhe di testo in un file. Normalmente la ricerca viene effettuata usando una espressione regolare, ma in questo caso è più che sufficiente limitarsi a cercare la presenza di un semplice spazio nell’output di ls. La risposta è,

$ 2015-12-23-first-draft-la prova.md

dove manca effettivamente il trattino fra “la” e “prova”. Correggo subito, eseguo di nuovo

$ ls 20*.md | wc
     201     201    8704

e questa volta ottengo il risultato che mi aspetto.

Ora che ci siamo scaldati, proviamo qualcosa di più divertente. Voglio sapere quante parole in tutto ho scritto finora in questi famosi 200 post. Facile, basta sostituire ad ls il comando cat (concatenate), che stampa sul Terminale il contenuto dei file indicati dopo il comando. Eseguendo

$ cat 20*.md

non faccio altro che stampare sullo schermo uno dietro l’altro il contenuto di tutti i file dei post. La stampa dei file è velocissima, ma scrollando all’indietro nel Terminale si può verificare che ci sono veramente tutti. Se volessi potrei usare less,

$ cat 20*.md | less

per stampare i file riempiendo una pagina alla volta del Terminale (e potendo anche tornare indietro). Ma non mi interessa, preferisco inviare l’output di cat a wc,

$ cat 20*.md | wc
   10639  113141  836099

da cui risulta che i 200 (anzi 201) post scritti finora sono composti in tutto da 10639 linee (che equivalgono in pratica ai paragrafi, separati fra loro da un a capo) e da ben 113141 parole.¹

Ogni post è quindi composto in media da

$ echo "113183 / 200" | bc
565

ben 565 parole.² Per calcolare la media ho usato bc, la calcolatrice integrata nel Terminale, un oggetto poco conosciuto ma a volte molto comodo. Anche in questo caso ho utilizzato il pipe (|) per inviare alla calcolatrice l’outupt di echo, il comando che stampa su schermo la stringa (o le stringhe) che lo segue. Volendo avrei anche potuto usare bc in modo interattivo,

$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
...
113183 / 200
565
quit

Il risultato non è precisissimo, ogni file dei post ha anche una intestazione che non compare su Wordpress e che contiene titolo, data, categoria e tag, e così via. E poi non bisogna dimenticare che c’è di mezzo anche questo 201-esimo post, che è già ben più lungo di 565 parole. Ma insomma, ad occhio dovremmo essere più o meno sulle 520-530 parole effettive per post.

Ma c’è modo di vedere quante parole ci sono in ciascuno dei post? Certo, basta racchiudere i comandi precedenti in un ciclo for,

$ for i in `ls 20*.md`; do echo $i; cat $i | wc -w; done

dove i è l’indice del ciclo for, a cui viene associato di volta in volta uno dei nomi di file stampati da ls. Nel corpo del ciclo do... done, per ogni valore di $i (in bash, ogni volta che si usa una variabile, le si antepone il $), si stampa con echo $i prima il valore della variabile (cioè il nome del file), poi si usa cat $i | wc -w per stampare il contenuto del file e inviarlo al contatore wc. L’opzione -w (word) di wc serve per contare solo le parole. Eseguendo il ciclo ottengo

$ for i in `ls 20*.md`; do echo $i; cat $i | wc -w; done
2013-12-18-il-migliore-spot.md
     238
2013-12-18-melabit-il-blog.md
     497
2013-12-19-una-pinta-di-tablet.md
     346
2013-12-20-la-dogana.md
     165
2013-12-21-rinominare-i-file-con-il-terminale.md
     669
...
2016-05-24-rapidweaver-7-in-anteprima.md
     729
2016-05-27-cartellino-rosso-su-facebook.md
    1385
2016-05-28-la-matematica-di-facebook.md
     356
2016-06-05-playlist-per-bora-bora-brian-boru.md
     278
2016-07-02-da-latex-a-word-e-ritorno.md
    2278
2016-07-05-duecento.md
     987

Per analizzare i dati è più comodo salvare la lista su un file, facendo in modo che il titolo del post e il conteggio delle parole stiano sulla stessa linea.

Facile, per salvare l’output di un comando di Terminale su un file si usa il simbolo > seguito dal nome del file (ricapitolando, il simbolo | invia l’output di un comando ad un altro comando, mentre il simbolo > lo invia ad un file). Per stampare titolo e conteggio sulla stessa linea, è sufficiente aggiungere al comando echo l’opzione -n (no newline).

Eseguendo il comando così modificato,

$ for i in `ls 20*.md`; do echo -n $i; cat $i | wc -w; done &#62; ~/Desktop/words.dat

compare sul Desktop il file words.dat, le cui prime 5 righe sono,

$ head -5 ~/Desktop/words.dat
2013-12-18-il-migliore-spot.md     238
2013-12-18-melabit-il-blog.md     497
2013-12-19-una-pinta-di-tablet.md     346
2013-12-20-la-dogana.md     165
2013-12-21-rinominare-i-file-con-il-terminale.md     669

esattamente come richiesto. Partendo da questi dati, è facile calcolare la distribuzione del numero di post in funzione del numero di parole,

da cui è evidente che quasi la metà dei post contiene non più di 300 parole.

Più specificatamente, si trova che la mediana è uguale a 346, che significa che metà dei post contiene meno di 346 parole e l’altra metà ne contiene di più. Forse non sono poi così prolisso come ho sempre pensato.

Domanda (facoltativa): Perché c’è questa grossa differenza fra la media e la mediana del numero di parole che compongono i miei post?

Si noti che se l’output di un comando che stampa qualcosa sul Terminale viene inviato ad un altro comando per un’ulteriore elaborazione, l’output stesso viene risucchiato dal secondo comando e non compare più sullo schermo. ↩︎
Forse sono troppo prolisso, 565 equivalgono a più di una pagina (densa) di un libro di formato medio-grande. ↩︎

Automatizzare il Mac dal Terminale - Sua maestà cron

Sat, 22 Nov 2014 06:00:00 +0000

Nella prima parte di questa serie abbiamo visto come usare il comando at per automatizzare determinate attività sul Mac dal Terminale.

At è utile ogni volta che si vuole eseguire un comando automaticamente una sola volta e in un momento ben definito

Ma at ha anche parecchi limiti e non è adatto a svolgere una attività periodica in modo trasparente, come richiesto da Lucio Bragagnolo nel post da cui ha preso spunto questa serie.

Un demone chiamato cron

Lo strumento più adatto a questo scopo è cron, il cui nome deriva dal greco chronos (tempo). Cron permette di eseguire comandi singoli o interi script, in modo automatico ad una data e ora stabilita, con una precisione che arriva fino al minuto.

Cron è nel gergo di Unix un demone, un comando eseguito automaticamente all’avvio di OS X (o di Linux) che rimane sempre attivo in sottofondo e agisce senza necessità di alcun intervento da parte dell’utente. Cron si attiva ogni minuto ed esegue (quando serve) i comandi contenuti nel file crontab di configurazione.

Ogni utente del Mac ha a disposizione un proprio file crontab, ma esiste anche un file crontab di sistema gestito dall’amministratore, normalmente il primo utente creato al momento della installazione di OS X. I file crontab degli utenti sono contenuti nella directory /usr/lib/cron/tabs/ e si chiamano con il nome account (o nome breve) dell’utente, quello di sistema è /etc/crontab.

Non c’è bisogno di precipitarsi a controllare, nelle nuove versioni di OS X il file /etc/crontab non esiste più, come vedremo la prossima volta.

Dal Terminale, si può visualizzare il contenuto del proprio file crontab con il comando

$ crontab -l

mentre per modificarlo bisogna necessariamente usare

$ crontab -e

e mai un editor di testo (cosa fra l’altro impossibile senza essere amministratore del Mac).

Infine il comando per cancellare il proprio file crontab è

$ crontab -r

Com’è fatto crontab

Ma come è fatto un file crontab? È piuttosto semplice: un file crontab è composto da una o più righe contenenti ciascuna sei campi (colonne) separati da spazi

*	*	*	*	*	comando

Nei primi cinque campi si inseriscono le indicazioni di data ed ora, sostituendole agli asterischi, nell’ultimo campo il comando o il nome dello script da eseguire. Ad esempio,

05	*	*	*	*	echo "Tanti saluti da cron!"

stamperà sul Terminale al quinto minuto di ogni ora la stringa “Tanti saluti da cron!”

In realtà sul Terminale non viene mai stampato nulla. Infatti, analogamente ad at, ogni volta che cron esegue un comando definito nel file crontab di un utente, provvede ad inviargli una email con l’output completo generato dal comando stesso, email che può essere letta dal Terminale con (chi ci avrebbe mai pensato!) mail. La ragione è semplice: cron potrebbe agire dietro le quinte per mesi od anni, effettuando azioni periodiche come il backup in rete di determinate directory o la pulizia del sistema da certi file inutili. È più razionale inviare all’utente interessato una email che gli permetta di controllare, quando ne ha tempo e voglia, che tutto vada bene, invece di disturbarlo periodicamente mentre sta usando il Terminale con l’output delle azioni eseguite da cron.

Per disabilitare l’invio della email mandando l’output del comando eseguito da cron sul file output.txt sul Desktop, si può utilizzare la tecnica standard di Unix di redirezione dell’output

05	*	*	*	*	echo “Tanti saluti da cron!” » ~/Desktop/output.txt

dove il simbolo » aggiunge l’output del comando eseguito da cron alla fine del file output.txt (usando un solo > si sovrascrive ogni volta il contenuto precedente del file).

Data e ora in cron

Rimane da definire come sono codificate le indicazioni della data e dell’ora a cui eseguire cron. Non è molto difficile, almeno se ci si limita ai casi più comuni. La figura seguente mostra il significato dei campi del file crontab.

[caption id=“attachment_1418” align=“aligncenter” width=“500”] Significato dei campi di una riga del file crontab.[/caption]

Quindi per eseguire un comando al quindicesimo minuto di ogni ora bisogna inserire la riga

15	*	*	*	*	comando

mentre per farlo alle 2:00 di ogni lunedì

00	02	*	*	1	comando

Alcuni simboli permettono di specificare dei valori multipli in un campo. Il trattino “-” indica un intervallo, per cui la riga

30 07	*	*	1-5	comando

esegue il comando alle 7:30 dal lunedì al venerdì.

La virgola “,” indica una lista di valori. Quindi

00	08	1,15,30		*	*	comando

esegue il comando specificato il giorno 1, 15 e 30 di ogni mese.

L’asterisco equivale a selezionare tutti i valori consentiti per il campo a cui si riferisce. Una riga come questa

*	*	*	*	*	echo "Tanti saluti da cron!"

istruisce cron ad eseguire il comando echo "Tanti saluti da cron!" una volta al minuto e per sempre!

Infine la barra “/” indica l’incremento del campo numerico, per cui

*	*/3	*	*	*	echo "Tanti saluti da cron!"

equivale a far eseguire il comando ogni 3 ore.

Tutto qui. Ci sono delle finezze ulteriori, ma chi fosse interessato può leggere qualche articolo specifico su cron, come questa pagina su Wikipedia¹, o questo tutorial molto dettagliato.

Cron online

Per i più pigri esiste un servizio online che genera automaticamente la riga del file crontab corrispondente alle date e ore specificate tramite l’interfaccia web. Ma si fa prima ad imparare la sintassi di cron che ad orientarsi nella miriade di opzioni del servizio.

Molto più utile mi sembra il Cron Sandbox, un altro servizio online che consente di verificare che la lista di date e ore generate da una particolare riga del file crontab corrisponda a quanto ci si attende.

Al lavoro

Se vogliamo usare il comando cron per eseguire lo script ~/bin/makeblog e rigenerare automaticamente il blog “Pazzi per la mela” alle 2:00 di ogni notte, dobbiamo inserire nel file crontab la riga

00	02	*	*	*	~/bin/makeblog

e dimenticarci subito dopo della sua stessa esistenza. Cron lavorerà per noi ogni notte, preciso ed instancabile senza infastidirci, a meno che non decidiamo di andare a controllare quello che sta combinando.

E Lux?

Non mi sono dimenticato di Lux. Come già ricordato la volta scorsa, Lux vorrebbe poter scrivere i post del suo blog lasciando al sistema il compito di aggiornare i file html e di trasferirli sul server per la pubblicazione online. E vuole farlo indifferentemente dal Mac o dall’iPad (e perché no, anche dall’iPhone).

Con cron è semplice. Basterà mettere la directory contenente i vari pezzi del blog Octopress dentro la cartella di Dropbox del Mac ² e creare lo script makeblog, configurando cron in modo da eseguirlo automaticamente all’ora desiderata.

Se Lux volesse poter aggiornare il blog quattro volte al giorno (esagerato!) alle ore 0, 6, 12 e 18, dovrebbe inserire in crontab la riga

00	*/6	*	*	*	~/bin/makeblog

oppure qualcosa di più specifico come

30	1,5,12,19	*	*	*	~/bin/makeblog

adattando così gli orari di aggiornamento ai propri ritmi di lavoro.

Ogni volta che Lux scrive un nuovo post con il Mac non dovrà fare altro che salvarlo nella directory giusta della sua installazione di Octopress, né più né meno di come fa già ora. Se invece usa l’iPad o l’iPhone, deve solo ricordarsi di inviare il post a Dropbox, scegliendo la stessa directory che usa sul Mac. Appena l’iPad si troverà connesso ad una rete, invierà il nuovo file a Dropbox, che lo spedirà a sua volta al Mac.

Tutto automatico, senza Apple Script, Azioni Cartelle, e mal di testa.

Conclusioni

Con cron the sky is the limit, o quasi. Io per anni ho fatto fare a cron il backup completo del contenuto di un sito web professionale, contenente centinaia di documenti e di programmi da distribuire agli utenti registrati, e del relativo database MySQL. Una volta scritto lo script che eseguiva il backup vero e proprio (questa è stata la cosa veramente complicata, visto che volevo mantenere backup multipli orari, giornalieri e mensili), ho lasciato fare a cron e… me ne sono letteralmente dimenticato.

Ma non finisce qui. La prossima volta mi toccherà parlare di launchd. Come potrei evitarlo, visto che questo blog è focalizzato (più o meno) sul Mac?

Poteva mai mancare un riferimento ad una pagina di Wikipedia? MA non è certo colpa mia se Wikipedia è una delle cose migliori del web e che tante pagine sono fatte veramente bene. ↩︎
Si potrebbe anche usare un collegamento simbolico o un altro servizio di condivisione dei file, ma non generalizziamo troppo. ↩︎

Automatizzare il Mac dal Terminale - Il comando at

Thu, 06 Nov 2014 06:05:00 +0000

Qualche giorno fa Lucio “Lux” Bragagnolo ha pubblicato sul suo interessantissimo blog (da seguire assolutamente ogni giorno!), un post in cui poneva una domanda molto stimolante. Lascio a lui la parola per descrivere il problema:

Octopress – il motore di questo blog – si basa su una cartella che risiede nel Mac. La cartella contiene sottocartelle varie che ospitano i pezzi del blog. Pubblicare questo articolo significa creare un file e metterlo nella giusta cartella, per poi dare un comando di Terminale che genera una edizione aggiornata del blog e un altro comando di Terminale che deposita una copia dell’edizione dentro il server di pubblicazione.
Spesso mi trovo a scrivere pezzi per il blog su iPad, lontano da Mac. Facciamo finta che il Mac rimanga irraggiungibile fisicamente per tutta la giornata. Qual è la strategia che richiede meno lavoro in assoluto per pubblicare il pezzo?

Detto in modo più generale, la domanda di Lux è:

quali strumenti possono essere usati sul Mac per automatizzare determinate attività nel modo più semplice e veloce possibile?

Nella discussione che è seguita sul blog il mio incontrollabile alter ego virtuale ha proposto velocemente due o tre possibili soluzioni, promettendo anche di approfondirle appena possibile.

Credo che questo sia lo spazio migliore per farlo, tornando finalmente a discutere di argomenti connessi alla programmazione e alla amministrazione del Mac, dopo parecchio (troppo!) tempo dedicato a divagazioni più o meno lontane dal target principale del blog.

Introduzione

Sul Mac sono disponibili diversi strumenti che permettono di automatizzare le operazioni effettuate sul sistema. Mi concentrerò qui sui comandi di derivazione Unix presenti di default in OS X, perché sono strumenti ben testati ed affidabili e sono utilizzabili anche su piattaforme diverse dal Mac.

Avrei voluto concentrare la discussione in un unico post, ma mi sono accorto che raggiunto una lunghezza eccessiva e difficile da digerire in una sola volta.

Ho deciso quindi di dividere la trattazione in più parti distinte. In questa prima parte mostrerò l’uso di at, il comando più semplice disponibile su OS X per questo scopo.

Nei prossimi post mostrerò l’utilizzo di strumenti più avanzati come cron e launchd. Cercherò poi di descrivere ulteriori prodotti di terze parti ed eventualmente anche una soluzione basata su Automator (ammesso che questa sia in grado di fare al meglio quanto richiesto, cosa di cui non sono troppo sicuro in questo momento).

Per evitare di essere troppo vago cercherò di circoscrivere il problema, basandomi strettamente su quanto richiesto da Lux, ma provando anche a rendere facile l’estensione di quanto descritto a casi più generali.

Pazzi per la mela

Supponiamo di voler automatizzare la pubblicazioni dei nuovi post sul blog “Pazzi per la mela”, raggiungibile all’indirizzo IP http://pazziperlamela.it (inutile cliccare sul link, il blog non esiste).

Pazzi per la mela utilizza Octopress per convertire i file di testo che costituiscono ciascun post in pagine html statiche, che devono essere poi copiate sul server remoto che gestisce il sito web del blog.

Sul Mac, tutti i testi dei post e i file di configurazione del blog si trovano nella cartella ~/Documenti/pazziperlamela/, dove ~ indica per convenzione la cartella Inizio (o home) dell’utente del Mac, identificata nel Finder dall’icona di una casetta.

Ogni volta che si aggiungono nuovi post o si modificano quelli già esistenti, bisogna rigenerare le pagine html, eseguendo dal Terminale i comandi

$ cd Documenti/pazziperlamela/

per posizionarsi all’interno della cartella del blog, e poi

$ rake generate

per ricreare sul Mac le pagine html che costituiscono il sito web del blog. Un ulteriore comando

$ rake deploy

sincronizza le pagine html modificate con il server remoto tramite rsync, probabilmente il migliore strumento di sincronizzazione bidirezionale fra un server remoto e il sistema locale.

Mettiamo insieme questi comandi creando un semplice script di shell,

	#!/bin/bash
	cd ~/Documenti/pazziperlamela/
	rake generate
	rake deploy

salviamolo in ~/bin con il nome makeblog e rendiamolo eseguibile (le istruzioni dettagliate si trovano in Script di shell in OS X).

E arriviamo finalmente alla parte centrale del post.

Supponiamo di voler rigenerare automaticamente il blog “Pazzi per la mela” una volta al giorno, magari alle 2:00 di notte per evitare che troppi lettori siano collegati nel momento in cui vengono modificate le pagine del blog.

Vediamo come farlo, usando il comando più semplice presente sul Mac

Un comando semplice semplice

Lo strumento più semplice che possiamo usare sul Mac per automatizzare determinate operazioni è at, che esegue uno o più comandi alla data e ora specificata. La sintassi di at adatta a questo scopo è

$ at -f script -m ora data

dove script è il nome dello script di shell contenente i comandi da eseguire, mentre ora e data possono essere specificate sia in modo assoluto, ad esempio “02:00” oppure “02:00 Nov 06” (senza virgolette), che in modo relativo, “now + 1 minute”, “tomorrow”.

In alternativa si può specificare la data e l’ora in formato POSIX,

$ at -f comando -m -t YYYYMMDDhhmm

cioè scrivendola al contrario di come siamo abituati, iniziando dall’anno e finendo con i minuti. Qui YYYY indica l’anno, MM il numero del mese, DD il giorno, infine hh e mm l’ora e i minuti. Tutti gli elementi della data vanno inseriti usando due (o quattro) cifre e facendoli precedere eventualmente da uno zero. In questo formato, il 6 Novembre alle ore 2:00 diventa “201411060200”

Per motivi che mi sfuggono, il comando at è disabilitato di default in OS X. Per attivarlo bisogna eseguire da Terminale

$ sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.atrun.plist

dopo di che il comando at rimarrà disponibile anche riavviando il Mac.

Si può ora utilizzare at per eseguire automaticamente lo script di shell makeblog all’ora desiderata, scrivendo nel Terminale

$ at -f ~/bin/makeblog -m 02:00 tomorrow

Il Terminale (o meglio bash) ci risponderà con l’indicazione della data e dell’ora completa alla quale verrà eseguito lo script. Dopo averlo completato, inoltre, bash sarà tanto gentile da inviarci una email con l’output completo prodotto dallo script.

A meno di non configurare opportunamente il servizio di posta elettronica interno di OS X (una cosa che va ben oltre gli scopi di questo post), questa email però non riuscirà a raggiungere la nostra abituale casella di posta elettronica. Potrà però essere letta dal Terminale con il comando (poteva essere diversamente?) mail.

Troppo semplice per essere utile?

Purtroppo il comando at non è adatto a soddisfare quanto richiesto da Lux.

Infatti, dopo aver finito di scrivere un nuovo post, Lux dovrebbe comunque lanciare il Terminale e configurare at in modo da fargli eseguire lo script makeblog alle due della notte successiva. Se invece sta usando l’iPad, dovrebbe collegarsi tramite ssh al Mac e fare la stessa cosa da remoto.

Ma, avendo accesso al Terminale, e indipendentemente dal fatto che avvenga in locale o in remoto, è molto più semplice eseguire direttamente lo script makeblog, senza complicarsi ulteriormente la vita.

Quindi at non serve a niente?

Certo che at serve (altrimenti che senso avrebbe avuto scrivere questo post?). Ma serve nei casi in cui si vuole eseguire una determinata attività sul Mac automaticamente e una volta sola, mantenendo il pieno controllo del momento esatto in cui viene fatta partire.

Se invece vogliamo eseguire un’attività periodicamente e quasi dimenticandocene, at non serve e bisogna usare per forza di cose degli strumenti più avanzati.

Il mio incontro con at

Sono sicuro di non aver mai usato finora at su OS X, ma questo comando mi è stato utilissimo diversi anni fa, quando ho avuto accesso a delle favolose workstation Sun.

All’epoca dovevo eseguire delle simulazioni che duravano parecchie ore. Un semplice PC era improponibile: non solo perché era troppo lento, ma anche perché c’era sempre qualcuno che, zelante, lo spegneva la sera passandoci davanti (nonostante tutti i cartelli di avviso che potevo mettere davanti al monitor).

Un amico grande esperto di Unix (ho imparato i fondamenti da lui!) mi permise allora di usare le workstation Sun del laboratorio di elaborazione video che gestiva.

Per ottimizzare l’uso delle macchine e non dare fastidio agli altri utenti, dovevo però lanciare le simulazioni di notte, quando i sistemi erano quasi inattivi. Passavo poi gran parte della giornata successiva a controllare e ad elaborare i dati prodotti durante la notte e a preparare i file di configurazione per le successive elaborazioni notturne.

Questo ciclo, preparazione-calcolo-elaborazione, mi impediva di usare cron (un comando che vedremo la prossima volta), che avrebbe eseguito ciecamente le simulazioni ogni notte al momento stabilito, anche nei week-end o nei giorni in cui per qualche motivo non ero riuscito ad elaborare i dati.

Invece at era perfetto per questo scopo. Una volta completata la scrittura dei nuovi file di configurazione, li trasferivo tramite rete locale sulle Sun e configuravo at in modo da eseguire un nuovo ciclo di simulazioni la notte successiva. Semplice e veloce.

Accessori ma sempre utili

Fra i comandi di supporto di at, sono particolarmente utili atq, che permette di elencare i comandi at in attesa di essere eseguiti, e atrm seguito da un numero intero, che cancella il comando at in coda identificato dal numero intero associato. Ad esempio

$ atq
35	Thu Nov  6 02:00:00 2014
36	Thu Nov  6 06:00:00 2014
37	Sat Nov 15T12:15:00:00 2014

$ atrm 36
$ atq
35	Thu Nov  6 02:00:00 2014
37	Sat Nov 15T12:15:00:00 2014

Se si vuole disabilitare di nuovo at, bisogna eseguire da Terminale

$ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.atrun.plist

Conclusioni

In questo lungo post abbiamo visto il più semplice comando che può essere utilizzato per automatizzare determinate attività sul Mac. Nel prossimo post affronteremo cron, il re indiscusso degli strumenti adatti a questo scopo.

Script di shell in OS X

Thu, 06 Nov 2014 06:00:00 +0000

Nei sistemi operativi basati su Unix la shell è una applicazione che permette di eseguire i comandi del sistema tramite una interfaccia testuale a linea di comando.

La shell più popolare oggi è bash, acronimo di “Bourne-Again Shell”, un gioco di parole fra Stephen Bourne, l’autore della shell sh da cui deriva bash, e il termine “born” (nato). Bash significa quindi sia “la nuova shell di Bourne” che “la shell rinata”.

Bash è la shell ufficiale del progetto GNU, ed è da tempo la shell di default in praticamente tutte le distribuzioni di Linux oltre che in OS X. Per accedere a bash in OS X si utilizza il Terminale, una applicazione di cui si è già parlato più volte in questo blog. Il Terminale si trova in Applicazioni > Utility.

Bash permette di eseguire i comandi del sistema operativa sia in modo interattivo, scrivendoli uno alla volta sulla linea di comando, che tramite uno script di shell (shell script), un vero e proprio programma all’interno del quale è possibile usare variabili, strutture di controllo e funzioni, esattamente come in tutti i linguaggi di programmazione.

Uno script di shell ben fatto può diventare quindi un vero e proprio comando specializzato, eseguibile dalla linea di comando e praticamente indistinguibile dai comandi intrinseci del sistema.

Ma come si crea uno script di shell? Basta seguire alcune semplici regole.

Innanzi tutto lo script va scritto usando un editor, mai un wordprocessor come Word o Pages. Lo script deve infatti essere un semplice file di testo e non deve contenere i codici di formattazione o i caratteri speciali inseriti normalmente dai programmi di videoscrittura.
Come editor si può usare TextEdit, preinstallato in tutte le versioni di OS X, ma vanno ancora meglio programmi gratuiti, come TextWrangler, TextMate 2.0, Brackets, Atom, o commerciali, come il mostro sacro BBEdit e Sublime Text. Tutti questi editor hanno il grande vantaggio rispetto al semplice TextEdit di evidenziare i comandi di bash e di supportare l’autocompletamento delle parole chiave riconosciute dall’editor.
Volendo si possono usare anche macvim o emacs, ma chi è in grado di usarli non ha bisogno di sicuro di leggere queste note.
Per permettere al sistema operativo di identificare il file come uno script per la shell bash, gli script devono iniziare con la riga

#!/bin/bash

È buona regola salvare tutti i propri script in una cartella (directory) comune, in modo che siano facilmente rintracciabili dal sistema operativo (ma dopo un po’ di tempo anche da noi stessi!)
Per uniformarci alle convenzioni di Unix, creiamo una directory bin nella nostra cartella Inizio (o directory home), dove salveremo tutti gli script.¹ Lanciamo il Terminale ed eseguiamo i comandi

$ cd ~
$ mkdir bin

dove il simbolo ~ indica per convenzione la cartella home dell’utente.

Lo script deve essere reso eseguibile direttamente con il comando

$ chmod u+x scriptname

Aiutiamo il sistema operativo a trovare facilmente i nostri script aggiungendo la directory bin appena creata alla variabile di ambiente PATH, che definisce le directory dove il sistema operativo va a cercare i comandi del sistema. Torniamo al Terminale ed eseguiamo in sequenza i comandi

cp -p .bashrc .bashrc.ORIGINAL
echo “export PATH=~/bin:$PATH” » .bashrc

Il primo comando duplica il file .bashrc originale, mentre il secondo aggiunge la riga contenuta fra virgolette alla fine del file .bashrc. Bisogna stare molto attenti ad usare due simboli di maggiore nel secondo comando altrimenti si rischia di sovrascrivere .bashrc con effetti potenzialmente disastrosi (questo è il motivo per cui è bene prima duplicare il file .bashrc originale).

Una volta chiuso e rilanciato il Terminale, la cartella ~/bin sarà aggiunta alla lista delle directory contenenti i comandi eseguiti da bash.

Bisogna notare che la creazione della directory ~/bin e la sua aggiunta al PATH del sistema vanno eseguiti una sola volta per ogni utente del Mac.

Vorrei infine sfatare una credenza ormai obsoleta: non è assolutamente necessario che il nome dello script termini con l’estensione .sh. È una vecchia abitudine che ha l’unico vantaggio di rendere immediatamente riconoscibile uno script salvato in una directory qualunque del sistema. Ma è una pratica inutile se si segue il consiglio di tenere tutti gli script di shell in una directory predefinita come ~/bin.

La cartella Inizio in OS X è quella identificata dall’icona di una casetta. ↩︎

Aggiornato bash... finalmente!

Wed, 01 Oct 2014 06:00:00 +0000

Apple ha finalmente rilasciato l’aggiornamento per bash, un componente fondamentale dei sistemi operativi derivati da Unix, fra cui c’è lo stesso OS X.

La settimana scorsa si è sparsa la notizia della scoperta di questa gravissima falla di sicurezza nella shell bash, il componente software che interpreta ed esegue i comandi del Terminale, diventata ormai da anni la shell di default di OS X e di quasi tutte le distribuzioni di Linux.

Per scoprire se il proprio sistema è affetto dalla falla (e se siete su OS X lo è di sicuro), basta lanciare il Terminale ed eseguire questo comando,

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Se vengono stampate le due righe,

vulnerable
this is a test

la shell bash è affetto dalla vulnerabilità.

Scaricando l’aggiornamento di bash dal sito di Apple (quello di Mavericks è qui, ma ci sono anche le versioni per Mountain Lion e per Lion) ed installandolo sul proprio sistema, ci vuole un minuto in tutto, si dovrebbe riuscire a appare questa falla.

Dopo l’installazione, eseguendo di nuovo dal Terminale il comando di sopra si ottiene soltanto

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test

È un bene che Apple abbia rilasciato l’aggiornamento. Ma bisogna anche aggiungere: finalmente.

Avrebbe dovuto essere più veloce, non trincerarsi dietro la pretesa assurda che la vulnerabilità colpisce solo pochi utenti. Perché non è vero. Anche chi non sa nemmeno cosa sia il terminale può benissimo usare programmi che usano bash dietro le quinte, ritrovandosi a rischio senza nemmeno sospettarlo.

I limiti di Wordpress.com: generatori di siti web statici

Sat, 09 Aug 2014 06:00:00 +0000

Come ho già scritto qualche giorno fa, ci sono letteralmente decine di generatori di siti web statici, quasi quante sono le distribuzioni di Linux. Io nei miei bookmark ne ho una trentina.

Come orientarsi in questa moltitudine?

Per le distribuzioni di Linux esiste Distrowatch, un sito popolarissimo che cerca di classificarle tutte. Analogamente, esistono almeno due siti che cercano di elencare tutti i generatori di siti web statici: StaticGen e Static Site Generators. L’approccio dei due è totalmente diverso anche se le informazioni riportate sono praticamente le stesse.

Il primo ordina di default i generatori di siti statici in base alla popolarità, ma si possono applicare vari filtri basati sul linguaggio di programmazione, la valutazione degli utenti e persino gli issue, i problemi riscontrati dagli utenti.

L’altro è apparentemente una tabella ordinata alfabeticamente (in questo momento elenca ben 289 sistemi diversi!), ma cliccando sulle intestazioni si può ordinarla in base al linguaggio di programmazione, alla valutazione degli utenti o alla data in cui il sistema è stato aggiornato per l’ultima volta. Quest’ultima è una informazione utilissima, se un sistema non è aggiornato da anni non vale la pena perderci tempo.

Provando ad applicare un po’ di filtri si copre che esiste perfino un generatore, StatiKiss Framework, basato su Bash, ma il sito web ufficiale contenente la documentazione non risponde. In realtà esisteva un’altro sistema interessante basato su Bash, NanoBlogger, il cui sviluppo è stato però sospeso all’inizio del 2013. Evidentemente Bash non va bene per sviluppare siti web.

Si può trovare anche Zodiac, un generatore di siti statici scritto in AWK, un linguaggio perfetto per la manipolazione di file di testo, sviluppato fra gli altri da Brian Kernighan, uno dei padri di Unix e del linguaggio C. A leggere il README Zodiac sembra semplice da usare, supporta markdown e la struttura delle directory in cui sono organizzati i documenti utilizzati per generare il sito è ragionevole. Ma purtroppo la popolarità di Zodiac è scarsa, scarsissima. Si potrebbe di certo usare per un progetto personale e soprattutto per imparare, ma è impensabile volere sostituire Wordpress con qualcosa come Zodiac. A chi rivolgersi, dove cercare aiuto e documentazione se si volesse fare qualcosa di non previsto dal programmatore, ad esempio gestire un sistema di commenti?

Fra i generatori di siti web statici ci sono persino due sistemi scritti in .NET. Ma vogliamo farci veramente del male?

Ma lasciamo perdere le curiosità. Quali sono invece i top player? Quali sono i sistemi più popolari, più diffusi e, si spera, più affidabili? Facile, il primo in assoluto è Jekyll, un generatore sviluppato in Ruby, un linguaggio di programmazione che è più o meno la risposta giapponese a Python, molto diffuso per sviluppare applicazioni web. Seguono Octopress (un derivato semplificato di Jekyll, il cui sviluppo però è fermo dal 2011), Pelican in Python, Middleman ancora in Ruby e Hexo in JavaScript.

Ci sono comunque altri generatori interessanti, alcuni con nomi veramente curiosi, Ruhoh, Hugo, Pico, Calepin, DropPages, Pancake, Anchor CMS, Hyde, Sculpin, HTMLy,Dropplets, Chronicle. Esiste persino il venerabile (ha quasi 10 anni!) Dir2web, l’unico prodotto italiano che conosca.

Non mancato anche i prodotti a pagamento come Kirby e Statamic. O come Cactus, che è pure specifico per il solo Mac.

Per questi ultimi no grazie, il web nasce e deve rimanere multipiattaforma, sistemi sviluppati per uno specifico sistema operativo non mi vanno bene a priori. E trovo pure irragionevole cercare di vendere questi prodotti: se devo pagare per Statamic, quanto dovrei dare agli sviluppatori di Apache? Sei uno sviluppatore e vuoi guadagnarci? Distribuisci gratis il prodotto, dimostra nei fatti che è buono, fai in modo che diventi il più popolare possibile e poi vendi il supporto. Cercare di vendere software come questi, che subiscono la concorrenza di sistemi equivalenti, gratuiti e di qualità analoga se non migliore, è veramente sciocco.

Amministratore pro tempore

Sat, 05 Jul 2014 06:00:00 +0000

Qual’è la differenza fra semplice utente ed amministratore nei sistemi basati su Unix, come Linux o OS X? Non ho mai trovato una sintesi così perfetta come quella proposta dal geniale autore di xkcd.

Il comando di terminale sudo permette di diventare – anche se solo temporaneamente – l’amministratore (root) onnipotente di un sistema Unix in grado persino, e senza ripensamenti, di cancellare completamente il contenuto del disco rigido.

Un comando da usare con molta attenzione.

Ma, guardando le cose al contrario, proprio la differenza rigida fra utente ed amministratore è uno dei fattori che rendono i sistemi basati su Unix molto più sicuri di Windows, in cui la differenza di ruoli è molto più sfumata e quasi (vedi XP) assente.

Consentendo così a virus e malware vario di scorrazzare liberamente nei meandri del disco rigido.

Sandboxing in iOS: usciamo dal recinto

Thu, 22 May 2014 06:00:00 +0000

Esiste una soluzione semplice al problema del sandboxing delle applicazioni per iOS, che non impatti sulla sicurezza del sistema ma che allo stesso tempo permetta a più applicazioni di aprire e modificare un dato documento, evitando inutili duplicazioni e, quel che è peggio, di dover tenere traccia delle modifiche effettuate da ciascuna applicazione?

Soluzioni fattibili – più o meno semplici e più o meno affidabili o sicure – ce ne sono bizzeffe. Qui ne propongo una anch’io, che ha la caratteristica di sfruttare solo gli strumenti già esistenti in Unix e nei sistemi operativi derivati, fra cui anche iOS.

Sia chiaro che non voglio sostituirmi agli ingegneri e ai programmatori della Apple, che conoscono molto meglio di me il sistema su cui lavorano. Quello che voglio è solo dare un contributo di principio e di dimostrarne la fattibilità pratica.

L’eventuale (eventuale, non dimentichiamolo!) implementazione finale sarà di certo molto più brillante ed efficiente di questa.

Per evitare ambiguità userò nel seguito un linguaggio standard, evitando le definizioni tipiche del mondo Apple: directory al posto di cartella, file invece di documento, soft-link invece che link simbolico, e ogni volta che mi riferirò a Unix intenderò in effetti tutti sistemi operativi che derivano dalla base di Unix, come Linux, i vari BSD e ovviamente OS X e iOS.

Tutto è un file

Prima di proseguire il discorso bisogna ricordare alcuni concetti fondamentali sui file in Unix.

Tutto è un file in Unix. Questo è uno dei primi mantra che si imparano quando ci si accosta a questo sistema operativo. Una directory è un file, persino la comunicazione fra i vari processi o con i dispositivi hardware avviene tramite file.

Ma com’è fatto un file in Unix?

Un file è composto da tre parti diverse e ben distinte fra loro: il nome del file, il contenuto del file e i metadati, una serie di informazioni accessorie sul file che esamineremo meglio dopo.

Il contenuto del file è salvato in uno o più settori del disco rigido, i metadati sono memorizzati negli inode, delle strutture dati create al momento della formattazione del disco rigido e numerate univocamente, e infine il nome del file si trova nella directory (anch’essa un file!) che lo contiene, in una tabella che associa ad ogni nome di file della directory il numero dell’inode in cui sono salvati i metadati corrispondenti.

Ogni inode è una struttura dati (una specie di tabella un po’ più complicata) contenente, fra l’altro, la dimensione del file, i permessi di accesso e di modifica, la data e l’ora in cui in cui il file è stato creato, modificato o semplicemente letto, i puntatori ai settori fisici del disco rigido in cui è salvato il contenuto vero e proprio del file ed infine, quello che ci interessa di più, un numero intero che serve a contare il numero di copie (virtuali) del file stesso create tramite i cosiddetti hard-link.

Se a questo punto non vi gira già la testa potete continuare a leggere…

Hard-link e soft-link

In Unix è possibile riferirsi in modo indiretto ad un file mediante due diversi tipi di file: gli hard-link e i soft-link.

Dei soft-link ho già scritto in questo blog. Aggiungo che il soft-link crea un riferimento al nome del file, e si usa principalmente per dare un nome diverso ad un file.

Un hard-link crea invece un riferimento al numero dell’inode che contiene i metadati del file di partenza. Il file creato tramite un hard-link appare quindi a tutti gli effetti una copia del file originale, anche se non è esattamente così. Quando si copia un file, il nuovo file ha nome ed inode diverso ed anche il contenuto del file originale viene copiato in un’altra area del disco rigido. Creando un hard-link, il nuovo file avrà solo un nome diverso ma continuerà a riferirsi allo stesso inode, e quindi allo stesso contenuto, sul disco rigido.

Qualunque operazione effettuata sull’hard-link – modifica del contenuto del file, dei permessi, dell’ora di accesso al file – appare come se fosse effettuata anche sul file originale e su tutti i suoi hard-link: un hard-link è a tutti gli effetti lo stesso file, ma con un nome diverso.

A differenza del soft-link, però, che perde il riferimento al file originale e non serve più a nulla se quest’ultimo viene cancellato dal disco rigido, un hard-link continua ad essere valido anche se si cancella il file a cui fa riferimento.

Un hard-link ad un file viene creato con il comando,

$ ln file hfile

dove file è il file originale e hfile è l’hard-link (ovviamente i due file possono anche essere in directory diverse). Per creare il soft-link sfile basta aggiungere l’opzione -s al comando precedente.

$ ln -s file sfile

Ogni volta che si crea un nuovo file, il contatore delle copie del file contenuto nell’inode viene settato ad 1. Aggiungendo un hard-link a quel file, il sistema operativo incrementa di 1 il contatore, cancellando l’hard-link il contatore viene decrementato di 1. In effetti, tramite il contatore, il sistema operativo può sapere quanti hard-link sono presenti sul disco rigido oltre al file originale.

Arrivati a questo punto, chi vuole può saltare la sezione seguente e andare direttamente all’ultima parte del post.

Un po’ di pratica…

Usiamo ora il Terminale di OS X per mettere in pratica quanto abbiamo appena visto.

Il comando touch crea un nuovo file, a cui aggiungiamo una riga di testo qualunque con echo (un metodo quasi da hacker, si potrebbe benissimo farlo con un editor di testo).

$ touch file.txt
$ echo "Ho appena creato un file di testo." >> file.txt

Tramite ls -l mostriamo il file appena creato e una parte dei metadati associati.

$ ls -l
-rw-r--r--  1 maggi  staff  35 May 19T22:53:00 file.txt

Ci interessano qui due numeri in particolare. Quello contenuto nella seconda colonna è il contatore delle copie del file e vale 1 poiché il file è stato appena creato. Il numero nella quinta colonna, 35, è invece la dimensione in byte del file, uguale al numero di lettere che compongono il testo aggiunto con echo più il carattere (invisibile) di a capo.

Creiamo ora un hard-link e un soft-link che puntano entrambi al file di testo file.txt.

$ ln file.txt hfile.txt
$ ln -s file.txt sfile.doc

Eseguendo di nuovo ls -l,

$ ls -l
-rw-r--r--  2 maggi  staff  35 May 19T22:53:00 file.txt
-rw-r--r--  2 maggi  staff  35 May 19T22:53:00 hfile.txt
lrwxr-xr-x  1 maggi  staff   8 May 19T22:54:00 sfile.doc -> file.txt

si notano alcune cose fondamentali: (1) l’hard-link appare come un file del tutto identico al file originale, dimensioni, permessi, data di creazione (o di accesso), (2) il soft-link ha invece date, dimensioni e permessi differenti, (3) ed è anche mostrato in modo diverso nel Terminale, con una freccia che punta la file originale e con una l al posto del - nel primo carattere della riga, (4) avendo creato un hard-link il contatore delle copie del file contenuto nell’inode viene incrementato di 1 e, poiché i due file si riferiscono allo stesso inode (e quindi allo stesso contatore), il valore del contatore è uguale per file.txt e hfile.txt.

L’opzione -i del comando ls permette di stampare il numero dell’inode associato ad ogni file. Nel nostro esempio, si vede chiaramente che l’inode del file originale e quello dell’hard-link associato sono uguali.

$ ls -li
219115720 -rw-r--r--  2 maggi  staff  35 May 19T22:53:00 file.txt
219115720 -rw-r--r--  2 maggi  staff  35 May 19T22:53:00 hfile.txt
219115795 lrwxr-xr-x  1 maggi  staff   8 May 19T22:54:00 sfile.doc -> file.txt

Creando un hard-link si incrementa il contatore del numero di file contenuto nell’inode,

$ ln file.txt h2file.dat
$
$ ls -li
219115720 -rw-r--r--  3 maggi  staff  35 May 19T22:53:00 file.txt
219115720 -rw-r--r--  3 maggi  staff  35 May 19T22:53:00 h2file.dat
219115720 -rw-r--r--  3 maggi  staff  35 May 19T22:53:00 hfile.txt
219115795 lrwxr-xr-x  1 maggi  staff   8 May 19T22:54:00 sfile.doc -> file.txt

mentre se si cancella un hard-link il contatore viene decrementato di 1.

$ rm hfile.txt
$
$ ls -li
219115720 -rw-r--r--  2 maggi  staff  35 May 19T22:53:00 file.txt
219115720 -rw-r--r--  2 maggi  staff  35 May 19T22:53:00 h2file.dat
219115795 lrwxr-xr-x  1 maggi  staff   8 May 19T22:54:00 sfile.doc -> file.txt

Usciamo dal recinto

Per permettere a più applicazioni iOS di accedere alla stesso file, evitando allo stesso tempo la moltiplicazione dei file in diverso stato di “lavorazione”, serve un meccanismo che permetta di inserire tutti i documenti in un’area comune, riuscendo però a fare in modo che ciascuna applicazione continui ad accedere solo ai documenti che è autorizzata a gestire, cioè quelli contenuti nel suo sandbox.

Ricordo che il sandbox è un meccanismo che limita l’accesso di una applicazione ai file, alle preferenze, alle risorse di rete, all’hardware e così via, incapsulando ciascuna applicazione con i suoi documenti in una directory protetta.

Proprio gli hard-link possono essere sfruttati per implementare questo meccanismo.

In iOS (ma anche in OS X) le applicazioni ci appaiono come delle semplici icone. In realtà ogni applicazione è costituita da una directory che contiene al suo interno tutto quello che le serve per funzionare: l’eseguibile, le librerie, i file di supporto e di configurazione, le immagini e le icone e i documenti creati con l’applicazione stessa.

Immaginiamo ora di avere due applicazioni installate nel nostro dispositivo iOS. Se guardiamo al loro interno, osserveremo una struttura delle directory simile a questa.

$ tree
.
├── appA
│   ├── appA.app
│   ├── documents
│   ├── library
│   └── tmp
└── appB
	├── appB.app
	├── documents
	├── library
	└── tmp

La directory con estensione .app contiene il file eseguibile dell’applicazione, le altre non necessitano di spiegazioni. Si noti che il comando tree usato per mostrare la struttura delle directory delle due applicazioni non esiste di default in OS X, ma può essere installato sul Mac tramite Homebrew.

Aggiungiamo qualche file in ciascuna delle due applicazioni.

$ tree
.
├── appA
│   ├── appA.app
│   ├── documents
│   │   ├── file-AB.txt
│   │   └── file_A1.pdf
│   ├── library
│   └── tmp
└── appB
	├── appB.app
	├── documents
	│   ├── file-AB.txt
	│   ├── file_B1.pdf
	│   └── file_B2.txt
	├── library
	└── tmp

Come abbiamo già visto, ognuna delle due applicazioni può gestire solo i documenti contenuti al suo interno. Le due applicazioni possono al massimo scambiarsi i file contenuti nella directory documents di ciascuna, copiandoli integralmente da una applicazione all’altra. Nell’esempio precedente il file comune è file-AB.txt.

Una volta completata la copia, le modifiche effettuata da appA su file-AB.txt sono del tutto indipendenti da quelle effettuate da appB sul file omonimo contenuto nel suo sandbox. L’unico modo per mantenere il file sincronizzato fra le due applicazioni è quello di copiarlo dopo ogni modifica dal sandbox di una applicazione a quello dell’altra. Una cosa poco pratica e facilmente soggetta ad errori.

Immaginiamo invece di creare una directory pool, esterna alle due applicazioni, che agisca come spazio comune per tutti i documenti.

$ tree
.
├── appA
│   ├── appA.app
│   ├── documents
│   ├── library
│   └── tmp
├── appB
│   ├── appB.app
│   ├── documents
│   ├── library
│   └── tmp
└── pool
	├── file-AB.txt
	├── file_A1.pdf
	├── file_B1.pdf
	└── file_B2.txt

Ma le applicazioni presuppongono che i documenti siano all’interno del loro sandbox. È possibile fare in modo che le applicazioni riescano comunque ad accedere ai file in pool?

Facile: basta creare degli hard-link che dalla directory documents di ogni applicazione puntino ai file contenuti in pool. Ricreando tramite hard-link il contenuto originale delle directory documents delle due applicazioni si ottiene,

$ tree
.
├── appA
│   ├── appA.app
│   ├── documents
│   │   ├── hfile-AB.txt
│   │   └── hfile_A1.pdf
│   ├── library
│   └── tmp
├── appB
│   ├── appB.app
│   ├── documents
│   │   ├── hfile-AB.txt
│   │   ├── hfile_B1.pdf
│   │   └── hfile_B2.txt
│   ├── library
│   └── tmp
└── pool
	├── file-AB.txt
	├── file_A1.pdf
	├── file_B1.pdf
	└── file_B2.txt

dove, per chiarezza, gli hard-link sono indicati dal prefisso h aggiunto al nome del file.

Il vantaggio principale di questo meccanismo è che se una delle due applicazioni modifica il file hfile-AB.txt contenuto nel suo sandbox (quindi all’interno della sua directory documents), tutte le modifiche fatte dall’applicazione valgono anche per il file originale e per l’hard-link corrispondente contenuto nel sandbox dell’altra applicazione.

Ovviamente quanto detto finora è facilmente generalizzabile a un numero qualunque di applicazioni e di file.

Un altro vantaggio, che dovrebbe essere evidente da quanto detto in questo lunghissimo articolo, è che un hard-link non occupa altro spazio sul disco rispetto a quello occupato dal file originale. Si evita quindi di sprecare inutilmente spazio sul disco dell’iPhone e dell’iPad a causa della duplicazione dei file trasferiti da una applicazione all’altra. E si sa bene che lo spazio su qualunque computer non basta mai.

Ma come fa l’applicazione a inserire un nuovo documento in pool e a creare l’hard-link corrispondente nella sua directory documents? La risposta è semplice: non serve che lo faccia l’applicazione, il meccanismo immaginato qui può essere gestito dal solo sistema operativo. In altre parole, il meccanismo può essere implementato a livello del sistema operativo in modo del tutto trasparente alle applicazioni, che quindi non hanno bisogno essere modificate per funzionare correttamente.

Quando l’applicazione appA apre per la prima volta file-AB.txt, è il sistema operativo che si occupa di inserire il file in pool e di creare l’hard-link nel sandbox di appA. Il tutto è assolutamente trasparente ad appA, che non si accorge nemmeno di quello che è successo dietro le quinte. Se poi a un certo punto ho bisogno di inviare file-AB.txt da appA ad appB, posso limitarmi a cliccare come succede già oggi sull’icona apposita in appA, e sarà poi il sistema operativo ad intercettare la richiesta di copia del file, creando in realtà un nuovo hard-link in appB che punta anch’esso a file-AB.txt.

Infine, se si disinstalla una applicazione, supponiamo appB, anche i suoi documenti vengono cancellati dal disco, compreso hfile-AB.txt condiviso con appA. Ma il documento originale e l’hard-link in appA rimangono sul disco e non vengono persi inavvertitamente. Solo se si cancella anche appA, il sistema operativo attraverso il contatore nell’inode, si accorge che non ci sono più hard-link a file-AB.txt contenuto in pool e può decidere di cancellare anche il file originale, magari chiedendo conferma esplicita al proprietario o dopo aver effettuato un backup di sicurezza sul Mac.

E anche la cancellazione dei file può essere affidata senza problemi al sistema operativo e non deve essere gestita dalla singola applicazione.

Detto questo, aspettiamo pazientemente la WWDC 2014 per sapere che diavolerie inventerà veramente la Apple, in questo settore. Ammesso, naturalmente, che ne inventi qualcuna.

Homebrew: i comandi avanzati

Wed, 14 May 2014 06:00:00 +0000

Dopo aver esaminato i comandi principali per usare Homebrew, è ora di trattare i principali comandi avanzati. Prima però un breve ripasso del post precedente.

Aggiornamento

Come abbiamo visto, per aggiornare Homebrew si usa la terna di comandi

$ brew update

che aggiorna il sistema Homebrew vero e proprio,

$ brew outdated

che elenca le nuove versioni disponibili dei package già installati nel sistema (Figura 1),

Figura 1. Elenco dei nuovi package disponibili.

e infine

$ brew upgrade

che aggiorna i package installati alla versione più recente presente in Homebrew (Figura 2).

Figura 2. Aggiornamento dei package installati.

Se si vuole aggiornare solo uno o più package (magari perché si sa a priori che qualche aggiornamento contiene dei bachi o è incompatibile con altri software installati sul Mac)

$ brew upgrade package1 [package2 ...]

dove package1, package2, indicano i nomi dei package da aggiornare.

Versioni

Quando si aggiorna un package, Homebrew ne mantiene anche le versioni precedenti. Il comando

$ brew list --versions

elenca i package installati con i relativi numeri di versione. Se un package è stato già aggiornato, tutte le versioni presenti nel sistema sono mostrate sulla stessa riga (Figura 3).

Figura 3. Elenco dei package installati con i relativi numeri di versione. In evidenza un package di cui sono presenti due versioni diverse.

Per mettere in evidenza i package di cui esistono versioni multiple si aggiunge una ulteriore opzione a brew list che, sul Mac con una installazione relativamente recente di Homebrew che sto usando, riporta soltanto

$ brew list --versions --multiple
git 1.9.2 1.9.3
readline 6.3.3 6.3.5

Su un sistema più vissuto, la lista dei package in versioni multiple può diventare molto lunga (Figura 4).

Figura 4. Package in versioni multiple su un Mac con una installazione meno recente di Homebrew.

Per rimuovere le vecchie versioni di un package, lasciando installata l’ultima versione

$ brew cleanup package

mentre per rimuovere in blocco le vecchie versioni di tutti i package installati

$ brew cleanup [-n]

dove l’opzione -n serve ad eseguire un dry-run, cioè mostra le operazioni che saranno svolte senza eseguirle realmente (Figura 5). Togliendo l’opzione -n il sistema effettua la rimozione effettiva dei package più vecchi.

Figura 5. Esecuzione del comando `brew cleanup` in modalità `dry-run`, cioè senza eseguire le operazioni previste dal comando.

Disinstallazione

Per disinstallare un package, come abbiamo visto, si usa

$ brew remove package

oppure

$ brew uninstall package

che mi sembra più facile da ricordare.

Se sono presenti versioni multiple di un package, Homebrew disinstalla solo la versione più recente. Per rimuovere definitivamente un package di cui sono installate varie versioni è quindi consigliabile eseguire in sequenza

$ brew cleanup package
$ brew uninstall package

Quando si installano i package i file di installazione, sia in forma di sorgenti da compilare che di bottle precompilate, vengono salvati in una cartella ben definita, generalmente /Library/Caches/Homebrew, detta la cache di Homebrew. Il percorso della cache viene riportato dal comando

$ brew --cache
/Library/Caches/Homebrew

Si noti fra parentesi che, se si racchiude un qualunque comando fra $(...), il Terminale (o meglio l’interprete dei comandi bash) consente di usarne l’output come dato di ingresso di comandi successivi. Ad esempio, per elencare il contenuto della cache di Homebrew si può scrivere

$ ls -a /Library/Caches/Homebrew

oppure

$ ls -a $(brew --cache)

che è particolarmente comodo se si vogliono automatizzare determinate operazioni (Figura 6).

Figura 6. Parte del contenuto della cache di una installazione di Homebrew.

Una volta installato il package, i file di installazione dei package di Homebrew non sono più strettamente necessari (analogamente ai file .dmg che in OS X contengono nella maggior parte dei casi le applicazioni da installare) ed occupano inutilmente spazio sul disco rigido. Inoltre, soprattutto dopo installazioni fallite, si può voler rimuovere il file di installazione e scaricare una nuova versione pulita.

Per rimuovere dalla cache i file di installazione di uno o più package

$ rm -rf $(brew --cache package1 [package2 ...])

e per ripulire completamente la cache (naturalmente senza rimuovere i package installati)

$ rm -rf $(brew --cache)

Per programmatori

Un comando utile a chi ha esperienza di programmazione quando si installano nuovi package è

$ brew options package

che mostra le (eventuali) opzioni non standard di installazione di un determinato package. Ad esempio

$ brew options pandoc

non riporta nulla, mentre eseguendo

$ brew options git

si ottiene

--with-blk-sha1
    ompile with the block-optimized SHA1 implementation
--with-brewed-curl
    Use Homebrew's version of cURL library
--with-brewed-openssl
    Build with Homebrew OpenSSL instead of the system version
--with-gettext
    Build with gettext support
--with-pcre
    Build with pcre support
--with-persistent-https
    Build git-remote-persistent-https from "contrib" directory
--without-completions
    Disable bash/zsh completions from "contrib" directory
--devel
    install development version 2.0.0.rc3
--HEAD
    install HEAD version

Se si sa esattamente cosa si sta facendo, una o più di queste opzioni possono essere inserite nel comando di installazione del package, che verrà compilato con le opzioni prescelte e non con quelle di default. Ad esempio

$ brew install --with-brewed-openssl git

compila git usando la libreria OpenSSL – che tanto ha fatto parlare di sé negli ultimi tempi – contenuta in Homebrew e non quella installata in OS X (che è comunque immune all’Heartbleed Bug).

Il comando brew list seguito dal nome di un package

$ brew list [--verbose] package

elenca i file e le cartelle installati da quel package

$ brew list pandoc
/usr/local/Cellar/pandoc/1.12.3/bin/pandoc
/usr/local/Cellar/pandoc/1.12.3/etc/bash_completion.d/pandoc-completion.bash
/usr/local/Cellar/pandoc/1.12.3/share/doc/x86_64-osx-ghc-7.6.3/pandoc-1.12.3/COPYING
/usr/local/Cellar/pandoc/1.12.3/share/man/ (2 files)
/usr/local/Cellar/pandoc/1.12.3/share/x86_64-osx-ghc-7.6.3/ (38 files)

e, con l’opzione --verbose, mostra i file contenuti in tutte le cartelle installate (l’elenco può essere davvero molto lungo).

Formule

In tutti i miei post su Homebrew ho volutamente preferito usare il termine package invece di formula, come è più usuale in Homebrew e come si troverà scritto in tutta la documentazione disponibile.

Un package indica infatti il programma che vogliamo installare, mentre la formula è la serie di comandi usati da Homebrew per installarlo, scritta in Ruby. In Homebrew i due significati si confondono, ma secondo me è più comprensibile mantenerli distinti.

Se siamo curiosi di sapere come è fatta la formula di un package di Homebrew

$ brew cat package

Ad esempio

$ brew cat pandoc

mostra la formula che serve a compilare ed installare il solito pandoc (Figura 7).

Figura 7. `Formula` per l'installazione del package `pandoc`.

Quello che fa questa formula è abbastanza evidente, anche senza conoscere Ruby o altri linguaggi di programamzione.

Ed è questa un’altra caratteristica utile di Homebrew: rende la vita facile non solo a chi si limita ad installare i package, ma anche agli sviluppatori che si occupano di prepararli.

Uno degli aspetti che approfondiremo prossimamente.

Homebrew: installazione e disinstallazione

Sun, 04 May 2014 06:00:00 +0000

Nel post precedente abbiamo fatto la conoscenza con Homebrew, uno dei sistemi di gestione dei pacchetti software open source di derivazione Unix/Linux sviluppati per OS X.

Dopo la lunga introduzione al sistema con i suoi pro e contro è ora di sporcarsi le mani imparando ad installare (e, non si sa mai, a disinstallare) Homebrew.

Homebrew può essere installato sui Mac con processore Intel ed è compatibile con le versioni di OS X più recenti fino a OS X 10.5.8 (Leopard). Esiste anche una versione sperimentale (Tigerbrew) per i vecchi processori PowerPC, compatibile con Leopard e perfino con Tiger.

Installazione di Xcode

Prima di installare Homebrew è necessario aver installato Xcode, lo strumento principale per sviluppare le applicazioni per OS X e iOS, o almeno i Command Line Tools, gli strumenti a linea di comando che sono un sottoinsieme dell’Xcode completo.

Il pacchetto Xcode compatibile con le versioni di OS X da Snow Leopard in poi può essere installato direttamente dall’App Store. Gli utenti di Leopard possono scaricare l’ultima versione compatibile (la 3.1.4) dopo essersi registrati gratuitamente sul sito Developer della Apple (si può anche usare il proprio Apple ID). Per trovare rapidamente il link al pacchetto di installazione basta inserire la stringa “xcode 3.1.4” nel campo di ricerca in alto a sinistra.

La procedura esatta per installare i Command Line Tools cambia purtroppo a seconda della versione di Xcode.

I Command Line Tools sono integrati in Xcode 3.1.4 e non si possono installare separatamente dal resto del pacchetto. Bisogna solo assicurarsi che siano selezionati nel corso dell’installazione di Xcode.
Con Xcode 4.x e 5.0, si deve eseguire l’applicazione, selezionare Preferenze dal menu di Xcode e, dopo aver cliccato sull’icona Downloads, selezionare l’installazione dei Command Line Tools.
A partire dalla versione 5.0.1 di Xcode, i Command Line Tools non sono più integrati in Xcode e devono essere scaricati manualmente dal sito Developer della Apple.

In alternativa, con le ultime versioni di OS X si può eseguire dal Terminale (si trova in /Applicazioni/Utility) il comando

$ sudo xcode-select --install

Ricordo che il $ indica il prompt del Terminale e non va inserito. Ricordo anche che sudo permette ad un utente di OS X di eseguire i comandi del Terminale come se fosse l’onnipotente amministratore (root) dei sistemi Unix/Linux. Non tutti gli utenti di un Mac possono eseguire sudo, ma di sicuro può farlo almeno l’utente creato al momento dell’installazione di OS X – a cui viene assegnato automaticamente il ruolo di amministratore del sistema – ma solo dopo aver protetto il proprio account con una password (preferibilmente decente).

Dopo aver inserito la password associata al proprio account, comparirà la finestra mostrata in Figura 1.

Figura 1. Installazione dei `Command Line Tools` dal Terminale.

A questo punto si può premere Install per installare i soli Command Line Tools, oppure premere Get Xcode per installare Xcode dall’App Store. Io ho sempre installato l’Xcode completo sui miei Mac e non ho idea se la prima opzione possa creare dei problemi. In ogni caso, si può sempre installare anche in seguito l’intero Xcode dall’App Store (reinstallando eventualmente da zero Homebrew). Per maggiori dettagli, è utile consultare questa pagina web che purtroppo non è aggiornata a Mavericks.

Installazione di Homebrew

Per installare Homebrew basta aprire il Terminale ed eseguire il comando

~~$ ruby -e “$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"~~

~~$ ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"~~

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

In pochi minuti Homebrew verrà scaricato ed installato automaticamente in /usr/local/ (Figura 2). Tutto qui.

Figura 2. Installazione di Homebrew.

Subito dopo l’installazione è consigliabile eseguire immediatamente il comando

$ brew doctor

che, come indica il nome, controlla che non ci siano conflitti fra i file installati da Homebrew e quelli eventualmente già presenti in /usr/local/.

Il controllo eseguito da brew doctor è molto accurato, forse persino troppo, come mostrato in Figura 3, dove compaiono una serie di avvisi (warning) dovuti alla presenza sul mio Mac dei file installati da MacTex in parallelo ad Homebrew. Questi avvisi non sono preoccupanti – solo gli errori veri e propri lo sono – ma ci vuole un po’ per imparare a districarsi fra errori veri e propri e semplici avvisi.

Figura 3. Ecco `brew doctor` in azione.

Disinstallazione di Homebrew

Non si sa mai. Magari le cose non funzionano, magari Homebrew non ci piace e vogliamo tornare a MacPorts o Fink… È sempre utile sapere come fare a disinstallare Homebrew (o un qualunque altro pacchetto software) dal sistema.

In due parole: bisogna eseguire nel Terminale lo script bash contenuto nella pagina Uninstall Homebrew.

Chi ha conoscenze sufficienti del Terminale può finire di leggere qui. Per gli altri, ho cercato di elaborare una serie di istruzioni dettagliate da seguire passo passo.

Innanzi tutto bisogna andare alla pagina web Uninstall Homebrew, cliccare sul tasto Download Gist e salvare il file gist1173223-afa922fc4ea5851578f4680c6ac11a54a84ff20c.tar.gz (questo è il nome attuale del file, nel vostro caso può essere diverso) in una qualunque cartella del disco rigido (ad esempio sulla Scrivania o, nel gergo del Terminale, sul Desktop). Lanciare poi il Terminale ed eseguire i comandi

$ cd Desktop
$ tar -xzf gist1173223-afa922fc4ea5851578f4680c6ac11a54a84ff20c.tar.gz
$ cd gist1173223-afa922fc4ea5851578f4680c6ac11a54a84ff20c
$  sh ./uninstall_homebrew.sh

In pochi secondi Homebrew verrà rimosso dal sistema senza toccare gli eventuali altri file presenti in /usr/local/ (Figura 4).

La sequenza di comandi serve a (1) spostarsi nella cartella Desktop cioè sulla Scrivania del Mac, (2) scompattare il file compresso gist....tar.gz, (3) spostarsi nella cartella creata dopo la decompressione del file (non serve scrivere il nome completo della cartella, è sufficiente inserire i primi caratteri e premere il tasto Tab e il sistema provvederà ad aggiungere il resto automaticamente) e infine (4) eseguire lo script bash che effettua la disinstallazione vera e propria di Homebrew.

Alla fine del processo di disinstallazione compare di nuovo nel Terminale il simbolo $. Una volta chiuso il Terminale si può tranquillamente rimuovere dal Desktop il file gist1173223-afa922fc4ea5851578f4680c6ac11a54a84ff20c.tar.gz e la cartella relativa.

Figura 4. I comandi per disinstallare Homebrew.

Credetemi, è molto più complicato descrivere la procedura nei dettagli che eseguirla!

La prossima volta, prometto, sarà davvero la volta dei comandi di base di Homebrew.

Gemelli o diversi?

Fri, 31 Jan 2014 06:00:00 +0000

Mi capita spesso di ricevere o scaricare dei documenti senza riuscire a capire immediatamente se sono nuove versioni di file che ho già sul Mac o se ho solo prelevato lo stesso file con un nome diverso.

La soluzione più immediata è quella di aprire i documenti in due finestre affiancate e confrontarli ad occhio nudo. È una soluzione perfetta se i documenti sono profondamente diversi, ma non funziona se le differenze sono limitate a poche parole sparse qua e là.

Per essere sicuri al 100% che i file siano identici, basta utilizzare il Terminale di OS X. Il comando in questione è md5 che, in base al manuale, calcola una specie di firma digitale (detta hash) del file che gli viene fornito in ingresso. Il comando utilizza il ben noto algoritmo MD5, che è descritto nei dettagli nell’RFC1321. La particolarità dell’algoritmo è che la probabilità che due file diversi producano lo stesso hash (la cosiddetta collisione) è estremamente bassa.

Questo algoritmo è stato ormai ampiamente superato nelle applicazioni crittografiche, ma per i nostri scopi va più che bene.

Per controllare quindi che due file siano o meno identici, basta lanciare il Terminale (è in Applicazioni ➔ Utility, ma sarebbe meglio trascinarne una volta per tutte l’icona nel Dock), scrivere md5 -q seguito da uno spazio e trascinare una alla volta nel Terminale le icone dei (due o più) file da confrontare, premendo alla fine il tasto Invio. Il risultato è una serie di stringhe alfanumeriche, corrispondenti a ciascuno dei file controllati. Se le stringhe sono uguali lo sono di sicuro anche i file (a meno di casi eccezionali), in caso contrario possiamo essere certi che i file in ingresso differiscono fra loro, anche per un solo carattere.

Un esempio pratico

Prendiamo un file PDF qualunque, File_A1.pdf, trasciniamolo sul Desktop e duplichiamolo, rinominando la copia come File_A2.pdf. Lanciamo il Terminale ed eseguiamo i seguenti comandi (notare che il $ è il prompt del Terminale e non va inserito):

$ cd ~/Desktop

per spostarci nella cartella del Desktop,

$ md5 -q File_A1.pdf File_A2.pdf

che produce in uscita le due stringhe

8610396351906b395de49dccc7470ebf
8610396351906b395de49dccc7470ebf

corrispondenti rispettivamente ai miei due file di partenza File_A1.pdf e File_A2.pdf. Le due stringhe sono identiche e quindi, come sappiamo, anche i file controllati sono identici (ovviamente usando altri file le stringhe di output saranno differenti da queste).

Si noti che ho preferisco usare l’opzione -q (quiet) per evitare che il comando md5 stampi il percorso completo dei file controllati, che rende molto più complicato trovare a prima vista la stringa di hash. Provare per credere.

Duplichiamo ancora il file File_A1.pdf, rinominandolo questa volta come File_B.pdf. Lanciamo Anteprima ed apriamo il file File_B.pdf. Nelle ultime versioni di OS X Anteprima permette di modificare (parzialmente) il testo dei file pdf o di aggiungere evidenziazioni al testo. Per farlo, basta premere l’icona Edit (l’ultima a destra sulla barra degli strumenti) oppure selezionare la voce corrispondente posta nel menu Vista.

Modifichiamo in qualche modo il file, ad esempio selezionando con un doppio click una parola ed evidenziandola con Strumenti ➔ Annota ➔ Evidenzia il Testo, e salviamo il file modificato.

Torniamo al Terminale ed eseguiamo il comando

$ md5 -q File_A1.pdf File_B.pdf
8610396351906b395de49dccc7470ebf
22908db2457cf64af17c1296cb5f37e1

che ci mostra immediatamente come ora il secondo file sia ora diverso da quello originale. La figura seguente mostra l’esecuzione completa dei comandi ne mio Terminale.

Tre brevi commenti per concludere:

Il comando md5 è disponibile di default su OS X (ovviamente!) e su qualunque distribuzione moderna di Linux e Unix, dove però viene generalmente rinominato md5sum. In Windows, invece, si può installare il File Checksum Integrity Verifier (FCIV), uno strumento semi-ufficiale della Microsoft, che permette di calcolare la firma digitale di un file mediante vari algoritmi, fra cui l’md5.
La variante md5 -s "Questa e' una stringa" permette di calcolare l’hash di una stringa qualunque, aprendo la porta ad applicazioni nel campo della generazione casuale di password forti a partire da stringhe facilmente memorizzabili.
I programmi che trovano automaticamente i file duplicati sull’hard-disk funzionano più o meno su queste basi.

Rinominare i file con il Terminale

Sat, 21 Dec 2013 06:00:00 +0000

Tempo fa ho partecipato ad un sondaggio online del Ministero dell’Istruzione relativo al valore legale del titolo di studio. Mentre creavo l’account e compilavo il questionario, ho eseguito una serie di screenshot delle pagine del browser, a futura memoria e ho messo tutte le immagini in una cartella apposita.

Alla fine di tutto mi sono trovato con parecchie immagini, chiamate Screen shot anno-mese-giorno at ora.minuto.secondo contenenti quindi la data e l’ora del momento dell’acquisizione. Ovviamente volevo rinominarle in un modo più comprensibile. Farlo a mano era fuori discussione.

Ma sul Mac che stavo usando in quel momento non ho trovato nessun programma di rinominazione dei file, e non avevo voglia di andarne a cercare uno affidabile in rete. E poi, se lo avessi fatto, come avrei potuto scrivere questo post?

Ho deciso che bash avrebbe fatto il lavoro sporco per me. Bash è l’interprete di comandi da terminale usato di default in Mac OS X, con il quale si possono lanciare comandi per copiare i file, rinominarli, creare cartelle (o più propriamente, directory), eseguire ricerche di file o ricerche nel contenuto dei file stessi, compiere cicli ripetitivi e decine di altre cose essenziali per un uso produttivo del computer.

Ho lanciato il Terminale (sul Mac è in Applicazioni -> Utility) e mi sono spostato nella cartella (directory!) dove avevo salvato le immagini. Come?

Con Mac OS X (e anche con Linux) è molto semplice. Basta per prima cosa andare alla cartella desiderata con il Finder. Poi lanciare il Terminale e scrivere, dopo il prompt di bash (cioè dopo il simbolo del $)

$ cd

seguito da uno spazio, poi tornare al Finder, selezionare la piccola con che simboleggia la cartella aperta, posta in alto al centro della barra del Finder, e trascinare l’icona sul Terminale aperto. Molto più complicato da scrivere che da fare.

Insomma, se supponiamo di aver messo gli screenshot nella cartella immagini sul Desktop, dopo questa operazione nel Terminale dovremmo vedere

$ cd /Users/nome_utente/Desktop/immagini

dove nome_utente è il nome breve dell’utente che sta usando il Mac, stabilito alla prima esecuzione di OS X durante la configurazione del sistema operativo.

Premiamo invio e andremo così all’interno della directory desiderata.

Per elencare i file contenuti nella cartella, basta eseguire il comando

$ ls -1

(“ls meno uno”) che mostrerà il solo elenco dei file, oppure

$ ls -l

(“ls meno elle”) con il quale otterremo parecchie informazioni in più, fra cui data e ora in cui i file sono stati creati.

A questo punto, scriviamo nel Terminale questo comando (attenzione, deve stare su un’unica riga)

$ cnt=0; find . -name "*.png" -print | while read i; do mv "${i}" immagine_$cnt; (( cnt++ )); done

Voilà. I nostri file sono stati rinominati in immagine_0, immagine_1, etc. La rinominazione non è perfetta ma accontentiamoci, almeno per ora.

Essere riusciti a rinominare i file con una sola riga di comandi bash è per ora più che soddisfacente.

Questa semplice riga di comandi contiene però una quantità inimmaginabile di strumenti e di concetti fondamentali, che cercheremo di approfondire nel corso del tempo.

P.S.: Quello che è particolarmente divertente è che ho potuto partecipare al cosiddetto sondaggio del Ministero anche con un nome totalmente inventato. Sono riuscito ad entrare senza trucchi nel sito, utilizzando solo un codice fiscale basato sulla mia identità fittizia e la password inviata dal Ministero ad un indirizzo email creato appositamente.

Le immagini che ho catturato dalla finestra del browser lo testimoniano. Tanto per dimostrare quanto siano affidabili certe applicazioni web.

Ne riparleremo.