Launchd on Melabit

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.

Automatizzare il Mac dal Terminale - Ancora Launchd

Tue, 28 Apr 2015 06:00:00 +0000

A volte bisogna saper ammettere i propri errori. Questa è una di quelle volte.

Nel mio post su launchd di qualche mese fa non avevo nascosto il mio scetticismo per una soluzione molto lontana dai canoni di Unix e troppo complicata per essere usata al posto di cron, il programma che nei sistemi operativi derivati da Unix è incaricato di eseguire periodicamente dei comandi o degli interi script in modo automatico.

Leggendo però questo post su MacStories, mi sono reso conto dell’esistenza di una ulteriore opzione di launchd, QueueDirectories, che permette di di tenere sotto controllo una (o più) directory del Mac e di eseguire automaticamente un comando ogni qualvolta si aggiunge un file alla directory osservata.¹ Oltre a questa esiste una opzione più generale, WatchPaths, che permette di tenere sotto controllo uno o più file (o directory) ed eseguire un comando quando uno di questi file (o directory) viene modificato.

Con queste due nuove (almeno per me!) opzioni si può estendere notevolmente il campo di applicazione di launchd, facendogli eseguire un comando o uno script non solo in modo periodico (in sostituzione di cron), ma anche al verificarsi di un evento come l’aggiunta di un file ad una directory o la modifica di un determinato file.

Launchd, l’osservatore

Riprendiamo quindi il file plist di configurazione del post precedente e vediamo cosa possiamo fare se aggiungiamo l’opzione QueueDirectories.

Il punto di partenza è sempre lo stesso: vogliamo eseguire automaticamente lo script ~/bin/makeblog e rigenerare automaticamente il blog “Pazzi per la mela”.

Questa volta però vogliamo rigenerare il blog non ad un’ora ben definita ed immutabile, ma solo quando inseriamo un nuovo post nella directory ~/Dropbox/blog/.

In questo caso usare Dropbox (o un qualunque servizio analogo, Box, Copy, Google Drive, o perfino OneDrive di Microsoft) è particolarmente utile, perché permette di aggiungere il post anche lontano dal Mac, magari dopo averlo preparato sull’iPad o sull’iPhone.

Il file plist di configurazione del post precedente diventa

<?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>Program</key>
	<string>/Users/utente/bin/makeblog</string>
	
	<key>QueueDirectories</key>
	<array>
    	<string>/Users/utente/Dropbox/blog/</string>
	</array>
	
	<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>

Per attivarlo, come abbiamo già visto, basta salvarlo nella directory ~/Library/LaunchAgents/ del proprio account (dove il simbolo ~ indica la cartella Inizio o home dell’utente che sta usando il Mac) con il nome it.pazziperlamela.makeblog.plist (il nome del file deve essere uguale a quello senza estensione utilizzato alla riga 6 del file plist), ed eseguirlo una prima volta dal Terminale con il comando

$ launchctl load it.pazziperlamela.makeblog.plist

Ai successivi riavvii sarà il sistema operativo ad eseguire periodicamente lo script.

Conclusioni

Devo ammettere che le opzioni QueueDirectories e WatchPaths rendono launchd molto più interessante di quanto mi sia mai reso conto, permettendo di eseguire dei comandi di sistema o degli interi script in modo asincrono, al verificarsi di eventi particolari come la scrittura o la modifica di un file in una directory.

Intendiamoci, le mie riserve sulla complessità di launchd rimangono intatte. Inoltre continua a non piacermi il fatto che sia uno strumento confinato al solo OS X, con poche prospettive di diffusione al di fuori del mondo Apple fra i sistemi operativi derivati da Unix, come Linux e BSD.

Però pragmaticamente mi rendo conto che in certe circostanze launchd può rivelarsi uno strumento utilissimo e senza eguali. Basta solo usarlo con moderazione.

Qualcosa di simile alle cosiddette “Folder Actions”, introdotte già da parecchi anni in OS X senza troppo successo, che istruivano il sistema operativo a tenere sotto controllo una directory e ad eseguire dei comandi AppleScript o Automator ogni volta che un file veniva aggiunto o rimosso da quella directory, oppure quando quest’ultima veniva aperta, chiusa o spostata. ↩︎

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