Unix on Melabit

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. ↩︎

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.

Un anno, cento post

Thu, 18 Dec 2014 06:00:00 +0000

Questo blog spegne oggi la sua prima candelina virtuale con il centesimo post. Una coincidenza non casuale ma niente affatto pianificata.¹

Un anno fa non avrei mai potuto pensare di riuscire a scrivere tanto. È stata una bella fatica, ma allo stesso tempo una sfida divertente. Che ha messo a dura, durissima, prova la mia capacità di spiegare qualcosa in modo comprensibile. Spero qualche volta di esserci riuscito.

In effetti qualche giorno fa mi sono accorto di essere arrivato quasi a cento e ho anticipato la pubblicazione di un paio di articoli per far coincidere le due date. ↩︎

Automatizzare il Mac dal Terminale - Una soluzione targata Apple

Thu, 11 Dec 2014 06:00:00 +0000

Dopo i programmi di derivazione Unix, at e cron, è la volta di parlare di launchd, una soluzione sviluppata dalla Apple per OS X.

Launchd

Launchd è il programma che, a partire dalla versione 10.4 (Tiger) di OS X, esegue tutti i processi di avvio del sistema operativo e che, come se non bastasse, può anche svolgere i compiti eseguiti da cron.

Launchd è stato sviluppato dalla Apple e, dopo qualche incomprensione, è stato rilasciato sotto la licenza open source Apache, con l’intento di promuoverne l’adozione anche sotto Linux e BSD. Finora però l’accoglienza al di fuori di OS X è stata tiepida, se non peggio, e quindi al momento launchd rimane confinato al solo Mac.

La cosa non mi stupisce.

Al di là degli aspetti tecnici relativi al porting su altre piattaforme e focalizzando l’attenzione solo sull’utilizzo di launchd al posto di cron, sono perfettamente d’accordo con quanto è stato scritto tempo fa su Low End Mac, con il titolo significativo Apple’s launchd Is Anti-Unix (Launchd di Apple è anti-Unix).

One of the great things about Unix-like systems is that most of your skills, programs, dot files, and highly polished shell scripts are portable. I brought them with me to OS X after dragging them through a dozen or so Linux distributions…
Consequently, I was distressed when launchd emerged from the dark side of One Infinite Loop…
Merging periodically run jobs into the main system process doesn’t make sense. Replacing a simple /etc/crontab text file with multiple, awkwardly named XML plist files scattered among no less than four different directories is taking two big steps toward complexity.

Credo sia abbastanza chiaro anche così, ma lo traduco qui sotto perché ne condivido ogni parola.

Una delle cose migliori dei sistemi Unix è che la maggior parte delle competenze, dei programmi sviluppati, dei file di configurazione [detti “dot file” perché il nome di questi file inizia in genere con un punto] e degli script di shell sono portatili [su piattaforme differenti]. Io me li sono portati dietro su OS X dopo averli fatti transitare per una dozzina di distribuzioni diverse di Linux…
Di conseguenza mi preoccupa vedere launchd emergere dalla faccia oscura di One Infinite Loop [l’indirizzo della Apple]…
Non ha senso mescolare processi eseguiti periodicamente con il processo principale [di inizializzazione] del sistema operativo. Sostituire un semplice file di testo /etc/crontab con una serie di file plist in formato XML con nomi assurdi e distribuiti su almeno quattro directory diverse è un bel passo avanti [sarebbero due, ma in italiano non viene bene] verso la complessità…

Launchd contro cron

Se consideriamo il semplice obiettivo di rendere automatiche certe attività ripetitive sul Mac, la chiave del discorso sta proprio nell’ultima frase citata: “Sostituire un semplice file di testo /etc/crontab con una serie di file plist in formato XML con nomi assurdi, distribuiti su almeno quattro directory diverse è un bel passo avanti verso la complessità”.

Launchd è molto più complicato di cron, inutilmente più complicato. Basta usarlo un po’ per accorgersene.

Proviamo a sostituire launchd a cron per eseguire lo script ~/bin/makeblog e rigenerare automaticamente il blog “Pazzi per la mela” alle 2:00 di ogni notte.

Con cron basta solo aggiungere al file crontab la riga seguente

00	02	*	*	*	~/bin/makeblog

Se invece si vuole utilizzare launchd, bisogna creare un file plist di configurazione in linguaggio XML più o meno come questo,

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>it.pazziperlamela.makeblog</string>
	
	<key>ProgramArguments</key>
	<array>
		<string>/Users/utente/bin/makeblog</string>
	</array>
	
	<key>StartCalendarInterval</key>
	<dict>
		<key>Hour</key>
		<integer>02</integer>
		<key>Minute</key>
		<integer>00</integer>
	</dict>
	
	<key>StandardOutPath</key>
	<string>/Users/utente/Documenti/makeblog.log</string>
	
	<key>StandardErrorPath</key>
	<string>/Users/utente/Documenti/makeblog.err</string>

	<key>RunAtLoad</key>
	<false/>
</dict>
</plist>

salvarlo nella directory ~/Library/LaunchAgents/ del proprio account (la ~ indica la cartella Inizio o home dell’utente che sta usando il Mac) usando obbligatoriamente il nome it.pazziperlamela.makeblog.plist (il nome del file deve essere uguale a quello senza estensione utilizzato alla riga 6 del file plist), e infine eseguirlo una prima volta dal Terminale con il comando

$ launchctl load it.pazziperlamela.makeblog.plist

Per fortuna ai successivi riavvii ci pensa il sistema operativo ad eseguire periodicamente lo script.

Un brevissimo tutorial

Può essere utile descrivere brevemente le informazioni essenziali da inserire nel file plist di configurazione, in modo che il processo automatico gestito da launchd funzioni correttamente. Per ulteriori informazioni, consiglio la lettura di quest’ottimo tutorial e delle specifiche dettagliate del formato del file plist usato da launchd.

Le prime tre righe del file specificano tipo e versione dei formati xml e plist utilizzati, e vanno copiate esattamente come sono scritte nell’esempio precedente.

Il file plist deve contenere tre chiavi obbligatorie. La prima, Label (riga 5), serve per specificare il nome del file plist stesso, senza estensione. Nel nostro caso il nome del file è it.pazziperlamela.makeblog (riga 6).¹

La chiave ProgramArguments (riga 8) serve invece per specificare il percorso e il nome dello script di shell da eseguire. Qui è /Users/utente/bin/makeblog, dove al posto di utente bisogna sostituire il nome breve del proprio account. Il modo più semplice per ottenere il proprio nome breve è eseguire da Terminale il comando whoami (oppure id -un).

L’ultima chiave obbligatoria, StartCalendarInterval (riga 13), definisce ora e minuto (oltre che eventualmente giorno della settimana, giorno e mese) in cui launchd deve eseguire lo script di shell. In alternativa si può usare la chiave StartInterval, che lancia invece lo script ogni certo numero di secondi, a partire dalla prima esecuzione del processo tramite launchctl.

Due ulteriori chiavi opzionali, StandardOutPath e StandardErrorPath (righe 21 e 24), definiscono rispettivamente il percorso dei file da usare per salvare l’output completo generato dal comando e gli eventuali messaggi di errore. Anche in questo caso bisogna sostituire nel percorso dei file il proprio nome breve al posto dell’utente generico.

Un’altra utile chiave opzionale è RunAtLoad (riga 27), che specifica se lo script di shell deve essere eseguito al momento del caricamento da parte di launchctl. Questa opzione è inutile se, come in questo caso, si definiscono esattamente gli orari di esecuzione del processo tramite la chiave StartCalendarInterval. Se invece si usa la chiave StartInterval, bisogna impostare RunAtLoad al valore true/, in modo da fissare il tempo iniziale da cui far partire il conteggio dei secondi.

Due comandi utili

Per elencare tutti i processi gestiti da launchd in un dato momento si esegue da Terminale il comando

$ launchctl list

Il Mac su cui sto scrivendo questo post elenca ben 294 processi, considerando sia i processi attivi che quelli ormai terminati.

Per smettere di eseguire automaticamente lo script it.pazziperlamela.makeblog.plist, si deve eseguire il comando

$ launchctl unload ~/Library/LaunchAgents/it.pazziperlamela.makeblog.plist

e poi cancellare (o spostare) il file it.pazziperlamela.makeblog.plist dalla directory ~/Library/LaunchAgents/. In caso contrario, lo script tornerà ad essere lanciato automaticamente al prossimo riavvio.

Conclusioni

È evidente che non mi piace l’idea di usare launchd al posto di cron. Troppo complicato e troppo proprietario. Una vera pugnalata ad uno dei principi cardini di Unix (e del software ben fatto): fare una cosa sola ma farla bene e in modo efficiente.

Intendiamoci, launchd va benissimo per gestire l’avvio del sistema e i servizi automatici (i demoni) gestiti dal sistema operativo e dalla sua introduzione in (Mac) OS X 10.4/Tiger ha reso molto più veloce il processo di avvio di OS X. Ma sostituire launchd a cron introduce un livello di complessità inutile ed insensato.

Nonostante tutto c’è qualcuno a cui launchd piace anche per questo scopo. Contento lui, io finché posso preferisco tenermi stretto il buon vecchio cron.

Il formato consigliato per il nome del file plist è il cosiddetto Uniform Type Identifier (UTI), una struttura simile a quella di un dominio web inverso. In questo caso è stato preso il nome dello script da eseguire makeblog, lo si è aggiunto all’indirizzo del (presunto) sito web del progetto pazziperlamela.it, e infine si è invertito l’ordine della stringa risultante, makeblog.pazziperlamela.it, ottenendo il nome del file plist. ↩︎

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. ↩︎

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.

Homebrew: software per il Mac fatto in casa

Tue, 29 Apr 2014 06:00:00 +0000

Homebrew è un sistema di gestione dei pacchetti (package) che semplifica l’installazione su OS X del software open source di derivazione Unix/Linux.

Homebrew si autodefinisce “The missing package manager for OS X” (Il gestore di pacchetti per OS X che mancava), una definizione un po’ sfrontata – in particolare nelle prime fasi dello sviluppo alcuni anni fa – ma ormai non troppo lontana dalla realtà.

La sua semplicità di installazione e di uso l’hanno fatto crescere rapidamente in popolarità nell’ultimo anno, a scapito dei sistemi concorrenti più affermati, Fink e MacPorts (quest’ultimo supportato direttamente da Apple).

A differenza di questi ultimi, Homebrew cerca di usare per quanto è possibile gli strumenti software di base già presenti in OS X – gcc, perl, python, ruby, git, mysql, sqlite – e non obbliga l’utente ad installare duplicati inutili. I package suddetti sono comunque disponibili nell’archivio (repository) di Homebrew, per chi avesse bisogno di utilizzare versioni più recenti (e a volte meno stabili) di quelle utilizzate dalla Apple.

Da qualche mese Homebrew fornisce anche un gran numero di pacchetti precompilati (bottles), velocizzando notevolmente il processo di installazione e di aggiornamento dei pacchetti, che non devono più essere obbligatoriamente compilati uno alla volta.

Questa pagina su Stack Exchange approfondisce i pro e contro dei tre principali sistemi di gestione dei pacchetti su OS X. The state of package management on Mac OS X è una analisi piuttosto approfondita dei pregi e dei difetti di tutti i sistemi di gestione dei pacchetti per OS X, considerando anche quelli meno diffusi e supportati.

Una delle questioni più controverse riguardanti Homebrew riguarda il fatto che tutti i pacchetti sono installati all’interno della cartella (directory) /usr/local/. Alcuni critici osteggiano questa scelta, notando fra l’altro che:

/usr/local/ è una cartella di sistema che non dovrebbe essere usata da Homebrew ma solo dal software installato dall’utente root (l’amministratore onnipotente dei sistemi basati su Unix);
Homebrew modifica i permessi di alcune cartelle contenute all’interno di /usr/local/ assegnandoli all’utente che installa il gestore di pacchetti, mentre i permessi dovrebbero essere configurati in modo che le suddette cartelle siano usabili da tutti gli utenti del sistema;
è da preferire invece la scelta di MacPorts o Fink di usare delle cartelle create ad-hoc, rispettivamente /opt/ o /sw/.

Personalmente mi sembrano critiche risibili e che i vantaggi in termini di praticità e di sicurezza delle scelte fatte dagli sviluppatori di Homebrew superino di gran lunga i presunti svantaggi.

Del resto /usr/local/ e le cartelle in esso contenute sono fatte apposta per installare software specifico per la macchina in uso, vengono usate ad esempio da MacTeX e da Ghostscript, e non capisco cosa impedisca di usarle liberamente anche per altre applicazioni.

Assegnare i permessi di installazione e di uso dei pacchetti di Homebrew ad un singolo utente, piuttosto che a root, limita i rischi di sicurezza che il software installato potrebbe creare nel sistema. Inoltre è difficile negare che il Mac sia un sistema fondamentalmente monoutente, per cui questa scelta dovrebbe comunque andare bene nella maggior parte dei casi.

Nei casi rimanenti di un Mac condiviso da più utenti, indipendentemente dal fatto che ci giri OS X liscio o OS X Server, chi gestisce il sistema dovrebbe essere facilmente in grado di assegnare il gruppo utente giusto a chi è interessato ad usare i pacchetti di Homebrew.

Di sicuro una cosa non più complicata di dover aggiungere al PATH di ciascun utente il percorso della cartella (/opt/ o /sw/ a seconda dei casi) in cui vengono installati i pacchetti gestiti da MacPorts o Fink.

Nel corso del tempo ho usato tutti e tre i sistemi di gestione dei pacchetti, stabilizzandomi da almeno due anni su Homebrew che trovo complessivamente molto più lineare e usabile, senza le troppe opzioni di compilazione di MacPorts, che portano fin troppo spesso a incompatibilità con i pacchetti installati successivamente, o la confusione fra pacchetti binari e sorgenti, con comandi diversi di installazione, di Fink.

Dopo questa lunga introduzione, nel prossimo post vedremo come installare (ma anche disinstallare) Homebrew, ~~esaminando anche i principali comandi di gestione dei pacchetti~~.

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.

Melabit, il blog

Wed, 18 Dec 2013 06:00:00 +0000

Appare online da oggi questo nuovo blog, che sarà dedicato prevalentemente al Mac, alla programmazione e all’open source, con puntatine nella scienza e nella tecnologia in generale.

L’idea di avere una presenza online è partita da Lucio “Lux” Bragagnolo, tecno-scrittore, evangelizzatore Mac, consulente editoriale di Macworld Italia e noto blogger sul mondo Mac. Il blog sarebbe stato ospitato sul sito del nuovo Macworld Italia poi, per vari motivi, non se n’è fatto nulla.

L’idea però ha continuato a frullarmi in testa per quasi due anni e alla fine ho deciso di partire. Per me è una novità. Finora non ho mai voluto avere uno spazio personale sul web, limitandomi a contribuire dall’esterno a svariati blog e forum e, ormai parecchi anni fa, a vari newsgroup (qualcuno se li ricorda ancora?).

È anche una bella sfida e anche un impegno notevole. Spero solo di esserne all’altezza.

Chi sono? Sono uno che passa il tempo a leggere, a studiare, a fare esperimenti o a sviluppare modelli (più o meno) matematici. Insomma, sono quello che si dice un ricercatore, una figura un po’ arcana e con tristi reminiscenze scolastiche. Una figura anche parecchio squalificata di questi tempi, in questo strano Paese…

In realtà un ricercatore è una persona normale (beh, non sempre…), affascinata ed incuriosita da quello che lo circonda. Ma quello che faccio cercherò di spiegarlo meglio in un prossimo post.

Nel mio lavoro uso da anni prevalentemente il Mac, davanti al quale passo la maggior parte della giornata. E mi piace anche Unix, che è il motore che gira sotto l’interfaccia amichevole e graficamente strepitosa di OS X, e la sua incarnazione moderna, Linux.

Mi piacerebbe condividere qui alcune idee ed informazioni che provengono da quello che faccio ogni giorno e che hanno poco spazio nelle riviste dedicate ai Mac ed ai computer in generale.

Insomma, in questo blog si parlerà soprattutto di terminale, di programmazione, di reti di computer, di software piccolo o poco diffuso, meglio se open source, e magari a volte anche di scienza e tecnologia.

Tutti argomenti apparentemente ostici ma che, se vengono affrontati con il tono giusto, possono diventare estremamente interessanti e rendere molto più produttivo e flessibile l’uso quotidiano del computer.

Avrei volute scrivere tante altre cose e, soprattutto tante cose diverse, ma mi accorgo che presentarsi è veramente difficile (ed anche un po’ imbarazzante). Meglio farsi conoscere a poco a poco e focalizzare le idee con il tempo.

Spero di riuscire ad essere sufficientemente originale e non banale, affrontando temi interessanti da leggere e da commentare.

Spero anche di riuscire a mantenere una periodicità costante e prevedibile. Vedremo, non sarà facile.

Fatemi sapere per favore cosa pensate di quello che scrivo, ed eventualmente contestatelo. Ogni commento argomentato e civile, anche se negativo, sarà ben accetto.