Terminale on Melabit

Addio dc, benvenuta luka: una nuova calcolatrice RPN da Terminale

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

La Notazione Polacca Inversa (o RPN, dall’inglese Reverse Polish Notation) è un modo per eseguire operazioni matematiche senza usare le parentesi. Negli anni ‘70-80 l’RPN fu resa popolare da Hewlett-Packatd (HP), che l’utilizzò in tutte le sue calcolatrici scientifiche e finanziarie.

Con le calcolatrici della rivale Texas-Instruments, che usavano le parentesi, era facile perdere il conto di quante parentesi si erano aperte o chiuse, cosa che costringeva spesso a reinserire l’intera espressione dal principio. Chi usava una calcolatrice RPN non aveva questi problemi, anche se doveva superare un piccolo scoglio iniziale per abituarsi alla nuova notazione.

Oggi le calcolatrici fisiche sono poco usate, e quasi tutti preferiscono utilizzare un’app sul telefono o sul computer. Ma c’è ancora qualche nerd impenitente che non si arrende all’interfaccia grafica e si ostina ad usare il Terminale. Perché? Ad esempio, perché è molto più facile inserire numeri e operazioni complicate con la tastiera, che premere i tasti di vetro di una calcolatrice virtuale.

Premessa

Se avete fretta e non volete sobbarcarvi la lettura di questo lungo articolo, troverete tutte le informazioni che vi servono in questo post, sintetico ma come sempre brillante, su Quickloox, uno dei blog di riferimento per chi è appassionato del mondo Apple.

– Immagine generata da Google Gemini.

Un po’ di storia

La Polonia ci ha dato Niccolò Copernico, Fryderyk Chopin, Joseph Conrad, Marie Curie, Arthur Rubinstein, Stanislaw Lem. Ma ci ha dato anche Jan Lukasiewicz, un logico matematico (e filosofo) che cent’anni fa inventò una notazione matematica che non faceva uso di parentesi.

In questa notazione polacca tutti i simboli di operazione ( $ + $, $ - $, $ \times $, $ / $ ) precedono i numeri a cui si applicano. Lo stesso vale più in generale per le funzioni matematiche, come $ \sqrt{} $, $ \sin $, $ \cos $, $ \exp $ (dette operatori) e i numeri o le variabili (dette operandi) su cui agiscono.

Ad esempio, una operazione come $ 3 + 4 $, in notazione polacca viene scritta $ + \ 3 \ 4 $, mentre $ (5 + 2) \times (5 - 2) $ diventa $ \times + 5 \ 2 - 5 \ 2 $.

Per molti anni questa è rimasta solo una idea un po’ bislacca, perché il vantaggio di non usare le parentesi non sembrava compensare a sufficienza la notazione inusuale e più difficile da leggere.

Poi alla fine degli anni ‘50, John McCarthy rispolverò la notazione polacca (o prefissa) per il LISP, uno dei linguaggi di programmazione più influenti di tutti i tempi,¹ sviluppato con l’obiettivo di essere applicato allo sviluppo di programmi nell’ambito della nascente intelligenza artificiale.

La notazione prefissa, infatti, non solo semplificava notevolmente la scrittura dell’interprete LISP, ma permetteva anche di rappresentare allo stesso modo sia il codice che i dati, una cosa utilissima per un linguaggio finalizzato a rendere in computer intelligente. Ma meglio non divagare troppo.

Notazione polacca inversa

Ma la vera svolta avviene invertendo l’ordine fra operandi ed operatori, cioè scrivendo prima i numeri e poi le operazioni da eseguire, per cui $ 3 + 4 $ diventa $ 3 \ 4 \ + $ e $ (5 + 2) \times (5 - 2) $ diventa $ \ 5 \ 2 + 5 \ 2 - \times $.

Questa notazione polacca inversa (RPN) viene scoperta e riscoperta per almeno tre volte in vent’anni, ma diventò popolare solo all’inizio degli anni ‘60 quando Friedrich Bauer, inventore del concetto di stack e uno degli sviluppatori dell’ALGOL, e Edsger Dijkstra, famoso per la soluzione del “problema del cammino minimo” e per mile altre cose, ripresero in mano il concetto, perché permetteva di ridurre l’accesso alla memoria, che nei computer dell’epoca era scarsa e lenta, e di eseguire tutte le operazioni in un’area di memoria bene definita (lo stack) e per questo più facile da manipolare.

I vantaggi dell’RPN per eseguire i calcoli matematici erano così evidenti che HP la utilizzò in praticamente tutte le sue calcolatrici scientifiche e finanziarie, almeno fino all’inizio degli anni ‘90. Solo con lo sviluppo di memorie più capienti e di display molto più grandi divenne possibile visualizzare e modificare facilmente l’intera operazione impostata – e non più solo l’ultimo numero inserito – rendendo così meno necessario l’uso dell’RPN.

Una calcolatrice nel Terminale

Chi vuole usare una calcolatrice tradizionale nel Terminale di macOS o di Linux ha una scelta pressoché obbligata: bc, il basic calculator, presente in UNIX dal 1975, 50 anni filati. La versione attuale, disponibile su Linux e macOS, è stata completamente riscritta, ma quella originale era solo una interfaccia per dc (desk calculator), una delle più antiche utility presenti in UNIX e più vecchia persino del C.

E dc era… una calcolatrice RPN. Una scelta che confermava l’intuizione di HP: la notazione RPN era più efficiente e più semplice da implementare, e quindi ideale anche per i computer dalle risorse limitate degli anni ’70.²

Oggi l’RPN non è più una scelta quasi obbligata dalle limitazioni hardware, ma direi una scelta motivata soprattutto dalla pigrizia. Perché, una volta che si è spesa una mezz’oretta per imparare ad usarla, si scopre che è davvero molto più comodo eseguire i calcoli con questa notazione piuttosto che con quella tradizionale.

E poi forse c’è anche un certo gusto per andare controcorrente: in un mondo in cui tutti si uniformano ai dettami degli influencer (veri o presunti) sui social, usare una calcolatrice RPN diventa un modo per distinguersi, per sentirsi fuori dal coro, quasi una dichiarazione di indipendenza intellettuale.

dc è ancora presente in Linux e macOS e può essere tranquillamente usata dal Terminale, ma è una bella fatica, i suoi cinquant’anni si sentono (e si vedono) tutti. I risultati delle operazioni non si vedono, a meno di non stamparli sullo schermo con p. Nemmeno lo stack si vede, a meno di non chiederlo esplicitamente con f. I numeri negativi si indicano con l’underscore _ e non con il normale -, per cui $ - 4 $ si scrive $ \_4 $. E così via.

Ma da oggi c’è dc2 o meglio, luka.

La calcolatrice RPN del XXI secolo

E sì, perché da qualche settimana abbiamo a disposizione una nuova calcolatrice RPN per il Terminale di macOS di Linux, chiamata inizialmente dc2, in omaggio alla veneranda calcolatrice ormai ultracinquantenne.

Però dc2 sapeva troppo di una riscrittura dell’originale, mentre questo è un progetto completamente nuovo, scritto da zero in C. Meritava quindi un nome tutto suo, luka, in omaggio a Jan Lukasiewicz, l’inventore della notazione polacca (si veda il riquadro qui sopra).

Rispetto a dc, luka è davvero di un’altro secolo, e si vede appena si inizia a provarla. È interattiva, mostra in ogni momento il contenuto dello stack, ha la storia delle operazioni eseguite, le variabili, un help sintetico ma completo in linea, una pagina di manuale cristallina (ce ne fossero tante altre così!).

E poi luka è fatta in Italia. In tempi in cui si esalta l’identità nazionale per i motivi più futili, è bello vedere qualcosa che merita davvero di essere valorizzato.

Il programma in questo momento ha un piccolo bug legato alla visualizzazione dell’history, ma l’autore macina il codice molto più velocemente di quanto io macini le parole, per cui è più che probabile che il bug sarà corretto al più presto (vacanze permettendo).

Evoluzione del codice

Lo sviluppo di dc2/luka è stato rapidissimo. Dietro al progetto c’è Davide Mastromatteo, noto fra i suoi amici di penna come @mastro35 e autore dell’ottimo blog The Python Corner.

In pochi giorni Davide è passato dalla versione 0.1.0, perfettamente funzionale ma con una interfaccia utente ancora acerba,

alla versione 0.2.0, con una vista dello stack molto più chiara, la possibilità di usare gradi e radianti e di cambiare il formato di rappresentazione dei numeri, nonché con un help più compatto.

La versione 0.3.0 ha introdotto l’history delle operazioni eseguite e un help ancora rivisto,

mentre la versione 0.4.0, che è coincisa con il cambio di nome del programma, ci ha portato le variabili e parecchi nuovi comandi da tastiera, come si può vedere nelle prime immagini di questo articolo.

Usare luka

Installare luka sul Mac o su Linux è un attimo, almeno per chi usa homebrew (e chi non lo usa dovrebbe iniziare a farlo subito)

brew install mastro35/homebrew-mastro35/luka

Altrimenti basta scaricare l’ultima release del codice sorgente, scompattarla ed eseguire

make clean && make

dal Terminale, ovviamente dopo essersi spostati nella directory che contiene il codice sorgente.³

Inutile dire che chi ha installato make e un compilatore C su Windows, potrà compilare luka anche su questo sistema operativo.

Dimenticavo: presto arriveranno i pacchetti per Linux, in formato deb e rpn e, chissà, magari anche aur. E forse anche un installatore per Windows.

Sull’uso vero e proprio della calcolatrice c’è poco da dire. Chi conosce già l’RPN si troverà a suo agio, e ci metterà pochissimo ad usare luka al meglio. Chi non conosce l’RPN magari avrà voglia di provarla, per toccare con mano quanto sia più comodo eseguire un calcolo appena appena complicato con una calcolatrice RPN piuttosto che con una normale calcolatrice algebrica.

Di guide all’RPN ce ne sono a iosa, purtroppo sono tutte orientate a spiegarne l’uso con una calcolatrice fisica, come le ormai mitiche HP vintage, oppure con le emulazioni grafiche per Android o iOS.⁴

Rispetto a queste guide ci sono alcune differenze da considerare. La principale è che, non avendo i tasti fisici, luka (ma anche dc) richiede che si prema ogni volta ENTER per inserire un numero o una funzione. Anche alcuni nomi di funzioni sono diversi, così come i comandi per gestire lo stack o per salvare e recuperare le variabili. Ad esempio luka usa store e load per le variabili, mentre le calcolatrici fisiche o emulate usano dei tasti denominati in genere STO e RCL (ma se l’autore legge questo articolo forse cambierà idea 😂). Ma, a parte questi dettagli, la logica di fondo non cambia.

Da parte mia, ho provato in tutti i modi a far andare luka in crash, e non ci sono mai riuscito. Ho provato a fargli calcolare il fattoriale di numeri assurdamente grandi o piccoli, a dividere per zero, ad eseguire il famigerato $ 0 / 0 $ e poi a calcolare il reciproco del risultato. Ma niente, imperturbabile mi ha sempre dato il risultato esatto. Insomma, la qualità c’è.

Conclusioni

Provare luka non costa niente. Si installa (e disinstalla) in pochi secondi, funziona su macOS, Linux e, per chi vuole, anche su Windows. I risultati che produce sono esatti (e questa è la cosa che conta di più). Lo sviluppatore è bravo ed aperto ai suggerimenti. Insomma, è uno strumento ideale per chi vuole eseguire dei calcoli dal Terminale.

Certo, è uno strumento di nicchia, destinato a pochi utenti sofisticati che apprezzano la notazione RPN e non hanno paura del Terminale. Ma proprio per questo ha un fascino tutto suo.

E poi, vuoi mettere la bellezza di vedere un programma che evolve davanti ai nostri occhi, magari partecipando allo sviluppo con suggerimenti o critiche?

Ed uno dei pochi linguaggi di programmazione, assieme a FORTRAN e COBOL, ad essere ancora vivo e vegeto. ↩︎
Non a caso, uno dei linguaggi di programmazione più efficienti in assoluto è il FORTH, che si basa sullo stack e sull’uso dell’RPN. ↩︎
Come, non avete nemmeno make? Allora correte ad installare homebrew! ↩︎
Per quest’ultimo consiglio senza riserve PCalc Lite o meglio ancora la versione full Pcalc, che costa quanto un panino e una minerale al bar. In alternativa WP 34s, che riesce a compattare tutto in una sola schermata, oppure i41CX, perfetta per chi a suo tempo sognava di averla. ↩︎

macOS Tahoe: dov'è il Terminale?

Tue, 08 Jul 2025 06:00:00 +0000

– Immagine generata da Google Gemini.

Prendete macOS Tahoe, aggiornato alla versione 26.0 Developer Beta 2, e aprite il Terminale. Anzi non apritene solo uno, aprite due, tre, quattro Terminali diversi, ciascuno nel suo pannello. Più o meno così:

A questo punto ditemi: qual’è il Terminale attivo in questo momento?

Per rispondere dovrete aguzzare lo sguardo, e solo allora vi accorgerete che la barra del titolo del Terminale attivo è di un grigio appena appena più scuro degli altri, e che il titolo stesso è in grassetto.

Rifate lo stesso giochetto con Sequoia, o con qualunque versione precedente di macOS, e vedrete a colpo d’occhio qual’è il Terminale che state usando.

In realtà, un modo per distinguere il Terminale in uso esiste anche in Tahoe, ma è contro-intuitivo e richiede l’uso del mouse. Se si sposta il mouse sopra la barra del Terminale attivo non si vede nessun cambiamento,

mentre, quando si sposta mentre il mouse sopra il pannello di uno dei Terminali inattivi, lo sfondo diventa più scuro.

A tanti sembrerà un dettaglio trascurabile, ma il Terminale è uno strumento essenziale per interagire a basso livello con il sistema operativo e viene usato da gente che non possono permettersi di perdere tempo a cercare il Terminale giusto o, peggio ancora!, di rischiare di inserire un comando pericoloso nel Terminale sbagliato.

Per fare un esempio concreto: per gestire questo blog uso tre pannelli del Terminale, ciascuno dedicato ad un compito specifico. In uno di questi lavoro via ssh su un sito privato di test, che mi serve per verificare che tutto funzioni prima di caricare il blog sul vero server. Essendo un ambiente di prova, sono abituato a cancellare tutto con un brutale rm -r *. Oggi posso farlo senza problemi, perché so a colpo d’occhio e senza bisogno di leggere che sono nel Terminale giusto. Ma con Tahoe dovrò cambiare abitudini, perché eseguire lo stesso comando nel pannello sbagliato potrebbe avere conseguenze catastrofiche.¹

Fra tutte le incongruenze di macOS Tahoe, questa è forse è la più incomprensibile, e potenzialmente la più pericolosa.

A questo punto una domanda è d’obbligo: ma gli sviluppatori Apple usano davvero i prodotti che realizzano?

Certo, io per non fare errori prendo ulteriori precauzioni, come assegnare colori diversi ai vari Terminali. Ma il problema di fondo rimane. ↩︎

Quando iCloud non va...

Fri, 01 Mar 2024 06:00:00 +0000

– Fonte: Polina Kuzovkova su Unsplash.

Per chi usa il Mac, iCloud è lo strumento più semplice e naturale per sincronizzare i propri file con computer diversi (sì, anche se usano Windows o Linux) o con l’iPhone e l’iPad. Costa un pelo più dei concorrenti ma è studiato specificatamente per i prodotti Apple, funziona bene ed è veloce a sufficienza, non mi pare che ci sia partita.

Ma anche iCloud ogni tanto si incrocchia e rimane bloccato, senza più riuscire a completare la sincronizzazione.

– Tante grazie a kOoLiNuS per l’immagine!

La soluzione più immediata è riavviare il Mac, cosa che risolve quasi sempre il problema senza troppa fatica.

Ma riavviare il computer può essere seccante per chi ha sempre molte finestre aperte, oppure se ha l’abitudine di tenere sempre acceso il computer (come faccio io). In realtà riavviare non serve, basta solo interrompere il processo bird, che gira di continuo nel retrobottega del Mac.

Per farlo ci sono due modi diversi ma equivalenti:

selezionando il processo bird nella scheda CPU di Monitoraggio Attività (si trova in Applicazioni > Utility) e cliccando sull’icona di Stop (⊗) nella barra dell’applicazione;
aprendo il Terminale (anche questo si trova in Applicazioni > Utility) ed eseguendo il comando

killall bird

In entrambi i casi il processo verrà interrotto e fatto ripartire automaticamente, risolvendo (quasi sempre) il problema senza alcun bisogno di riavviare.

Apple abbiamo altri problemi: uno sguardo ai bachi d'epoca di macOS

Thu, 22 Feb 2024 06:00:00 +0000

– Immagine generata dall’IA di Microsoft Designer.

Nell’ultimo post ho descritto alcuni bachi freschissimi presenti in Sonoma, la versione più recente di macOS.

I bachi riportati qui, invece, si trascinano da svariate versioni di macOS e sembra che Apple non abbia nessuna voglia di sistemarli o che non li consideri dei veri e propri bachi. Questi problemi però, a differenza di altri report, non si verificano in condizioni estreme o dopo aver aperto un dazillione di file ma in normalissime condizioni d’uso, e quindi mi pare ancora più strano che non siano mai stati risolti.

I primi due sono più che altro incongruenze dell’interfaccia utente, molto sorprendenti se si considera l’attenzione quasi maniacale che Apple dedica ai minimi dettagli di design dei propri prodotti.

La barra di scorrimento (scrollbar) della lista delle applicazioni acquistate dall’App Store è parzialmente nascosta dal titolo della finestra e compare solo dopo aver scorso un certo numero di applicazioni (quante dipende dal numero totale di applicazioni presenti nella lista, se sono tante bisogna scendere parecchio per rivedere la barra).
La stessa cosa succede nella pagina iniziale dell’App Store quando si sposta il mouse nella parte superiore della finestra facendone comparire il titolo. Qui però gli elementi contenuti nella pagina sono pochi e quindi una parte della scrollbar rimane sempre visibile.

Questo invece è un vecchio baco relativo al Terminale.

Ho configurato le Impostazioni di Sistema > Scrivania e Dock in modo che l’opzione Preferisci pannelli quando apri i documenti sia sempre attiva. In questo modo, ogni volta che apro una nuova finestra nelle applicazioni che supportano questa funzione (fra cui il Terminale), macOS crea al suo posto un nuovo pannello all’interno della finestra già aperta.

Ma se sto usando il Terminale con una configurazione personalizzata (ad esempio la mia ha 120 colonne x 40 righe) e seleziono la voce di menu Nuova Finestra scegliendo un profilo che ha una dimensione diversa (ad esempio quella di default di 80 colonne x 24 righe), viene sì creato un nuovo pannello, ma tutto il Terminale cambia dimensione e assume quelle del profilo appena scelto.

In effetti questa potrebbe anche essere una scelta progettuale degli sviluppatori. Scelta che però contrasta con quello che succede quando l’opzione Preferisci pannelli quando apri i documenti è attiva solo a pieno schermo, perché qui il nuovo pannello assume invece la dimensione di quello di partenza.

Va detto che con High Sierra era perfino peggio: ogni volta che si apriva un nuovo pannello il Terminale perdeva una riga. Per fortuna questo baco è stato corretto nella versione successiva di macOS.

Questo baco, per me che uso sempre la modalità Allinea alla griglia nelle finestre del Finder e ordino le icone dei file in modo visuale seguendo un ordine logico (almeno per me) e lasciando spesso degli spazi vuoti, è una grandissima seccatura.

Fino a El Capitan, se spostavo le icone di una cartella al di sotto del bordo inferiore della finestra, il Finder non faceva una piega e manteneva l’ordine delle icone spostate, lasciando uno spazio vuoto dove queste si trovavano in origine. Da Sierra in poi, invece, il bordo inferiore della finestra del Finder è diventato una specie di barriera invalicabile, per cui la stessa operazione fa rimbalzare le icone che sarebbero finite sotto il bordo nella parte superiore della finestra, ora rimasta vuota.

Per evitarlo, bisogna trascinare le icone premendo contemporaneamente il tasto CMD (⌘), che in teoria serve per bypassare l’allineamento alla griglia, obbligando a ripristinare l’ordine delle icone in un secondo momento.

Questa chicca finale, quello che senza dubbio è il mio baco preferito di macOS, non è solo una seccatura ma, per dirla alla Camilleri, una grandissima rottura di cabasisi.

Proprio come per i documenti, io organizzo le applicazioni in modo visuale, raggruppandole in base alla tipologia e a quanto spesso le uso, e allinenando le icone alla griglia virtuale del Finder.

Di conseguenza, lascio in cima alla finestra Applicazioni tutte le applicazioni preinstallate di casa Apple e quelle che aggiungo io subito dopo la prima configurazione del sistema operativo, Pages, Numbers, Keynote, XCode, iMovie, GarageBand e così via. Subito sotto ci sono quelle da ufficio (la suite Office 365 e LibreOffice, gestori di PDF), quelle per la comunicazione (Teams, Webex, Skype), poi i browser e le applicazioni di sincronizzazione e accesso remoto. Ancora più giù le applicazioni più specifiche per il mio lavoro, per scrivere, prendere note e gestire gli articoli, editare le immagini, sviluppare codice. In fondo finiscono le utility varie per tenere sotto controllo la temperatura del Mac, gestire la clipboard, scompattare i file strani, registrare lo schermo e, ogni tanto, eseguire una scansione antivirus del Mac (MalwareBytes).¹

Con questa organizzazione ci metto un attimo a scorrere la cartella Applicazioni in cerca del programma che mi serve, perché so a priori dove dovrebbe essere anche se non ne ricordo il nome esatto.²

Purtroppo però, da non so più quante versioni di macOS, ogni volta che aggiorno macOS le icone delle applicazioni vengono sempre riordinate in modo alfabetico. Dato che per la cartella Applicazioni l’ordinamento alfabetico è quello di default, la maggior parte degli utenti non se ne accorge nemmeno. Ma chi, come me, preferisce un ordinamento personalizzato, è obbligato ogni volta a rimettere tutto a posto.

Perché considero questo un baco e non una caratteristica voluta di macOS? Il motivo è banale: se per ogni cartella il Finder mi consente di ordinare i file in modi diversi – alfabetico, per data, per dimensione, per tipo – e mi consente anche di allinearli su una griglia o non ordinarli affatto, non si capisce perché mai la cartella Applicazioni dovrebbe comportarsi in modo diverso.

Ci sono dei motivi tecnici alla base di questa decisione? Nell’uso normale la cartella Applicazioni può essere personalizzata esattamente come tutte le altre cartelle del Finder, quindi perché mai il Finder dovrebbe essere obbligato a resettare le personalizzazioni ad ogni aggiornamento, anche minore, del sistema operativo?

Secondo la mia modestissima opinione questo errore, insieme a quello descritto al punto precedente, è legato ad un problema con i fetentissimi file .DS_Store, che gestiscono la configurazione di ciascuna cartella nel Finder e il cui formato è tenuto più segreto di ciò che avviene dietro i cancelli dell’Area 51.

Se qualcuno del team di sviluppo di Apple sta leggendo queste righe, può trovare un’oretta per sistemare questi bachi? Non dovrebbe essere troppo difficile, dateci una occhiata per favore, un vostro fedele utente ve ne sarà grato.

La possibilità di organizzare le applicazioni e i documenti in modo visuale è una delle funzioni di macOS che me lo fa preferire a Linux o a, orrore!, a Windows, dove questo modo di lavorare semplicemente non esiste. ↩︎
Sul Mac di casa su cui sto scrivendo ho 148 applicazioni installate, e per le mie abitudini non sono nemmeno tante. Ricordare il nome di tutte non fa per me, infatti non ho mai usato l’ordinamento alfabetico né tanto meno applicazioni come Alfred e simili. ↩︎

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

MacBook Air M1 la non-recensione: Big Sur

Thu, 07 Apr 2022 06:00:00 +0000

Big Sur mi piace, ha portato una ventata di freschezza all’interfaccia grafica di macOS, un’interfaccia ormai familiare, ben assestata, rassicurante ma che, come le pareti di una casa abitata da tanti anni, attendeva con ansia una bella rinfrescata.

Big Sur

Dopo i fasti di Aqua, la prima interfaccia grafica di Mac OS X, tanto innovativa e dirompente con i canoni stilistici dell’epoca da dare un grosso contributo alla rinascita del Mac e dell’intera Apple, e dopo il passaggio al look grigio-metallico iniziato timidamente in Mac OS X 10.3/Panther e concluso con Mac OS X 10.5/Leopard, l’interfaccia grafica di macOS è sembrata stagnare per anni, un ritocchino qui e uno là, quasi sempre ispirato a iOS,¹ ma niente di più.

Con Big Sur Apple ha cambiato radicalmente il linguaggio grafico di macOS, e lo ha fatto già a partire dallo sfondo che abbandona le noiose fotografie naturalistiche per tornare ad una grafica astratta molto moderna, chiaramente ispirata ai grandiosi sfondi dei primi Mac OS X che hanno rallegrato i nostri occhi per tanti anni (il mio preferito è quello di Tiger). E non solo i nostri, perché anche i grafici che curavano le distribuzioni di Linux di quegli anni si sentivano quasi in dovere di trarre ispirazione dagli sfondi di Mac OS X (e lo fanno ancora oggi).

Come tutti i cambiamenti radicali, Big Sur presenta dei difetti e delle incongruenze, che sono stati descritti molto bene da Riccardo Mori nella sua serie di articoli su Big Sur. La sua non sarà una recensione dettagliata e tecnicamente ineccepibile come quelle, inarrivabili!, di John Siracusa, ma le si avvicina parecchio.

Alcuni di questi difetti sono piuttosto evidenti proprio sull’Air M1. Ma cominciamo da quello che sull’Air non si vede, grazie alla potenza del processore M1. Sui Mac Intel Big Sur sembra molto più pesante dei sistemi operativi precedenti, magari con un i7 o un i9 non ci facciamo troppo caso, ma se abbiamo solo un i5 o peggio un i3, il rallentamento è abbastanza evidente. Certo, dopo un aggiornamento del sistema operativo è normale che il Mac fatichi un po’, magari perché deve convertire il filesystem da HFS+ a APFS e di sicuro perché sta indicizzando il contenuto del disco rigido,² ma per chi è ancora fermo a Catalina o a Mojave questo è un aspetto da non sottovalutare.

Il Finder

Nell’elencare i difetti più evidenti di Big Sur sull’Air M1 mi voglio concentrare sul Finder che, anche per gli amanti del Terminale come il sottoscritto, rimane lo strumento principale per interagire con il Mac.

Io preferisco avere delle finestre del Finder piuttosto piccole, non solo perché così posso copiare o trascinare più facilmente file e cartelle da una finestra all’altra (per questo ci sono i pannelli e sono forse più comodi), ma soprattutto perché una finestra piccola mi permette di avere sempre in vista i file su cui lavoro, anche quando la maggior parte del desktop è occupata dal programma (o dai programmi) in uso.

Ma con Big Sur, ridurre le dimensioni delle finestre del Finder sull’Air M1 ha l’effetto collaterale di nascondere quasi tutte le icone della barra degli strumenti, dove rimane comunque un sacco di spazio vuoto che potrebbe essere utilizzato in modo più efficace.

Per confronto, ecco come ho configurato il mio Finder su Mojave, le icone della barra degli strumenti sono più piccole e tutte ben visibili e nel complesso mi sembra che il tutto sia molto più usabile.

La differenza sostanziale sta nel titolo della finestra, che nel Finder è il nome della cartella corrente. Fino a Catalina il titolo occupava uno spazio a sè stante in cima alla finestra, allineato ai bottoni colorati di chiusura/massimizzazione, mentre con Big Sur è stato integrato nella barra degli strumenti del Finder, rendendo necessario lasciare un po’ di spazio vuoto per mostrare tutto il nome della cartella. Ma anche così, quando questo supera la ventina di caratteri il Finder non ce la fa più a farlo vedere tutto e lo deve accorciare con dei puntini di sospensione, messi un po’ incongruamente alla fine del nome invece che nel mezzo, come siamo abituati a vedere da sempre nella finestra principale del Finder.

Ma come già detto, nel Finder di Big Sur c’è anche un sacco di spazio fra una icona e l’altra, come si può vedere meglio nell’immagine qui sotto dove l’area attiva dell’icona, cioè l’area sensibile al click del mouse, appare in un grigio leggermente più scuro circondata da una enorme area più chiara del tutto inutilizzata.

Se volessi vedere tutte le icone della barra degli strumenti dovrei allargare parecchio la finestra del Finder, una cosa che può non essere un problema su un monitor da 27", ma che diventa piuttosto seccante sul piccolo schermo dell’Air, perché significa occupare più della metà della larghezza del desktop. L’unico vero vantaggio di questa configurazione è la possibilità di passare con un click da una all’altra delle quattro modalità di visualizzazione dei file, una cosa che trovo molto comoda e di fatto irrinunciabile (ma dovrei ricordarmi una buona volta che ci sono le combinazioni di tasti ⌘1 - ⌘4 per fare la stessa cosa).

C’è da dire che anche le icone della barra dei menu hanno subito lo stesso trattamento della barra degli strumenti del Finder, apparendo molto più separate l’una dall’altra rispetto alle versioni precedenti di macOS. Usando poco l’Air M1 (che tecnicamente è di mia moglie, io ne curo solo la parte tecnica) non me ne accorgo, ma se avessi tante icone sulla barra dei menu, come è normale sui miei Mac, questa potrebbe diventare un’altra piccola seccatura.

C’è sempre un modo

Come succede spesso, il Terminale ci viene in aiuto, perché basta eseguire il comando

$ defaults write com.apple.finder NSWindowSupportsAutomaticInlineTitle -bool false

e riavviare il Finder (o meglio ancora fare logout e login nel proprio account) per ripristinare l’aspetto che la barra del Finder aveva nelle versioni di macOS precedenti a Big Sur.

Ora la finestra del Finder può assumere un aspetto più congruente con le piccole dimensioni dello schermo dell’Air, mostrando allo stesso tempo l’intera barra degli strumenti. Esteticamente non è un gran che – il titolo della finestra in grassetto e l’icona colorata alla sua sinistra stonano con tutto il resto – ma se risolve un problema può essere un buon compromesso. In ogni caso, il comando complementare

$ defaults write com.apple.finder NSWindowSupportsAutomaticInlineTitle -bool true

seguito dal riavvio del Finder (o dal logout/login) permette di ripristinare in ogni momento la situazione originale.

Per cambiare invece l’aspetto della barra degli strumenti in tutte le applicazioni di Big Sur e non solo nel Finder, il comando da eseguire diventa

$ defaults write -g NSWindowSupportsAutomaticInlineTitle -bool false

dove il parametro -g indica un cambiamento globale di configurazione. Anche in questo caso basta modificare il parametro finale in -bool true per ripristinare la situazione originale.

Se vogliamo invece riavvicinare le icone della barra dei menu, pare che non ci sia alternativa ad usare Bartender, un programma da 17 euro ma che fa tante altre cose, per cui potrebbe essere un buon modo per investire i propri soldi. Chissà se prima o poi qualcuno scoprirà un comando da Terminale per risolvere la questione.

Ma c’è dell’altro

Big Sur mostra parecchi altri piccoli difetti, non ne farò una lista dettagliata che sarebbe stucchevole. Mi voglio invece concentrare su quelli che considero dei veri e propri bug, niente di grave per fortuna, solo delle piccole incongruenze che spero che Apple corregga prima o poi.

Primo esempio sono queste finestre di dialogo, nelle quali non si capisce perché il testo di uno dei pulsanti è in rosso o perché due azioni tutto sommato molto simili (perché potenzialmente pericolose per i propri file) hanno delle selezioni di default diverse.

Ancora più inesplicabile è il motivo per cui i menu di Big Sur mostrano le abbreviazioni da tastiera nello stesso tono di grigio delle voci di menu non attive. È vero che ora i menu sono più puliti dal punto di vista grafico, ma non c’era una soluzione più soddisfacente di far pensare che le abbreviazioni siano state disattivate?

Conclusioni

La freschezza di Big Sur è innegabile, i piccoli difetti elencati qui sembrano più che altro dei difetti di gioventù, che saranno corretti man mano che la nuova interfaccia grafica si consolida. Quello che è altrettanto innegabile è la convergenza fra l’interfaccia utente di macOS e quella di iPadOS. Una tendenza che, se realizzata in maniera coerente, non può fare che bene, soprattutto ora che fra Universal Control, Sidecar, processori della stessa famiglia, diventa sempre più difficile dire dove finisce il Mac e dove inizia l’iPad.

C’è chi ipotizza che l’aver separato nettamente le icone della barra del menu e della barra degli strumenti delle applicazioni sia il preludio all’introduzione sui Mac di uno schermo sensibile al tocco. Non so se sia vero e non so nemmeno se possa servire, personalmente ho provato brevemente ad usare le dita per gestire Windows 10 su un Surface della Microsoft ed è una impresa praticamente impossibile. Per fortuna Apple sa fare molto meglio.

In ogni caso ci sarà da divertirsi.

Come le odiate barre di scorrimento nascoste o lo scroll naturale del mouse, che tanto naturale non è. Opinione personale, naturalmente. ↩︎
Un piccolo prezzo da pagare per avere delle ricerche istantanee o quasi. ↩︎

Come nascondere in modo sicuro le informazioni riservate di un file pdf

Sat, 07 Aug 2021 06:00:00 +0000

Ve la ricordate la figuraccia dell’esercito americano che aveva documentato i risultati dell’indagine sulla morte di Nicola Calipari con un PDF pieno di omissis ma che poteva essere letto integralmente con un semplice copia e incolla del testo? Beh, è successo anche a me: dovevo nascondere delle informazioni riservate da alcuni documenti richiesti dal Ministero e ho fatto lo stesso errore degli americani. Però poi ho imparato come si fa in modo corretto e lo racconto qui perché potrebbe essere utile ad altri lettori.

La burocrazia italiana è un mostro dalle mille teste e da un pezzo ho smesso di cercare di capirne le motivazioni. Questa però non è male: ogni volta che partecipo a un progetto di ricerca finanziato da un Ministero o da una Regione devo produrre i miei cedolini dello stipendio in formato PDF per tutti i mesi (o meglio anni) di durata del progetto.

Tutto ciò serve a dimostrare che il mio datore di lavoro è in regola con i contributi e con tutte le altre disposizioni di legge. Tutto bene in teoria, peccato che il mio datore di lavoro sia il CNR, un ente pubblico, che quindi deve per forza di cose essere in regola con queste disposizioni. Ma la burocrazia non guarda a questi dettagli, se c’è una norma va applicata ciecamente anche se è inutile (anzi, direi, preferibilmente se è inutile).

Ma al di là della seccatura di dover rispondere ad una richiesta chiaramente superflua, i cedolini contengono informazioni riservate che è bene nascondere: l’IBAN prima di tutto, ma poi anche l’eventuale quota sindacale, informazioni sulle tasse pagate o sui prestiti e benefici vari di cui si potrebbe usufruire, e chissà che altro che non so. Per parecchio tempo ho reso illeggibili queste informazioni utilizzando la funzione sfumino (smudge) di Pixelmator, come si può vedere qui sotto.

Usare lo sfumino però è noioso, soprattutto se si deve ripetere il processo su un gran numero di documenti diversi. E allora a un certo punto, ideona!, ho pensato bene di utilizzare Anteprima per inserire dei rettangoli neri sopra le porzioni di testo da nascondere, con il grosso vantaggio di poterli copiare ed incollare facilmente in tutti i documenti da mascherare.

Ma, proprio come nel rapporto Calipari, questo metodo consente di recuperare le informazioni riservate con un semplice copia e incolla, come potete verificare voi stessi con questo file.¹

Tutto ciò succede perché, a partire dalla versione 1.5, un file PDF può memorizzare le informazioni su più livelli diversi, più o meno come i file grafici di Photoshop (o simili). Nel caso specifico, i rettangoli aggiunti finiscono in un livello diverso da quello del cedolino originale e possono essere selezionati e modificati anche in un secondo momento con Anteprima o con Acrobat Reader.

Combinare i livelli di un file PDF è facile, basta usare il servizio “Salva come PDF…” raggiungibile dal menu File > Stampa… di Anteprima (o di qualunque altra applicazione per macOS). Questo servizio simula la stampa del file PDF originale, salvandolo invece in un nuovo documento PDF. Poiché una stampante non può gestire i livelli multipli del file originale, l’effetto finale è quello di fondere tutti i livelli in uno solo, rendendo il documento non più modificabile (come ci si può accorgere facilmente se si prova a selezionare i rettangoli neri di questo file dopo averlo stampato virtualmente come appena descritto).

Ho sempre pensato che tutto ciò bastasse a nascondere efficacemente le informazioni riservate, ma purtroppo non è così: anche se i rettangoli neri aggiunti al file PDF non possono essere più modificati, è ancora possibile selezionare e copiare il testo sottostante (provare con il file di sopra per credere).

Per fortuna il problema può essere risolto sia tramite il solito Anteprima che con il Terminale. Anteprima va benissimo se abbiamo a che fare con uno o due file PDF, mentre la potenza del Terminale viene fuori alla grande quando i file da gestire sono parecchi.

Metodo numero 1. Usare Anteprima è di gran lunga il modo più facile per nascondere in modo sicuro le informazioni riservate presenti in un file PDF, ma richiede due passaggi manuali e la creazione di un file intermedio che va poi buttato via, per cui è consigliabile solo a chi deve rendere sicuri solo pochi file PDF (oppure a chi ha molta pazienza).

Per procedere bisogna aprire con Anteprima il file PDF contenente le informazioni riservate ancora in chiaro e inserire i soliti rettangoli neri sopra le parti di testo da nascondere. Arrivati a questo punto si esporta il file PDF in un formato grafico, che può essere indifferentemente HEIC, PNG o TIFF (non JPEG, perché questo formato supporta solo documenti di una pagina). Basta ora aprire questo file grafico con Anteprima ed esportarlo di nuovo in PDF (o ancora meglio stamparlo virtualmente in PDF) per avere un file a prova di bomba, nel quale non è più possibile selezionare il testo del documento. Il file rimane sicuro anche se lo si sottopone ad un processo di riconoscimento ottico dei caratteri (OCR) con uno dei tanti software disponibili (io uso con soddisfazione una vecchia versione di PDFpenPro ma ce n’è davvero per tutti i gusti), che ora non può andare a leggere dietro le pecette nere.

Metodo numero 2. Ghostscript è probabilmente lo strumento software più diffuso per la gestione dei file PostScript e PDF dal Terminale, può fare cose complicatissime ma richiede un grosso sforzo per padroneggiarlo a dovere. Ghostscript non è presente di default in macOS ma può essere installato facilmente tramite Homebrew oppure installando MacTeX,² la distribuzione più diffusa di LaTeX per macOS.

Una volta che abbiamo Ghostscript sul Mac, possiamo usarlo per trasformare in un solo colpo il documento PDF da mascherare in un documento sicuro tramite questo comando da eseguire nel Terminale di macOS

$ gs -dPDF -dBATCH -dNOPAUSE -dNOSUBSTDEVICECOLORS -sDEVICE=pdfwrite \
-sOutputFile=documento_sicuro.pdf documento_da_mascherare.pdf

I nomi dei due file PDF presenti nell’ultima riga del comando sono autoesplicativi e vanno sostituiti con i nomi veri dei nostri documenti. Ricordo come al solito che il carattere $ indica il prompt del Terminale di macOS e non fa parte del comando vero e proprio.

Ghoscript funziona bene ma è un po’ lento e tante opzioni sono davvero oscure. Molto meglio secondo me utilizzare il prossimo metodo.

Metodo numero 3. Anche ImageMagick è un peso massimo fra gli strumenti da Terminale, specializzato nella creazione, modifica o conversione dei file grafici di praticamente qualunque formato ci venga in mente. ImageMagick mette a disposizione una marea sterminata di comandi e di opzioni fra i quali è facile perdersi, però la natura più moderna del programma lo rende più facile da usare, almeno al livello base che ci serve qui. Anche ImageMagick va installato sul Mac tramite Homebrew, e comunque richiede la presenza di Ghostscript per funzionare (che è poi il motivo principale per cui ho deciso di presentare anche il metodo numero 2).

Per convertire il documento PDF da mascherare in un documento sicuro con ImageMagick basta eseguire da Terminale il comando

$ magick convert -density 300 documento_da_mascherare.pdf documento_sicuro.pdf

eventualmente anche senza il comando iniziale magick

$ convert -density 300 documento_da_mascherare.pdf documento_sicuro.pdf

L’opzione density indica la risoluzione (in punti per pollice, dpi) del documento finale, 300 dpi vanno benissimo per i documenti stampati ma possono essere tranquillamente ridotti a 150 o anche 96 dpi se il file sicuro viene utilizzato solo sul computer (e quindi, come piace tanto dire ai nostri burocrati, è dematerializzato).

Come dicevo prima, l’utilità di usare il Terminale viene fuori soprattutto quando abbiamo un gran numero di file da rendere sicuri. Per farlo possiamo usare questo script in bash che va copiato nella cartella contenente i file PDF da processare (oppure in una cartella presente nel PATH) dandogli un nome significativo (io uso secure_pdf ma potete usare quello che preferite), lanciandolo da Terminale dopo averlo reso eseguibile con chmod (i dettagli di come si fa li trovate qui).

#!/bin/bash

OUTDIR="./secured"

if [[ ! -d $OUTDIR ]]; then
    mkdir "$OUTDIR"
fi
 
for f in *.pdf; do
    fout="$OUTDIR/$f"
    echo "Converting '$f' to '$fout'"
    convert -density 300 "$f" "$fout"
done

Lo script converte tutti i PDF che trova nella cartella dove viene eseguito, salvandoli in una nuova cartella secured con lo stesso nome del documento PDF originale. Se volete che i file sicuri abbiano un nome diversi e magari finiscano nella stessa cartella dei file originali, basta aggiungere o modificare un paio di righe ed è fatto.

#!/bin/bash

OUTDIR="."
SUFFIX="-SECURE"

if [[ ! -d $OUTDIR ]]; then
    mkdir "$OUTDIR"
fi
 
for f in *.pdf; do
    fname=`basename "$f" ".pdf"`
    fout="$OUTDIR/$fname $SUFFIX.pdf"
    echo "Converting '$f' to '$fout'"
    convert -density 300 "$f" "$fout"
done

Altri metodi. Naturalmente quelli elencato non sono gli unici metodi validi per rendere sicuro un PDF. Chi usa Acrobat Pro può fare tutto da questo programma utilizzando gli strumenti integrati di redazione del testo. Personalmente trovo inutile pagare 20 euro al mese per un editor di PDF (il migliore, è vero, ma sono sempre 240 euro all’anno), ma per chi ha già una licenza Adobe può essere l’opzione migliore.

Un’altra alternativa molto meno costosa è quella di usare uno strumento come il mai troppo apprezzato PDF Toolkit+, con il quale è possibile tramite interfaccia grafica esportare un documento PDF in vari formati grafici e a svariate risoluzioni, dove ogni pagina del PDF finisce in un file diverso, e rimontare poi le singole pagine in un unico file PDF. Niente che non si possa fare con Anteprima, ma qui abbiamo una maggiore flessibilità, ad esempio perché possiamo decidere di cambiare l’ordine delle pagine o di escluderne alcune dal documento finale. In ogni caso PDF Toolkit+ vale molto di più dei due caffè che costa, io ad esempio lo trovo perfetto per ridurre le dimensioni dei file PDF scannerizzati.

Direi che questi 5 metodi possano bastare, ma se qualche lettore ne conosce altri sarebbe bello se li descrivesse nei commenti.

Non sperate di trovare il mio IBAN, è solo la versione in PDF della prima pagina di questo post. ↩︎
Qualcuno potrà chiedersi che senso abbia installare i quasi 5 GB di MacTeX solo per avere Ghostscript. Vista così può davvero sembrare una cosa insensata, ma il valore aggiunto di avere LaTeX sul Mac è, a mio avviso, inestimabile. ↩︎

Come riconoscere di nuovo la tastiera del Mac

Mon, 18 Jan 2021 06:00:00 +0000

Ne succedono di cose strane! La settimana scorsa ho voluto provare sul mio Mac principale la tastiera HP Pavilion 400, che mi sembrava interessante come tastiera di scorta per i tanti ammennicoli che ormai affollano la mia scrivania di casa, che è ormai anche la mia scrivania principale di lavoro (prima o poi ne parlerò più diffusamente).

La tastiera però l’ho tenuta pochissimo: va bene spendere poco, ma i tasti erano troppo leggeri e instabili per i miei gusti, mentre il mouse che arriva insieme alla tastiera è semplicemente tremendo, se dovessi fare una classifica dei peggiori mouse che ho avuto per le mani, questo occuperebbe di sicuro uno degli ultimi posti. In più, nonostante il layout della tastiera fosse italiano, il tasto corrispondente alla barra rovesciata e alla pipe (cioè \ e |) era scambiato con quello con i simboli di maggiore e minore, finendo così per trovarsi in basso fra la Maiuscola sinistra e la z invece che, come sarebbe normale, in alto e alla sinistra dell’1.

Io non sono un bravo dattilografo (come si dice in italiano touch typist?), ma una certa memoria muscolare ce l’ho, e poi questi tasti sono fondamentali quando uso il Terminale o programmo in R. Per cui dopo pochi minuti ho scollegato senza rimpianti la tastiera HP e sono tornato alla mia solita Logitech con tutti i tasti al posto giusto.

Purtroppo, per qualche motivo che mi sfugge, la configurazione della tastiera sul Mac aveva conservato la memoria dei due tasti scambiati: ogni volta che premevo il tasto < veniva fuori la barra rovesciata (poco male, visto che in pratica serve solo su Windows). Purtroppo però per inserire un backtick (cioè il simbolo `), dovevo premere ALT + < invece che ALT + \, come sarebbe normale. Sembra un problema da poco, ma il backtick lo uso spesso quando scrivo in Markdown (e non solo), ad esempio solo in questo articolo ho inserito finora una ventina di backtick.

La prima cosa che ho fatto per tornare al layout giusto è stata, lo ammetto, piuttosto contorta. Sono andato nelle Preferenze di Sistema del Mac, ho aperto l’impostazione della Tastiera e ho aggiunto la tastiera USA alle Sorgenti di input, in modo da poter rimuovere la tastiera italiana (ho dovuto fare così perché il sistema operativo richiede che ci sia almeno una tastiera, ooops! una sorgente di input, sempre attiva). Subito dopo ho riattivato la tastiera italiana e rimosso quella USA.

Ma non è successo niente, i tasti continuavano ad essere scambiati. Ho anche provato a rifare lo stesso giochetto riavviando il Mac prima di attivare di nuovo la tastiera italiana. Niente.

In fondo tutto quello che volevo era far comparire il solito Assistente di configurazione della tastiera, che chiede di identificare la tastiera premendo il tasto a destra della Maiuscola sinistra. Ma come?

Solo dopo il riavvio mi sono accorto che nelle impostazioni della Tastiera delle Preferenze di Sistema era (ri)comparso il pulsante Modifica tipo di tastiera..., che serve proprio ad eseguire l’Assistente di configurazione della tastiera. E con quello è andato tutto subito a posto.

Il problema è che questo pulsante sembra un po’ ballerino, a volte appare e a volte scompare dalle impostazioni della Tastiera, senza che si riesca bene a capire il perché. Ad esempio, come si può vedere qui sotto, su un altro Mac in questo momento il pulsante non c’è (qui è installato High Sierra, ma da quanto ho capito non è una questione di sistema operativo).

E anche quando il pulsante c’è, non è detto che premendolo compaia l’Assistente. Non mi chiedete il perché, sarà uno di quei piccoli bachi che si trascinano da una versione di macOS all’altra.

Per fortuna esiste una soluzione relativamente semplice per forzare macOS ad eseguire l’Assistente di configurazione della tastiera. Basta andare sul disco dove è installato macOS, cliccare su Libreria e poi su Preferenze, cancellare il file com.apple.keyboardtype.plist e riavviare. Una volta rientrati nel proprio account l’Assistente desiderato comparirà automaticamente. È un po’ tortuoso e purtroppo richiede il riavvio del computer, ma funziona sempre.

Da Terminale è perfino più facile. Basta eseguire il comando

$ sudo rm /Library/Preferences/com.apple.keyboardtype.plist

inserire la propria password e riavviare il Mac. Per farlo bisogna usare un account con privilegi di amministratore del sistema, ma se il Mac, come succede spesso, ha un unico account, questo è necessariamente un account di tipo amministrativo.

Il CNR è anche questo: un po' di codice

Tue, 01 Dec 2020 06:00:00 +0000

XKCD, Good code.

Per concludere nel miglior modo possibile questa serie di articoli (qui la prima e la seconda parte), cosa ci può essere di meglio di un po’ di codice?

Estrarre il testo da un file PDF

Cominciamo dallo script in R, pdf2csv.R, che estrae il testo da un file PDF, (che in questo caso specifico ho usato per estrarre i dati dalla domanda di partecipazione ad un concorso precedente). Qui sotto trovate l’immagine dello script, realizzata con Carbon (perché così è molto più bello), su GitHub c’è il sorgente vero e proprio, per chi voglia provare ad usarlo.

Per eseguire lo script è necessario aver installato sul proprio computer, non importa se è un Mac o un PC con Linux o Windows, l’ambiente R (in questo momento è disponibile la versione 4.0.3), meglio ancora se accompagnato da RStudio Desktop, che è di gran lunga il migliore sistema integrato di sviluppo (IDE) che abbia mai usato, oltre che uno strumento efficacissimo per affacciarsi all’uso di R.

Il codice è molto semplificato, ho tolto tutto ciò che non è strettamente necessario a far funzionare lo script. La chiave di tutto è la libreria pdftools per R. Di librerie per estrarre dati dai file PDF ne ho provate moltissime, sia per R che per Python, ma pdftools le batte tutte per potenza, semplicità e velocità. Ci sono dei tool che convertono un PDF in testo al ritmo di una pagina al minuto, pdftools riesce a convertire (molto bene, peraltro) un file di 400 pagine come questo in appena 5-6 secondi. C’è altro da aggiungere?

Lo script può essere utilizzato dalla linea di comando (per capirci, dal Terminale), lasciandolo esattamente com’è ed eseguendo il comando pdf2csv.R seguito dal nome dal file da convertire (se il nome del file contiene degli spazi va scritto fra virgolette),

	./pdf2csv.R file-da-convertire.pdf

che produrrà due file .csv contenenti il testo estratto dal file PDF. Il primo, con lo stesso nome del file di partenza, ha le righe numerate e cerca di riprodurre per quanto è possibile il layout del file originale. Nel secondo, salvato con il suffisso -clean, mancano i numeri di linea e vengono rimossi tutti gli spazi in eccesso, rendendolo più adatto ad una analisi automatica, in particolare quando il testo si estende per tutta la pagina (il primo file, invece, è molto più utile quando il testo è organizzato in colonne).

Prima di usare per la prima volta pdf2csv.R bisogna renderlo eseguibile tramite il comando chmod (ne ho già scritto diffusamente qui).

	chmod u+x pdf2csv.R

In alternativa si può lanciare lo script tramite il comando Rscript installato con R, senza che sia necessario renderlo eseguibile.

	Rscript ./pdf2csv.R file-da-convertire.pdf

È preferibile che il file PDF da convertire si trovi nella stessa cartella di pdf2csv.R. In caso contrario il testo estratto viene comunque salvato nella cartella dove si trova la script (ve l’avevo detto che lo script era molto semplificato!).

Per eseguire pdf2csv.R all’interno di RStudio bisogna commentare la linea 12 (basta aggiungere un # all’inizio della riga) e attivare la riga 14 o 15 (ma solo da una delle due) togliendo il # iniziale. Se si attiva la riga 14, si deve anche modificare la stringa file-da-convertire.pdf, sostituendola con il nome del file da convertire. Se invece si attiva la riga numero 15, al momento dell’esecuzione dello script comparirà una finestra grafica da cui selezionare il file PDF desiderato.

Nel repository su GitHub di questo articolo ho inserito dei file PDF di complessità crescente con cui fare qualche prova, fra cui un documento di quasi 1000 pagine (un vecchio manuale di riferimento del formato PDF, potevo scegliere qualcosa di diverso?), che può essere utile per valutare la velocità di conversione dello script. Non è necessario farlo a mano, il tempo di esecuzione di un qualunque programma o script si può misurare in modo preciso dal Terminale anteponendo il comando di sistema time, come mostrato qui sotto.¹

	time ./pdf2csv.R PDFReference.pdf

Come piccola chicca finale, ho aggiunto al repository su GitHub un file PDF contenente del testo (apparentemente) nascosto, provate a convertirlo e vi accorgerete di quanto sia banale recuperare il testo completo.

Generare automaticamente dei documenti con AWK

Tirar fuori il testo contenuto in un file PDF è quasi sempre solo il primo passo del lavoro, perché quello che vogliamo veramente è filtrare il contenuto del documento mantenendo solo le informazioni che ci interessano. Nel caso specifico, io avevo bisogno di selezionare dalla domanda di concorso precedente solo i dati relativi ad una specifica tipologia di attività (ad esempio tutti gli articoli scientifici pubblicati), salvandoli in un file ad hoc. E, già che c’ero, volevo anche costruire una tabella LaTeX per ciascun articolo. Una cosa abbastanza facile da fare con AWK.

Di AWK ho già parlato tempo fa e non mi ripeterò, dirò solo che è un linguaggio ideale per analizzare un file di testo una riga alla volta, verificando se si presentano determinate condizioni ed eseguendo le operazioni programmate corrispondenti.

Nonostante i suoi tanti pregi, AWK ha una limitazione piuttosto seria: per come è strutturato, AWK deve per forza di cose esaminare tutto il file senza poter tornare indietro, e quindi è piuttosto difficile fargli eseguire delle operazioni basate su condizioni multiple complesse. È molto meglio (quando è possibile) scrivere più script AWK, da eseguire in sequenza sullo stesso file di partenza o sull’output generato dallo script precedente, piuttosto che cercare di combattere con le limitazioni del linguaggio, complicando a dismisura il codice.

In una prima versione di questo articolo avevo pensato di utilizzare un breve estratto della mia domanda di concorso precedente per descrivere il funzionamento degli script in AWK. Ma mentre scrivevo mi sono accorto che il discorso sarebbe stato così specifico da essere quasi inutile. Ho preferito quindi preparare un piccolo file PDF tratto dagli ultimi post pubblicati su Melabit, con l’intestazione in YAML² di ciascun post seguita dalla prima frase del testo in Markdown e, quando c’è, dal link all’immagine iniziale. L’ho scelto perché la struttura di questo file assomiglia moltissimo a quella della mia domanda di concorso ma, allo stesso tempo, può essere uno schema di partenza applicabile a casi più generali.

Questo file PDF può essere considerato come la stampa di un piccolo _database_ di informazioni correlate, dove ogni post è un _record_, suddiviso a sua volta nei vari _campi_, rappresentati dalle righe di intestazione e dalla frase di testo.

Il file PDF si chiama Melabit ultimi post.pdf e, come gli altri file PDF, è disponibile nel repository su GitHub di questo articolo. Se lo aprite con Anteprima, noterete subito che ci sono delle righe vuote che separano chiaramente un post (nel linguaggio dei database, un record) dall’altro. Ma convertendo il file in testo,

	./pdf2csv.R "Melabit ultimi post.pdf"

(le virgolette sono necessarie perché il nome del file contiene degli spazi), le righe vuote scompaiono e le uniche interruzioni presenti nei due file CSV prodotti dallo script di conversione corrispondono al cambio pagina. Non so se questo sia un baco o una caratteristica voluta di pdftools, ma sta di fatto che è una particolarità con la quale dobbiamo fare i conti se vogliamo analizzare il testo con AWK.

Sembra una sciocchezza, ma senza le giuste interruzioni non è immediato riconoscere la fine di un record prima di iniziare ad esaminare quello successivo, in modo da chiudere correttamente la tabella LaTeX corrispondente al record appena esaminato e ad aprire quella relativa al record successivo. Inoltre, mentre in questo caso specifico la struttura del file PDF è volutamente molto semplice e ripetibile, nella maggior parte dei casi reali il documento da cui estrarre i dati può contenere informazioni strutturate in modi diversi, i campi da analizzare possono essere distribuiti in modo irregolare o mancare del tutto e ci possono essere incongruenze nella loro denominazione. Gestire tutti i casi possibili con un unico script lo renderebbe rapidamente troppo complesso.

Molto meglio affrontare il problema un pezzetto alla volta, utilizzando uno script specifico per ciascun tipo di informazione da estrarre (io ho avuto bisogno di 6 script AWK per eseguire tutto il lavoro di esportazione dei dati, o meglio quasi tutto il lavoro, perché per i casi meno frequenti ho preferito il buon vecchio copia-incolla manuale). In fondo è la stessa logica di Unix, che mette a disposizione un gran numero di strumenti semplici che messi insieme, come tanti mattoncini Lego, riescono a fare cose incredibili.

Un primo script, addblanklines.awk, può servire per inserire nel file CSV di partenza una riga vuota prima di ogni record (una cosa piuttosto semplice da fare in questo caso, dato che ogni post inizia sempre con la stringa “layout: post”). Lo script, appena quindici linee di codice, lo trovate “in bella” nell’immagine qui sotto (ma anche in questo caso il sorgente è su GitHub).

Bastano solo due linee di codice, la #4 e la #9, per aggiungere le righe vuote al posto giusto. Ma già che ci siamo, è conveniente dare anche una ripulita al file CSV togliendo le righe inutili, come quelle che contengono il numero di pagina o la stringa --- che segna l’inizio e la fine dell’intestazione in YAML (linee #5 e #12). Eseguendo lo script sul file CSV originale, si ottiene un nuovo file CSV con i vari record ben separati uno dall’altro.

	./addblanklines.awk "Melabit ultimi post-clean.csv" > file-con-righe-vuote.csv

Fatto questo, il passo successivo è semplice. Basta scansionare il file CSV appena generato, file-con-righe-vuote.csv, in cerca della stringa target layout: post e, ogni volta che se ne trova una, generare una nuova tabella LaTeX riempiendola con i dati tratti dalle voci (o più propriamente campi) successive. Il codice del secondo script, cvs2table.awk, è visibile nell’immagine qui sotto (mentre il sorgente è sempre su GitHub).

Lo script è relativamente lungo, sono più di 80 linee di codice, compresi commenti e righe vuote, ma una gran parte serve per implementare la funzione (linee #3-25) che riarrangia le informazioni presenti su più linee consecutive del file CSV in modo che vengano stampate su un’unica riga, e per generare la struttura di base del documento LaTeX (linee #35-42 e #83).

Tolte queste, il resto del codice è semplice, si tratta più che altro di scrivere le stringe giuste al momento giusto e di tenere conto dei casi in cui le informazioni si estendono su più linee consecutive (come succede ad esempio alle linee #61-62 e #66-73). Non entrerò nei dettagli di come funziona lo script, questo non è un corso di AWK (né tantomeno di R), basterà per ora dire che è scritto in modo da essere facilmente adattato a gestire esigenze analoghe. Per usarlo, si deve eseguire lo script usando come file di input file-con-righe-vuote.csv e salvando il risultato dell’elaborazione in un file LaTeX, che qui sotto ho chiamato (con la mia solita scarsa fantasia) lista-articoli.tex.

	./cvs2table.awk file-con-righe-vuote.csv > lista-articoli.tex

Mettere tutto insieme

Proviamo allora ad eseguire tutti insieme gli script presentati in questo articolo, in modo da ottenere il risultato finale desiderato. Dobbiamo prima di tutto convertire il file PDF in CSV con

	./pdf2csv.R "Melabit ultimi post.pdf"

che genera automaticamente il file “Melabit ultimi post-clean.csv”. Fatto questo, si eseguono in sequenza i due script AWK, salvando l’output del primo in un file intermedio.

	./addblanklines.awk "Melabit ultimi post-clean.csv" > file-con-righe-vuote.csv
	./cvs2table.awk file-con-righe-vuote.csv > lista-articoli.tex

Il risultato finale è un file LaTeX ben ordinato con una tabella per ogni articolo, come quello mostrato nella figura qui sotto la cui regolarità, messa in evidenza dai colori delle parole chiave, fa pensare ad uno spartito musicale.

Ma ha senso creare un file intermedio solo per trasferire l’output del primo script al secondo? Molto meglio usare il meccanismo di piping tipico in Unix, con il quale si può trasferire automaticamente il risultato dell’esecuzione di un comando all’ingresso di quello successivo, collegandoli con il carattere | (pipe)?³ Con il piping, i due comandi AWK precedenti possono essere eseguiti uno dopo l’altro in questo modo,

	./addblanklines.awk "Melabit ultimi post-clean.csv" | ./cvs2table.awk > lista-articoli.tex

evitando l’uso di un file intermedio. In questo caso non fa molta differenza, ma quando si devono trattare file molto grossi, il piping è molto più efficiente (con i velocissimi dischi SSD odierni non ce ne accorgiamo più, ma ai tempi dei dischi meccanici la scrittura di grossi file sul disco era un vero collo di bottiglia) e, cosa che non guasta mai, evita di intasare il disco rigido con un gran numero di file inutili.

E poi il piping è un meccanismo intrinsecamente elegante, che non a caso è stato adottato anche in alcuni linguaggi di programmazione odierni, come si può vedere nello script R mostrato nella prima parte di questo articolo (linee #24-25 e #35-37), dove il simbolo | usato in Unix è sostituito dalla strana combinazione di caratteri %>%, piuttosto fastidiosa da scrivere con una tastiera italiana (io almeno sbaglio sempre qualcosa).

Conclusioni

Chi ha l’occhio allenato si accorgerà facilmente che il file LaTeX risultante contiene alcuni errori piuttosto evidenti. Li ho lasciati apposta non solo per non complicare ulteriormente il codice, ma anche per mostrare quanto sia complicato il lavoro di estrazione automatica dei dati da file strutturati in modo non perfettamente regolare. Non è certo un caso che in questo campo ci sia una grossa attività di ricerca che prova a superare gli ostacoli e a rendere il tutto il più semplice e il più efficiente possibile.

Il comando time è presente di default nei sistemi operativi Unix come Linux e macOS. Su Windows time non esiste, ma si possono usare degli strumenti equivalenti. ↩︎
YAML è un linguaggio di markup particolarmente adatto per definire dei file di configurazione e, in generale, per rappresentare informazioni strutturate in modo semplice e leggibile, molto più facile da usare di strumenti più noti come XML e JSON. ↩︎
Il piping è uno dei meccanismi principali che rendono Unix una specie di Lego informatico. ↩︎

Il CNR è anche questo: concorsi in LaTeX

Sun, 08 Nov 2020 06:00:00 +0000

Nella puntata precedente ho raccontato della mia corsa contro il tempo dell’estate, una prova assurda come quelle di Giochi senza frontiere, ma senza allegria.

Inutile però dilungarsi ancora in dettagli poco comprensibili ai non addetti ai lavori. Meglio parlare invece di cosa ho fatto io per superare questa prova, cercando di sfruttare quel poco che so di LaTeX e di programmazione.

Perché, l’ho già detto ma mi ripeto, qualche nozione di programmazione può aiutare a cavarsela meglio con le tante rotture di cabasisi che dobbiamo affrontare ogni giorno.

Se c’è una cosa sulla quale sin dal primo momento non ho avuto il minimo dubbio, è che non avrei usato Word per preparare il curriculum professionale. Word non mi piace, si sa, ma in questa scelta non c’era nessuna prevenzione, era solo un modo per preservare la mia salute mentale.

Word ha grosse difficoltà a gestire strutture complesse come le tabelle. Una, due, tre, dieci tabelle vanno ancora bene, ma qui si trattava di creare centinaia e centinaia di tabelle diverse, una per ogni titolo – articolo, progetto, software, brevetto, insegnamento, incarico – inserito nel curriculum professionale. Dopo un po’ Word sarebbe letteralmente impazzito nel maneggiare tutte quelle tabelle, facendomi perdere un sacco di tempo prezioso.

Con LaTeX il problema non si pone. Un documento LaTeX è un normale file di testo e il fatto che contenga tabelle, liste o semplici paragrafi non fa molta differenza, sono solo delle porzioni di testo strutturate in modo diverso. Il peggio che può capitare è che il compilatore LaTeX impieghi qualche secondo in più a convertire il documento LaTeX in PDF.

Il fatto che i documenti LaTeX siano dei file di testo mi permetteva anche di generare automaticamente le tabelle relative a ciascun titolo inserito nel curriculum professionale, una cosa impossibile da fare con Word e che ha velocizzato moltissimo tutto il lavoro.

Già perché, non l’ho detto prima, il curriculum professionale andava sì scritto in Word, ma poi la sottomissione andava fatta in PDF,¹ utilizzando (ci credete?) la piattaforma online per i concorsi dismessa così improvvidamente. In pratica il modello in Word fornito dall’amministrazione serviva solo come indicazione di massima di come dovesse essere organizzato il curriculum, ma niente impediva di utilizzare altri strumenti. L’unica cosa davvero importante è che il layout del file PDF corrispondesse a quello previsto dall’amministrazione.

Riprodurre in LaTeX il modello originale in Word non è stato difficile: la classe memoir è molto flessibile ed è particolarmente adatta a produrre tutti quei documenti che escono dai canoni classici di LaTeX, mentre i package geometry, booktabs, multirow e titlesec permettono di regolare finemente i dettagli del documento finale.

Sia chiaro, preparare un modello di documento LaTeX partendo da zero non è mai facile, a meno di non essere dei veri esperti. Per fortuna avevo già fatto delle cose simili in passato e mi è bastato modificare qualche dettaglio per ottenere quello che mi serviva.²

Il modello LaTeX era però il problema minore, ciò che importava davvero era riuscire a riutilizzare il più possibile il lavoro fatto in passato. Come già detto nel post precedente, i soloni che ci governano non avevano previsto nessuna possibilità di esportare i dati già presenti sulla piattaforma online. L’unica possibilità era quella di partire dal curriculum in PDF preparato per un concorso precedente (del 2013, ben sette anni fa).

Per fortuna ho una certa esperienza nell’estrazione di dati dai documenti PDF, un problema molto attuale dato che tante istituzioni, non solo nazionali ma anche internazionali, sono molto restie a condividere i loro dati in formati standard utilizzabili da chi, come me, si occupa di estrarre informazioni dalle serie temporali di misure. Quando va bene il meglio che si riesce ad ottenere sono dei file PDF contenenti delle tabelle mal strutturate, che bisogna ingegnarsi a convertire in formati usabili per le analisi. Mi è bastato quindi adattare uno script in R sviluppato per altri scopi per riuscire a convertire la domanda in PDF in un file CSV ben ordinato.

Partendo dal file CSV e con qualche semplice script in AWK (un’altro tool di base di cui non potrei mai fare a meno) è stato quasi un gioco da ragazzi estrarre i dati relativi ai titoli già presentati in quel concorso, salvandoli in file differenti in base alla tipologia in modo che poi fosse più semplice aggiungere uno ad uno i titoli mancanti (dal 2013 ad oggi ce ne sono state di novità!). Il modello LaTeX si occupava poi di importare questi file nella sequenza corretta producendo il curriculum completo.

Già che c’ero, con gli stessi script potevo anche costruire automaticamente le tabelle LaTeX dove incasellare ciascun titolo. È una cosa più difficile da spiegare che da fare, ma che ha rappresentato un vantaggio incomparabile rispetto a creare le tabelle una ad una con Word.

Devo ammettere che gli script AWK non erano perfetti, purtroppo me ne sono accorto solo dopo aver iniziato il lavoro di inserimento dei nuovi titoli. Ma dato che questi script mi servivano solo una volta, ho preferito correggere a mano gli errori piuttosto che perdere altro tempo a perfezionarli.

Lavorare con file diversi per ciascuna tipologia (o fattispecie, il termine preferito dai nostri vertici amministrativi) aveva un altro grosso vantaggio. Avendo separato il modello LaTeX, che gestiva l’aspetto generale del curriculum professionale, dai dati riportati nei diversi file, potevo velocizzare parecchio la fase di (diciamo così) debugging del documento finale. In altre parole, se lavoravo sugli articoli scientifici scritti nel corso della mia carriera, potevo importare nel modello generale LaTeX solo il file relativo, lasciando fuori tutto ciò che riguardava le altre attività svolte. Analogamente per le altre tipologie di documenti. Sembra una cosa da niente, ma quando si passano le giornate ad inserire i dati di decine di nuovi documenti, avere a disposizione un file PDF più snello e poter controllare più rapidamente di non aver fatto errori e di non aver dimenticato niente può davvero fare la differenza.

Un altro aspetto chiave dell’usare LaTeX al posto di Word è stato il fatto di poter numerare a piacere le singole tabelle. Su questo la confusione era massima. Il principio generale era chiaro, i vari titoli delle Categorie A e B andavano inseriti rispettando un ordine temporale inverso, dal più recente al più vecchio, assegnando un numero progressivo a ciascuna tabella. Quello che non era affatto chiaro era il come.

Modello di curriculum professionale: titoli della Categoria A.

Modello di curriculum professionale: titoli della Categoria B.

C’era chi affermava che si dovessero numerare progressivamente i documenti della Categoria A, gli ormai famosi Prodotti della Ricerca, indipendentemente dalla loro tipologia ma tendendo conto solo della data, ricominciando la numerazione dal principio una volta passati ai titoli della Categoria B, dove invece i titoli andavano raggruppati in base alla tipologia. Altri pensavano che fosse preferibile raggruppare tutti i titoli della Categoria A per tipologia (prima tutti gli articoli, poi i capitoli di libri e gli atti di congressi, poi i brevetti, e così via), ordinandoli dal più recente al più vecchio e numerandoli progressivamente, continuando la numerazione con gli stessi criteri una volta passati alla Categoria B. Altri volevano numerare anche le tipologie, un po’ come si fa con i capitoli di un libro tecnico. Insomma, ogni partecipante al concorso aveva la sua idea.

Come ha scritto qualcuno in un gruppo WhatsApp, “le migliori menti del Paese non riuscivano a interpretare le istruzioni del bando di concorso”. Non so se al CNR ci siano davvero le migliori menti del Paese, ma è evidente che tutta questa confusione derivava dalla difficoltà di interpretare un gergo burocratico astruso e inconsistente, incomprensibile per chi è abituato per professione ad essere preciso e rigoroso. A ciò si aggiungeva un motivo più banale, il timore di fare degli errori nella stesura del curriculum e di essere penalizzati per questo dalle commissioni di valutazione.

Io non avevo scelta. Avendo raggruppato tutti i miei titoli in file differenti in base alla tipologia e importando i file uno dopo l’altro nel modello generale LaTeX, non potevo fare altro che numerare tutti i titoli della stessa tipologia in base alla data (dal più recente al più vecchio), proseguendo la numerazione una volta passato ad un’altra tipologia e continuando a numerare progressivamente allo stesso modo anche i titoli della Categoria B.

Mi sembrava anche la cosa più logica da fare, perché questo ordinamento facilitava il lavoro della commissione, che così trovava raggruppati prima tutti gli articoli scientifici (che sono senza ombra di dubbio i titoli più importanti per un ricercatore), poi tutti i capitoli di libri o gli atti di congresso, poi i brevetti, e così via. Se l’ordinamento primario per tipologia era previsto esplicitamente per la Categoria B, perché non fare lo stesso anche per la Categoria A? Se poi alla commissione non piacerà, pazienza!

Inutile dire che ho usato git – il sistema di controllo delle versioni che è ormai uno standard di fatto nel mondo dello sviluppo – per gestire le revisioni di tutti i file che mi servivano per produrre il curriculum professionale finale: il modello generale in LaTeX, gli script in R e AWK e tutti i file CSV e LaTeX generati dagli script.

Con il sistema di controllo delle versioni potevo aggiornare i vari file LaTeX dei titoli sapendo di poter tornare indietro anche in caso di errori troppo gravi per essere recuperati a colpi di undo. Per fare un esempio, a un certo punto mi sono accorto che avrei dovuto scambiare due righe in tutte le tabelle del file relativo agli articoli (si veda la figura qui sotto). Con un buon editor di testo è una cosa che si fa in cinque minuti, ma sapere di poter usare git anche per annullare ogni singola modifica è una cosa che si apprezza solo dopo essersi spupazzati una ad una un migliaio di righe di codice LaTeX.

Interfaccia grafica di git con la quale è possibile accettare o annullare ogni singola modifica ad un file.

Git è troppo complicato? Può darsi, ma un sistema di controllo delle versioni è come un backup, finché va tutto bene non si capisce a cosa serva, ma quando si presenta un problema si ringrazia il cielo di averlo usato.

Guardando a ritroso mi accorgo che la preparazione di questo curriculum professionale è stata in parte un lavoro di programmazione, tutto sommato abbastanza divertente, seguita da una lunga e noiosissima fase di inserimento dei nuovi dati e di controllo che tutto fosse a posto, una cosa che sembrava non dovesse finire mai. Lavorando una decina di ore al giorno ho impiegato quasi un mese per completare il lavoro, un pelo in anticipo rispetto alla scadenza prevista. Uno spreco di tempo assurdo per quello che dovrebbe essere un evento normalissimo nella vita professionale di chi fa questo mestiere.

La versione finale del mio curriculum ha 248 pagine, un numero che per un matematico (o un programmatore) ha un certo significato.³ Chissà se la commissione che lo giudicherà sarà dello stesso avviso.

(Continua…)

Una cosa più che ragionevole, visto che un file PDF è molto più difficile da manipolare del corrispettivo in Word. ↩︎
Detto fra parentesi, se c’è interesse per l’argomento, potrei scrivere dei post specifici su LaTeX e dintorni, toccando non solo le basi ma anche argomenti più avanzati come questo. ↩︎
Ammetto che arrivare a 271 o a 314 pagine sarebbe stato meglio, ma ci proverò la prossima volta. ↩︎

Spotlight e il riquadro fastidioso

Mon, 09 Mar 2020 06:00:00 +0000

– Fonte: sony kusuma estri su Unsplash.

Non so voi, ma a me ogni tanto succede che qualche scritta spuria rimanga come appiccicata sullo schermo del Mac. Capita soprattutto con l’anteprima del nome completo di un file, il pop-up che compare spostando il mouse sul nome di un file senza fare click.¹

In genere Il pop-up scompare appena si muove il mouse. Ma qualche volta, chissà perché, rimane come incollato sullo schermo sovrapponendosi alle altre finestre, e non c’è verso di farlo andare via. La strategia più efficace per rimuoverlo è quella di uscire e rientrare nell’account, che è una vera seccatura quando si hanno parecchie applicazioni aperte.

Un riquadro fastidioso

Ieri ne è successa una nuova su un Mac con High Sierra. Questa volta, dopo aver usato Spotlight, è rimasto sullo schermo un riquadro molto sottile, quasi invisibile, ma proprio per questo ancora più fastidioso.

Le ho provate tutte. Ho cambiato lo sfondo. Ho cambiato la risoluzione dello schermo. Ho aperto Mission Control e ho rimosso il Desktop incriminato. Niente, non c’era verso di far andare via quel dannato riquadro, e più provavo a toglierlo e più mi dava fastidio.

Uscire e rientrare nell’account era fuori discussione, avevo troppe applicazioni aperte, terminali, sessioni ssh remote. E anche se al login macOS riapre automaticamente tutte le applicazioni attive, ricostruire la disposizione esatta dei vari Desktop sarebbe stato un vero lavoraccio.

Quick Look e Spotlight

Dopo un po’ di ricerche in rete ho scoperto che Spotlight su High Sierra ha dei problemi a causa di QuickLookUIService, un processo che viene lanciato quando si usa Quick Look, la funzione di macOS che permette di vedere l’anteprima di parecchi tipi di file premendo semplicemente la barra spaziatrice.²

Chissà, magari QuickLookUIService era responsabile anche del riquadro che continuavo a vedere sullo schermo?

La cosa più semplice da fare era aprire Monitoraggio Attività, selezionare tutti i processi QuickLookUIService attivi e provare a chiuderli premendo il bottone con il simbolo della X che si trova all’estremità sinistra della barra degli strumenti di Monitoraggio Attività.

Ha funzionato perfettamente. Appena chiusi tutti i processi QuickLookUlService, anche il riquadro sottile che mi dava tanto fastidio è scomparso.

A questo punto sarei molto curioso di verificare se questo metodo funziona anche con i pop-up dei nomi dei file. Ma ora che ho trovato un metodo per rimuoverli senza fatica, ci sarà di sicuro qualche corollario della legge di Murphy che impedirà ai nuovi pop-up di comparire per un po'!

Per chi usa il Terminale

Ma non c’è solo l’interfaccia grafica, tutto quello che si può fare da Monitoraggio Attività può essere fatto (e meglio) anche dal Terminale di macOS. Chi preferisce usare il Terminale può cercare il processo (o i processi) QuickLookUIService attivi con grep,

$ ps axu | grep QuickLookUI
maggi	10149	0.0	0.2	4565600	32816	??	Ss	3:43PM	0:00.37	/System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuickLookUl.framework/Versions/A/XPCServices/QuickLookUlService.xpc/Contents/MacOS/QuickLookUlService
maggi	10725	0.0	0.0	4267768	840	  s006	S+	4:04PM	0:00.00	grep QuickLookUl
maggi	10673	0.0	0.2	4676576	40256	??	Ss	4:02PM	0:00.80	/System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuickLookUl.framework/Versions/A/XPCServices/QuickLookUlService.xpc/Contents/MacOS/QuickLookUlService

che stamperà una serie piuttosto criptica di informazioni relative ai processi che contengono nel nome o nel percorso la stringa cercata (fra cui anche il processo associato al comando grep che abbiamo appena eseguito). Di queste ci interessa solo il PID, il numero riportato nella seconda colonna della risposta subito dopo il nome breve dell’utente del Mac (come si può vedere nell’immagine precedente, il PID è riportato anche nella penultima colonna di Monitoraggio Attività).

Ora possiamo uccidere il processo (o i processi) QuickLookUlService con il comando kill -9 seguito dal PID,

$ kill -9 10673
$ kill -9 10725

o anche scrivendo tutti i PID sulla stessa riga

$ kill -9 10673T10725:00

In alternativa si può usare killall seguito dal nome del processo da chiudere

$ killall QuickLookUlService

Io preferisco usare kill -9 al posto di killall perché quest’ultimo, anche se in teoria è più semplice da usare, a volte non funziona come ci si aspetta (e francamente non ho mail capito il perché).

Per essere sicuri di aver ucciso veramente tutti i processi QuickLookUlService ci basta ripetere il comando grep

$ ps axu | grep QuickLookUI
maggi	10734	0.0	0.0	4267768	840	  s006	S+	4:04PM	0:00.00	grep QuickLookUl

verificando che restituisca solo il processo associato a sé stesso (domanda per i più attenti: perché il PID cambia ogni volta che esegue grep?).

Ma appena usiamo di nuovo Spotlight o Quick Look il sistema operativo lancerà di nuovo uno o più processi QuickLookUlService, come potremo verificare facilmente con Monitoraggio Attività o eseguendo di nuovo ps axu | grep QuickLookUI nel Terminale.

La tipica finezza Apple che all’inizio sembra superflua, ma dopo un po’ ti accorgi di non poterne più fare a meno. ↩︎
Spotlight e Quick Look sono strettamente connessi: i documenti trovati da Spotlight vengono visualizzati nella finestra di anteprima tramite Quick Look e non è certo un caso che Quick Look venga attivato dallo Spazio e Spotlight da ⌘-Spazio. ↩︎

Come creare una chiavetta USB per installare macOS

Tue, 07 Jan 2020 06:00:00 +0000

– Fonte: Ferdinand Stöhr su Unsplash.

Nell’articolo precedente, Come scaricare le versioni meno recenti di macOS: un anno dopo, abbiamo visto che da qualche mese Apple ha messo a disposizione delle versioni aggiornate dei programmi di installazione di macOS, da 10.10 Yosemite a 10.15 Catalina, utilizzando due diversi formati di file. Le versioni più recenti di macOS (High Sierra, Mojave e Catalina) sono disponibili solo come normali applicazioni per il Mac (formato .app), quella più vecchia (Yosemite) si può scaricare solo in formato immagine (o .dmg), mentre le due versioni intermedie sono disponibili sia come applicazioni che come immagini.

Ma una volta finito di scaricare uno dei programmi di installazione di macOS disponibili, come si fa ad installarlo sul Mac?¹

Aggiornare macOS non è difficile, ma cosa dobbiamo fare se vogliamo partire da zero? È sufficiente aprire il Terminale e seguire queste istruzioni per creare una chiavetta USB avviabile da cui eseguire una installazione pulita di macOS. Ma prima di farlo è meglio chiarire la differenza fra i due tipi di programmi di installazione di macOS messi a disposizione da Apple.

Due formati convergenti

I programmi di installazione disponibili come normali applicazioni per il Mac vengono scaricati nella cartella Applicazioni e si aprono automaticamente; con questi è possibile aggiornare in pochi minuti la versione di macOS installata sul Mac seguendo le semplici istruzioni che compaiono sullo schermo. Se invece vogliamo effettuare una nuova installazione di macOS, dobbiamo chiudere il programma (dal menu o con la combinazione di tasti ⌘-Q) ed eseguire un semplice comando di Terminale che trasferisce il programma di installazione presente in Applicazioni su una chiavetta USB, da cui avviare il Mac ed eseguire l’installazione di macOS.

Di contro, questo tipo di programmi di installazione richiedono il collegamento all’App Store e possono essere scaricati solo da chi lo ha già fatto in passato, quando erano disponibili sull’App Store, utilizzando un Mac compatibile con la versione di macOS desiderata (fa eccezione Catalina, la versione più recente di macOS, che è scaricabile liberamente dall’App Store da chiunque sia in possesso di un Mac compatibile).

I programmi di installazione in formato immagine, invece, possono essere scaricati liberamente dal sito di Apple senza passare dall’App Store, indipendentemente dal fatto che possano girare o no sul Mac usato per scaricarli. Una volta completato lo scaricamento, basta fare doppio click sul file .dmg per montare il file immagine sul Desktop del Mac e aprire una cartella contenente un tipico pacchetto (package) di installazione di macOS (l’analogo per il Mac dei ben più noti pacchetti di installazione per Windows o per Linux). Nella figura qui sotto è mostrato quello relativo a El Capitan, che utilizza ancora la vecchia denominazione “Mac OS X”,

questo invece è relativo a Sierra.

Un doppio click sul file .pkg fa partire l’installatore vero e proprio, che verifica che il programma in questione possa essere eseguito sul Mac,

e poi esegue la procedura di installazione standard di un package per macOS,

alla fine della quale troveremo in Applicazioni il programma vero e proprio di installazione di macOS, nella forma di una normale applicazione per il Mac, proprio come nel caso precedente.

Aggiornare o partire da zero?

In definitiva, qualunque sia il formato che decidiamo di scaricare, alla fine ritroveremo sempre in Applicazioni una applicazione per il Mac contenente il programma di installazione di macOS, e sarà questa che utilizzeremo per i passi successivi.

Se non si è già aperto automaticamente, possiamo fare doppio click sul programma di installazione presente in Applicazioni per aggiornare macOS alla versione desiderata, senza toccare le applicazioni e i documenti già presenti sul Mac.

Ma ci sono casi in cui si vuole ripartire da zero, ad esempio perché si è cambiato il disco di avvio del Mac, perché si è acquistato un Mac usato o perché, al contrario, si desidera vendere il Mac cancellando tutti i nostri dati e programmi dal sistema ma fornendo all’acquirente un computer con il sistema operativo preinstallato, utilizzabile sin dal primo momento. Oppure semplicemente perché abbiamo fatto dei pasticci e vogliamo ripartire da un sistema pulito.

Qualunque sia la ragione, per installare macOS da zero abbiamo davanti due alternative: la prima prevede di utilizzare macOS Recovery per installare l’ultima versione di macOS compatibile con il nostro modello di Mac, scaricandola eventualmente dalla rete.

L’altra alternativa richiede invece l’utilizzo di una chiavetta USB avviabile, sulla quale trasferire il programma di installazione di macOS scaricato. Una volta avviato il Mac dalla chiavetta USB si potrà installare macOS sul disco interno del Mac o eventualmente su un disco esterno collegato ad una porta USB3, Thunderbird o, per chi ce l’ha ancora, FireWire.

Creare una chiavetta USB avviabile

Utilizzare una chiavetta USB è molto più flessibile, perché a differenza di macOS Recovery ci permette di installare qualunque versione di macOS compatibile con il modello di Mac che stiamo utilizzando, senza nemmeno dover accedere alla rete o inserire i nostri dati personali per scaricare macOS. Avviare il Mac dalla chiavetta USB permette anche di cancellare preventivamente il disco rigido di avvio, partendo quindi da un sistema pulito. Altro aspetto a volte non trascurabile è che possiamo ripetere rapidamente l’intero processo di installazione su più Mac, senza dover attendere ogni volta lo scaricamento del programma di installazione.

Questa flessibilità ha un piccolo costo, perché richiede l’utilizzo del Terminale, ma basta seguire le istruzioni seguenti con un minimo di attenzione per non avere problemi.

Serve una chiavetta USB da almeno 8 GB (da almeno 16 GB per Catalina), vuota o contenente dei file che non servono più, perché nei passi successivi sarà cancellata completamente, senza troppe possibilità di recupero dei dati pre-esistenti. Per cui fate attenzione!, perché potreste perdere dei dati importanti.

Bisogna rinominare la chiavetta USB in modo che abbia un nome standard, che verrà usato in tutte le istruzioni successive. Il nome in sé non è importante, tanto sarà modificato nel corso del trasferimento del programma di installazione di macOS sulla chiavetta, ma usarne uno standard semplifica la scrittura dei comandi da Terminale. Per cui chiamiamola “InstallazioneUSB”, senza spazi, e non pensiamoci più.

La chiavetta USB deve essere formattata in formato Mac OS esteso con Mappa partizione GUID, se non siamo sicuri che sia già nel formato giusto lanciamo Utility Disco (si trova in Applicazioni → Utility) e selezioniamo le stesse opzioni mostrate nella figura qui sotto. Anche il nome da dare alla chiavetta può essere inserito in questo momento.

Ogni volta che si usa Utility Disco, bisogna stare molto attenti a non formattare per sbaglio un altro disco collegato al Mac, ma basta guardare la dimensione del disco da formattare, ben visibile in un riquadro in alto a destra della finestra di Utility Disco, per non sbagliare.

A questo punto si può lanciare il Terminale di macOS (anche questo si trova in Applicazioni → Utility) ed eseguire createinstallmedia, un programma nascosto da Apple in tutte le versioni gratuite dei programmi di installazione di macOS distribuite tramite l’App Store, che permette di trasferire sulla chiavetta USB i file di installazione di macOS. Le opzioni necessarie per il corretto funzionamento di createinstallmedia variano leggermente a seconda della versione di macOS e qui sotto è riportato il comando completo da utilizzare per ciascuna versione di macOS che è possibile trasferire sulla chiavetta.

Catalina

$ sudo /Applications/Install\ macOS\ Catalina.app/Contents/Resources/createinstallmedia --volume /Volumes/InstallazioneUSB &#38;&#38; osascript -e 'display notification "Trasferimento completato." with title "Terminale"'

Mojave

$ sudo /Applications/Install\ macOS\ Mojave.app/Contents/Resources/createinstallmedia --volume /Volumes/InstallazioneUSB &#38;&#38; osascript -e 'display notification "Trasferimento completato." with title "Terminale"'

High Sierra

$ sudo /Applications/Install\ macOS\ High\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/InstallazioneUSB &#38;&#38; osascript -e 'display notification "Trasferimento completato." with title "Terminale"'

Sierra

$ sudo /Applications/Install\ macOS\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/InstallazioneUSB --applicationpath /Applications/Install\ macOS\ Sierra.app &#38;&#38; osascript -e 'display notification "Trasferimento completato." with title "Terminale"'

El Capitan

$ sudo /Applications/Install\ OS\ X\ El\ Capitan.app/Contents/Resources/createinstallmedia --volume /Volumes/InstallazioneUSB --applicationpath /Applications/Install\ OS\ X\ El\ Capitan.app &#38;&#38; osascript -e 'display notification "Trasferimento completato." with title "Terminale"'

Yosemite

$ sudo /Applications/Install\ OS\ X\ Yosemite.app/Contents/Resources/createinstallmedia --volume /Volumes/InstallazioneUSB --applicationpath /Applications/Install\ OS\ X\ Yosemite.app --nointeraction &#38;&#38; osascript -e 'display notification "Trasferimento completato." with title "Terminale"'

Anche Mavericks può essere trasferito su una chiavetta USB con lo stesso metodo, sempre ammesso che si riesca a trovare da qualche parte il programma di installazione di questa versione del sistema operativo desktop di Apple.

$ sudo /Applications/Install\ OS\ X\ Mavericks.app/Contents/Resources/createinstallmedia --volume /Volumes/InstallazioneUSB --applicationpath /Applications/Install\ OS\ X\ Mavericks.app --nointeraction &#38;&#38; osascript -e 'display notification "Trasferimento completato." with title "Terminale"'

Come sempre il simbolo $ indica il prompt del Terminale di macOS e non fa parte del comando.

I comandi elencati vanno eseguiti da un account di tipo Amministratore; se siete l’unico utente del Mac siete automaticamente un amministratore del sistema, altrimenti dovete fare login in un account di questo tipo e riprovare oppure dovete chiedere all’amministratore del vostro Mac di eseguirlo per voi. Subito dopo aver premuto Invio vi verrà chiesta la password di login del vostro account, seguita da una richiesta di conferma dell’operazione di trasferimento del programma di installazione di macOS sulla chiavetta USB.

Il trasferimento del programma di installazione di macOS sulla chiavetta USB dura parecchio, almeno cinque minuti e spesso molto di più, a seconda della velocità di scrittura della chiavetta USB. Nel frattempo potete tranquillamente fare altro: una volta concluso positivamente il processo di trasferimento, il Mac provvederà a notificarcelo direttamente sul Desktop e farà anche ricomparire il prompt del Terminale.

Chi preferisce un avviso sonoro può sostituire la seconda parte del comando, da osascript -e ... fino alla fine della linea, con say "Trasferimento completato". Assicuratevi di aver installato il supporto per le voci in italiano (tramite Preferenze di Sistema → Accessibilità → Voce oppure Preferenze di Sistema → Dettatura e voce → Testo da pronunciare, a seconda della versione di macOS presente sul Mac) altrimenti vi sembrerà di sentire Ollio, ma in ogni caso un avviso sonoro sembra qui più efficace di una notifica.

Per chi vuole uno strumento grafico

Il Terminale è un strumento potentissimo, ma tanti utenti del Mac vengono messi a disagio dalla sua interfaccia spartana a linea di comando, e hanno quasi paura di usarlo temendo di fare danni. In questo caso specifico è molto difficile, se si seguono attentamente le istruzioni è impossibile sbagliare. Ma visto che ci sono due buoni strumenti che permettono di trasferire un programma di installazione di macOS su una chiavetta USB tramite una interfaccia grafica, perché non segnalarli?

Tanto è facile, sono solo due, Install Disk Creator e DiskMaker X, entrambe gratuiti (la versione Pro di DiskMaker X serve solo a chi deve installare macOS su un gran numero di Mac diversi o si occupa di supporto tecnico). Ammetto di non averli mai usate perché con il Terminale faccio prima, ma sono entrambi degli strumenti noti e notoriamente affidabili, chi decidesse di usarli non avrà problemi. E nel caso, c’è sempre il Terminale…

Per semplicità nel testo dell’articolo userò sempre il termine “macOS” anche per indicare le versioni che in origine si chiamavano OS X. ↩︎

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!!!

Come cambiare la data in macOS

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

– Fonte: JustHourglasses.

“Ma stai scherzando? Perché ci vuoi propinare uno dei tuoi soliti lunghissimi articoli solo per insegnarci a cambiare la data in macOS? Non lo sai che basta essere collegati ad internet e il Mac fa tutto da solo?”

Data e ora in macOS

Avete ragione, macOS (così come qualunque sistema operativo moderno) è perfettamente in grado di gestire da solo la data e l’ora. Gli basta collegarsi ai server Apple sui quali gira il servizio NTP (Network Time Protocol) per sincronizzare l’orologio interno del Mac con l’ora ufficiale di uno degli orologi atomici sparsi nel mondo.

Però ci sono almeno due casi in cui dobbiamo impostare data (e ora) a mano.

Il primo si verifica quando vogliamo aggiornare o installare ex-novo macOS utilizzando un programma di installazione scaricato prima della data fatidica del 24 ottobre di quest’anno, data nella quale Apple ha aggiornato la firma digitale di tutte le versioni di mac OS distribuite attraverso l’App Store (cioè da Lion in poi).

Il secondo caso si presenta quando la batteria montata sulla scheda madre del Mac invecchia e non riesce più a conservare le impostazioni del sistema, fra cui proprio la data e l’ora. Non potendo più contare sulla batteria interna, ad ogni riavvio la data del Mac si resetta al primo gennaio del 1970, al 2000 o a qualche altro giorno ormai lontano nel tempo.¹ Se proviamo ad aggiornare o ad installare macOS senza aver prima corretto la data, il Mac si può rifiutare categoricamente di procedere, con dei messaggi di errore così criptici da essere praticamente inutili, come questo di El Capitan,

o quest’altro di Sierra.

Le schermate di sopra sono state ottenute provando a installare macOS in Parallels. Con High Sierra e Mojave la data sbagliata non impedisce di completare il processo di installazione, ma non so dire se è una correzione inserita volutamente da Apple in queste versioni più recenti di macOS oppure è un effetto dell’emulatore.

Per impostare a mano la data possiamo usare due procedure diverse: una usa l’interfaccia grafica del Mac, l’altra ha bisogno del Terminale. Possiamo utilizzare la prima se abbiamo già macOS funzionante e vogliamo solo aggiornarlo, l’altra invece è necessaria quando dobbiamo installare macOS da zero, ad esempio perché macOS non riesce ad avviarsi (rarissimo, ma può succedere) o perché abbiamo cambiato il disco rigido del Mac.

Quando macOS è già installato

Se macOS è già installato sul Mac e vogliamo aggiornarlo utilizzando un programma di installazione scaricato prima del 24 ottobre – perché siamo pigri e non vogliamo scaricare di nuovo il programma di installazione di macOS oppure perché non troviamo più sull’App Store la versione di macOS che ci interessa – possiamo continuare a farlo con un trucco semplicissimo, che risale quasi alla notte dei tempi (informatici). Basta cambiare la data del Mac facendo in modo che sia precedente al 24 ottobre. Una volta concluso il processo di installazione potremo ripristinare senza problemi la data reale.

Un altro scenario possibile si presenta quando la batteria montata sulla scheda madre non riesce a conservare le impostazioni di data ed ora. In questo caso, per motivi che mi sfuggono, i server NTP non riescono a reimpostare automaticamente la data e l’ora corretta e bisogna per forza di cose fare a mano.

Qualunque sia la ragione, cambiare a mano la data del Mac dall’interfaccia grafica è facilissimo, come si vede nelle schermate seguenti.

Bisogna aprire le Preferenze di Sistema e fare doppio click sulle impostazioni di Data e Ora,

cliccare sull’icona del lucchetto per abilitare le modifiche e inserire nome utente e password (e no, le mie password non sono solo di quattro caratteri!),

deselezionare l’opzione che imposta automaticamente la data e l’ora e inserire nei campi sottostanti la data e l’ora desiderata, premendo il tasto Salva per confermare le modifiche,

e infine selezionare di nuovo l’opzione che imposta automaticamente la data e l’ora.

Se volete fare i fini potete anche impostare, al posto dei server NTP gestiti da Apple, uno dei server NTP ufficiali del nostro paese, ntp1.inrim.it, ntp2.inrim.it, time.inrim.it, premendo poi il tasto Invio per confermare la nuova impostazione,

e cliccando poi sull’icona del lucchetto per disabilitare ulteriori modifiche.

Quando dobbiamo partire da zero

Tutti i PC permettono di modificare la data e l’ora del sistema tramite il BIOS, senza aver bisogno di avviare il sistema operativo (i PC moderni, e anche il Mac, ormai usano l’EFI, Extensible Firmware Interface, ma il termine BIOS è rimasto scolpito nella memoria).

Anche i Mac con processore PowerPC potevano modificare data ed ora tramite l’Open Firmware, una specie di BIOS potenziato sviluppato da Sun e utilizzato da Apple per tutti i suoi Mac prima del passaggio ai processori Intel.

Sui Mac moderni, invece, l’unica possibilità per impostare a mano la data e l’ora senza utilizzare il sistema operativo è tramite la funzione di macOS Recovery, che normalmente viene richiamata premendo i tasti CMD (⌘) ed R all’avvio del Mac. Se sul disco rigido è già presente una partizione dedicata a macOS Recovery (normalmente invisibile ai normali strumenti di gestione dei file), l’utility verrà caricata da questa partizione, altrimenti il Mac provvederà a scaricare macOS Recovery da Internet e ad installarla sul disco di avvio del Mac.

Un’altra possibilità per accedere a macOS Recovery è quella di utilizzare una chiavetta USB avviabile che contiene un programma di installazione di macOS.

In tutti i casi, una volta avviato macOS Recovery e selezionata la lingua dell’interfaccia,

comparirà la schermata principale dell’utility di ripristino di macOS.

A questo punto bisogna selezionare il Terminale dal menu Utility,

e aspettare qualche secondo che compaia il Terminale al posto dell’interfaccia principale di macOS Recovery (si noti che, anche se abbiamo impostato l’italiano come lingua del sistema, il Terminale parla sempre e solo in inglese).

Per impostare la data e l’ora bisogna utilizzare il comando date seguito dalla data e dall’ora in un formato piuttosto astruso, MMDDhhmmYYYY, dove MM indica il mese (scritto sempre con due cifre, premettendo eventualmente lo zero), DD il giorno (sempre con due cifre), hh e mm l’ora e il minuto da impostare (c’è bisogno di dire che anche questi vanno scritti sempre con due cifre?) e infine YYYY indica l’anno. Qui sotto, ad esempio, ho impostato il mese di dicembre (12), il giorno 11, le ore 18 e 10 minuti e l’anno corrente (2019).

Se invece vogliamo impostare la data e l’ora del nostro Mac alle nove e trentacinque del mattino del quindici luglio 2018, dovremo scrivere nel Terminale

date 071509352018

Una volta impostata la data possiamo chiudere il Terminale e ritornare alla schermata principale di macOS Recovery, per proseguire l’installazione di macOS oppure riavviare il Mac senza installare nulla.

Conclusioni

Scrivere questo articolo è stato piuttosto noioso e questo fatto, insieme a svariati impegni lavorativi e familiari, ha contribuito ad allungare a dismisura i tempi di pubblicazione.

Ma anche se l’argomento trattato non è dei più interessanti, ho voluto pubblicarlo lo stesso perché la prima volta che non sono riuscito ad installare macOS a causa della data sbagliata ho dovuto faticare parecchio per capire cosa stesse succedendo. Se risparmierò questa fatica a qualche lettore del blog ne sarà valsa la pena.

Il 1 gennaio 1970 è la data in cui è iniziato il tempo, almeno secondo UNIX. ↩︎

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!

FTP con caffé e cornetto

Wed, 28 Dec 2016 18:00:00 +0000

Ha senso oggi trasferire file tramite FTP (l’acronimo sta per File Trasfer Protocol)?

Il protocollo FTP è stato ideato nei primi anni ‘70, agli albori di internet, quando solo pochissimi ricercatori usavano la rete e i problemi di sicurezza erano sconosciuti. Riuscire a trasferire file in modo efficiente ed affidabile da un punto all’altro della rete era un’esigenza fondamentale, in un’epoca di collegamenti lenti ed effettuati per lo più tramite la rete telefonica. Se questo comportava dover trasmettere i propri dati in chiaro attraverso la rete, pazienza, al massimo significava (allora!) dover subire qualche scherzo più o meno divertente.

Oggi FTP è sempre meno usato, anche nella versione più sicura SFTP basata su ssh (Secure SHell). Ormai il protocollo è integrato nei browser web (provate ad esempio questo link, ftp://ftp.debian.org/debian/), mentre i servizi cloud hanno reso sempre inutile mettere su un server FTP per condividere grossi file con colleghi ed amici (un vecchio classico: mettere a disposizione le foto di qualche manifestazione o festa).

Ma ci sono casi in cui può ancora servire, in particolare se vogliamo trasferire file di grosse dimensioni, meglio ancora intere directory, oppure se sviluppiamo siti e applicazioni web e vogliamo poter sincronizzare facilmente le modifiche effettuate sul nostro computer con un server remoto.

Sia FTP che SFTP sono presenti in tutti i sistemi Unix come applicazioni da riga di comando. Il Mac non fa eccezione: i programmi ftp e sftp sono installati di default in macOS/OS X e possono essere usati dal Terminale.

Ma anche un appassionato del Terminale come me si rende conto che per gestire i file un’interfaccia grafica è in tanti casi molto più comoda di una a riga di comando.

Per fortuna sul Mac i programmi grafici per FTP/SFTP non mancano di certo e tanti implementano anche protocolli meno diffusi ma altrettanto utili come rsync, per mantenere sincronizzati singoli file e intere directory su due o più computer senza dover usare un servizio cloud, o WebDAV, che permette di modificare file remoti tramite il comune protocollo http utilizzato dai browser web.

Negli anni ne ho usati parecchi, sia i pesi massimi commerciali ForkLift e Transmit che l’open source CyberDuck, che per tanto tempo è stato il mio preferito e che poteva essere usato anche dal Terminale. Ho provato brevemente Flow e pure RBrowser e Fetch, i cui siti web hanno ormai un aspetto vintage, ma ormai da tempo uso solo Yummy FTP Pro, che secondo me ha il miglior equilibrio fra potenza e facilità d’uso.

Il pannello di configurazione può mettere in soggezione, ma le opzioni di default sono scelte con molta cura ed in genere non è necessario modificarle. Dopo anni di uso credo di aver cambiato solo la directory su cui salvare i file trasferiti. Allo stesso tempo, il fatto di poter configurare il programma in modo così dettagliato può permettere di risolvere i casi più difficili senza penare troppo.

Comodissima è anche la possibilità di salvare i bookmark dei server a cui si accede più spesso, con tutte le opzioni di connessione relative, e di sincronizzarli fra tutti i Mac tramite Dropbox, iCloud Drive o Google Drive.

In questi giorni Yummi FTP Pro ha un prezzo imbattibile sull’App Store, costa praticamente quanto un caffé e cornetto. Fatevi un favore e non fatevelo sfuggire. Anche se non usate spesso FTP/SFTP, a questo prezzo è una applicazione che non può mancare sul vostro Mac.

Auguri dal Terminale

Sun, 25 Dec 2016 00:00:00 +0000


  ########    ###    ##    ## ######## ####       ###    ##     ##  ######   ##     ## ########  ####  
     ##      ## ##   ###   ##    ##     ##       ## ##   ##     ## ##    ##  ##     ## ##     ##  ##   
     ##     ##   ##  ####  ##    ##     ##      ##   ##  ##     ## ##        ##     ## ##     ##  ##   
     ##    ##     ## ## ## ##    ##     ##     ##     ## ##     ## ##   #### ##     ## ########   ##   
     ##    ######### ##  ####    ##     ##     ######### ##     ## ##    ##  ##     ## ##   ##    ##   
     ##    ##     ## ##   ###    ##     ##     ##     ## ##     ## ##    ##  ##     ## ##    ##   ##   
     ##    ##     ## ##    ##    ##    ####    ##     ##  #######   ######    #######  ##     ## ####  
  
  ########  ######## ########     ##     ## ##    ##  #######   
  ##     ## ##       ##     ##    ##     ## ###   ## ##     ##  
  ##     ## ##       ##     ##    ##     ## ####  ## ##     ##  
  ########  ######   ########     ##     ## ## ## ## ##     ##  
  ##        ##       ##   ##      ##     ## ##  #### ##     ##  
  ##        ##       ##    ##     ##     ## ##   ### ##     ##  
  ##        ######## ##     ##     #######  ##    ##  #######   
  
   ######  ########  ##       ######## ##    ## ########  #### ########   #######   
  ##    ## ##     ## ##       ##       ###   ## ##     ##  ##  ##     ## ##     ##  
  ##       ##     ## ##       ##       ####  ## ##     ##  ##  ##     ## ##     ##  
   ######  ########  ##       ######   ## ## ## ##     ##  ##  ##     ## ##     ##  
        ## ##        ##       ##       ##  #### ##     ##  ##  ##     ## ##     ##  
  ##    ## ##        ##       ##       ##   ### ##     ##  ##  ##     ## ##     ##  
   ######  ##        ######## ######## ##    ## ########  #### ########   #######   
  
  ##    ##    ###    ########    ###    ##       ######## ####  
  ###   ##   ## ##      ##      ## ##   ##       ##       ####  
  ####  ##  ##   ##     ##     ##   ##  ##       ##       ####  
  ## ## ## ##     ##    ##    ##     ## ##       ######    ##   
  ##  #### #########    ##    ######### ##       ##             
  ##   ### ##     ##    ##    ##     ## ##       ##       ####  
  ##    ## ##     ##    ##    ##     ## ######## ######## ####