Programmazione on Melabit

70 anni di Fortran (più o meno)

Sun, 06 Oct 2024 06:00:00 +0000

Pochi giorni fa, il 20 settembre per essere precisi, il Fortran ha compiuto 70 anni.¹ La data scelta per il compleanno è un po’ anomala, per i software di solito si celebra la data in cui vengono presentati al pubblico,² mentre per il Fortran è stato scelto il giorno in cui gli sviluppatori dell’IBM hanno eseguito il primo programma scritto in questo linguaggio, ben tre anni prima della presentazione ufficiale.

Ad alto livello

Ed è una decisione pienamente giustificata, poiché il 20 settembre del 1954 accade qualcosa che avrebbe fatto la storia: per la prima volta un computer esegue un programma scritto in un linguaggio ad alto livello, molto più vicino al modo di pensare di un uomo, invece che in un linguaggio comprensibile solo alle macchine come l’assembler.

Un evento cruciale, che avrebbe reso la programmazione accessibile ad un numero sempre maggiore di persone, aprendo la strada alla diffusione capillare dei computer e innescando una trasformazione radicale della società e della nostra vita quotidiana. Non a caso David Padua³ sostiene che

è quasi universalmente riconosciuto che l’evento più importante del XX secolo nel campo dei compilatori – e in quello dell’informatica [in generale, ndt] – è stato lo sviluppo del primo compilatore Fortran tra il 1954 e il 1957. Dimostrando che è possibile generare automaticamente codice macchina di qualità a partire da descrizioni ad alto livello, il team IBM guidato da John Backus aprì le porte all’era dell’informazione.

Il primo programma?

Per quanto abbia cercato non sono riuscito a trovare il codice di questo primo programma in Fortran, ma non dovrebbe essere troppo diverso da questo,

– IBM 704 Fortran Programmer’s Reference Manual, 1956.

che cerca il numero più grande in una lista di numeri fornita dall’utente. Il programma è molto semplice e può analizzare non più di 999 numeri ma, quando l’unica alternativa era scorrere a mano colonne e colonne di numeri, doveva essere un bel passo in avanti.

Da notare la presenza dell’istruzione FREQUENCY, rimossa nelle versioni successive e più efficienti del compilatore, con la quale il programmatore poteva stimare il numero di volte in cui ciascun ciclo DO o test logico IF poteva essere eseguito, dando modo al compilatore di ottimizzare il codice macchina generato. L’ottimizzazione si basava sul nuovo (per l’epoca) metodo Monte Carlo, che non è per niente difficile da padroneggiare, ma che deve essere piuttosto difficile da programmare in un linguaggio a basso livello come l’assembler. Tanto di cappello per gli sviluppatori del primo Fortran!

Ottimizzare ottimizzare ottimizzare

La questione dell’ottimizzazione del codice generato dal compilatore era essenziale per il successo del nuovo compilatore Fortran. I computer di allora erano estremamente lenti e costosi, e i programmi dovevano essere molto efficienti per riuscire ad eseguire le operazioni richieste senza inutili sprechi di risorse. Il team IBM era consapevole che

se il Fortran, nei suoi primi mesi di vita, fosse in grado di tradurre qualsiasi programma sorgente scientifico ragionevole in un programma oggetto con una velocità pari alla metà di quella della sua controparte codificata a mano, l’accettazione del nostro sistema sarebbe in serio pericolo.

E ci sono riusciti. Un programma scritto in Fortran e tradotto in codice macchina attraverso il primo compilatore risultava effettivamente più lento di uno equivalente scritto in assembler, ma molto meno di quanto avessero temuto inizialmente gli sviluppatori.

Il grande vantaggio di poter programmare utilizzando un linguaggio ad alto livello, con una sintassi molto vicina all’inglese, compensava ampiamente questa perdita di prestazioni. Non a caso, in pochi anni l’uso dei linguaggi ad alto livello si diffuse così tanto da mandare l’assembler nel dimenticatoio.

Notarelle finali

Il manuale della prima versione del Fortran era davvero smilzo, appena 54 pagine. Niente a che vedere con i giganteschi tomi odierni, che riempiono 4-500 pagine per insegnare i rudimenti di un linguaggio di programmazione o di uno strumento software.

Negli anni ‘80 il Fortran era così popolare in ambito scientifico che poteva essere usato non solo sui grossi mainframe o sulle workstation e i minicomputer tanto diffusi in ambito universitario, ma perfino sui microcomputer economici come il Commodore 64 e lo Spectrum 48K, oppure (c’è bisogno di dirlo?) sul più potente Apple II. Certo, su queste macchinette non si poteva pensare di far girare una simulazione meteorologica o di generare un frattale in tempo reale, ma per imparare nella comodità di casa propria potevano essere più che sufficienti.

È curioso che i tre principali linguaggi di programmazione sviluppati negli anni ‘50, Fortran (1954), LISP (1958) e COBOL (1959) siano ancora in uso oggi, dividendosi in modo netto i campi di applicazione: il Fortran per il calcolo scientifico ed ingegneristico, il COBOL in campo finanziario e bancario. E il LISP? Beh, il LISP sta ben nascosto in tante cose odierne, fra cui emacs e Julia, e comunque rimane sempre il più affascinante dei tre.

Bibliografia

Qualche link per chi volesse approfondire:

Il sito di riferimento del linguaggio Fortran, fortran-lang.org.
A Brief History of FORTRAN/Fortran.
David Padua, The Fortran I Compiler, Computing in Science & Engineering, 2000.
Lee Phillips, Scientific computing’s future: Can any coding language top a 1950s behemoth?, Ars Technica, 2014.
Rud Merriam, This Is Not Your Father’s FORTRAN, Hackaday, 2015.
Liam Tung, This old programming language is suddenly hot again. But its future is still far from certain, ZDNET, 2021.

Lo so, ormai non sono più tanto pochi, ma negli ultimi tempi sono stato assorbito dal trasloco imprevisto del nostro istituto a causa di urgenti lavori di ristrutturazione. ↩︎
Anche in modo informale, come è successo per Linux, presentato per la prima volta su un newsgroup dedicato ad un sistema operativo ormai dimenticato. ↩︎
David Padua è professore emerito presso il Dipartimento di Informatica dell’università dell’Illinois a Urbana-Champaign. ↩︎

Dieci anni!

Mon, 18 Dec 2023 06:00:00 +0000

Dieci anni fa nasceva MelaBit, questo piccolo blog dedicato al mondo Apple, della programmazione e della scienza con un pizzico di nostalgia per il retrocomputing. Sembra ieri quando pubblicai il mio primo articolo, e invece eccoci qui, nel 2023, a festeggiare il primo decennio di vita di questo spazio online.

In tutti questi anni MelaBit è cresciuto insieme a me e a tutti voi lettori, che mi avete sostenuto con i vostri commenti, le condivisioni e il tempo che dedicate a leggere i miei articoli.

In questi dieci anni ho avuto il piacere di raccontare le novità di Apple e dei sistemi operativi, scoprire insieme a voi linguaggi di programmazione e software utili e condividerete riflessioni sulle innovazioni tecnologiche. Ho potuto viaggiare nel tempo parlando di mitici computer del passato ed esplorare alcuni affascinanti ambiti della scienza.

Voglio ringraziare ognuno di voi per aver reso MelaBit quello che è oggi. Grazie ai miei primi lettori, a chi è arrivato negli anni e a chi ci seguirà in futuro. Il viaggio continua, tutti insieme!

Post Scriptum. Per l’immagine di copertina ho lasciato fare all’IA di Microsoft (eh già!). Secondo me ha fatto un buon lavoro, ma alcune alternative erano altrettanto valide, come si può vedere qui sotto. Peccato solo per gli strafalcioni nell’ultima immagine, sarà pure artificiale ma un ripassino di grammatica questa intelligenza dovrà pur farlo!

Swift contro Python, ovvero mele contro pere

Mon, 03 Oct 2022 06:00:00 +0000

– Fonte: Martina Leuderalbert su Unsplash.

Alle elementari la maestra mi aveva insegnato a non sommare le mele con le pere, cioè a non mettere insieme (o paragonare) cose e fatti molto diversi fra loro. Non ha quindi senso sommare 3 litri di acqua con 5 chilogrammi di farina o chiedersi se 40 metri sono più o meglio di 20 secondi.

Quello che diceva la mia maestra lo dicono, sono sicuro, le maestre di tutto il mondo, ma c’è sempre qualcuno assente a queste lezioni.

Il Golia della programmazione moderna

Uno di questi è stato di sicuro Ari Joury che, nonostante il suo dottorato in fisica delle particelle, non si è fatto scrupoli a pubblicare su Medium questo Swift was poised to replace Python. Then it tanked.

Cosa dice l’articolo? Che nel mondo del machine learning i linguaggi di programmazione più usati sono Matlab, R, Julia e soprattutto Python. Quest’ultimo, nato originariamente per sviluppare dei piccoli script senza troppe pretese, è diventato oggi un vero “Golia della programmazione moderna”, tanto da essere usato estensivamente da aziende come Dropbox, Instagram e Pinterest per i loro servizi online.

Grazie alla disponibilità di librerie come TensorFlow o PyTorch (nonché, aggiungo io, di librerie di base come Pandas o NumPy), Python è diventato anche il linguaggio di elezione di chi si occupa di machine learning e di analisi dei dati.

La crescita di Python sembra bloccata da un paio di anni, ma la sua enorme diffusione lo farà rimanere comunque un attore centrale anche nel prossimo futuro.

Entra in scena Swift

Fin qui tutto vero e condivisibile. Magari si potrebbe eccepire qualcosina sull’importanza di R nell’ambito dell’analisi dei dati, ma non voglio essere puntiglioso.

Il guaio è che se uno si limita a scrivere queste cose non se lo fila nessuno, chi vorrà mai leggere l’ennesimo articolo generico sulle virtù di Python per il machine learning (e non) o su quale linguaggio è destinato a soppiantarlo?¹ Ci vuole un colpo d’ala.

Per fortuna c’è sempre Apple che, come il nero, va bene su tutto e, soprattutto, garantisce sempre un bel po’ di click. E allora perché non mettere in mezzo Swift?

Swift è un linguaggio di programmazione sviluppato da Apple con l’obiettivo specifico di sostituire Objective-C come linguaggio di elezione per lo sviluppo delle applicazioni per iOS e per macOS. Swift è facile da imparare e la sua sintassi leggibile ricalca quella di Python, è vero, così come quella di Julia e di tanti altri linguaggi di programmazione moderni.²

Swift però non ha mai preteso di essere, come sostiene il nostro Ari, il nuovo “Re della Programmazione”. Ad Apple non interessa posizionare Swift come uno strumento di programmazione general purpose, le interessa solo che venga usato per programmare le applicazioni per i suoi sistemi operativi. Del resto, il fatto che manchi di una versione per Windows taglia fuori una fetta così importante di potenziali utenti da rendere impossibile a priori una pretesa tanto assurda.

A maggior ragione Swift non ha mai preteso di essere il nuovo strumento principe per il machine learning, come il buon Ari sotto sotto ci vuole far intendere. È vero che Google ha provato a supportare Swift all’interno di TensorFlow (di cui Google è il principale sviluppatore), ma questo esperimento, come succede con tanti altri prodotti dell’azienda di Mountain View, è stato interrotto nel 2021. È ragionevole pensare, infatti, che chi sviluppa in Swift preferisce usare gli strumenti per il machine learning integrati in macOS/iOS piuttosto che prodotti di terze parti.

Io sono più popolare di te

Ma la cosa più sconcertante è pretendere di confrontare la popolarità (o meno) dei linguaggi di programmazione utilizzando una metrica fasulla come la percentuale di domande poste ogni mese su StackOverflow relativamente ad uno o ad un altro linguaggio. In base a questa percentuale, la popolarità di Python è cresciuta costantemente fino alla fine del 2020, per poi stabilizzarsi al 16% del totale delle domande su StackOverflow, mentre quella di Swift dopo aver raggiunto un massimo del 3% è in declino e ora si aggira nei dintorni dell'1.5%.

Perché è una metrica fasulla? Perché finché siamo sui grandi numeri e confrontiamo la popolarità di Python con quella di JavaScript può anche avere senso basarsi sul numero di domande poste su StackOverflow per valutarne la diffusione.

Ma se buttiamo nel calderone anche la terna HTML, CSS e PHP, che sono ancora oggi tre strumenti fondamentali per chi fa sviluppo web, troviamo che questi ultimi sono in costante declino, senza però che la decadenza (su StackOverflow) di PHP venga compensata da un incremento corrispondente nell’interesse verso JavaScript.

Anche Wordpress, che piaccia o non piaccia sta dietro il 40% dei siti web, secondo la metrica di StackOverflow sarebbe in calo. Idem per MySQL.

E allora la spiegazione può essere un’altra: più che la diffusione, le domande su StackOverflow ci fanno vedere la complessità del linguaggio e la qualità della sua documentazione: HTML, CSS e PHP (o Wordpress e MySQL) sono prodotti ben assestati, per loro esistono ottime guide sul web che ne spiegano diffusamente i segreti. Di conseguenza non è necessario cercare risposte più o meno occasionali su StackOverflow, e comunque quelle che ci sono già bastano ed avanzano.

Python e JavaScript, al contrario, hanno una sintassi di base piuttosto semplice ma per essere usati al meglio hanno bisogno di un gran numero di librerie aggiuntive, che sono spesso più complesse del linguaggio base e che vengono aggiornate ed espanse di continuo. La documentazione relativa non tiene sempre il passo dello sviluppo, per cui il modo migliore per imparare ad usare al meglio le centinaia e centinaia di API disponibili è quello di rivolgersi a qualche esperto su StackOverflow, spingendo così in alto la popolarità dei due linguaggi.³

Secondo la logica basata sul numero di domande su StackOverflow anche C e C++, i linguaggi usati per la programmazione di sistema (e non) su Linux e Windows, sarebbero in declino, e lo stesso succede a concetti di base come algoritmo, architettura, classe o database. Ma sono in declino perché c’è davvero poco interesse o solo perché anche per loro c’è abbondanza di documentazione di ottimo livello, senza doversi ridurre a porre sempre delle nuove domande su StackOverflow?

Nel mio piccolo lo faccio anch'io: quando programmo in R uso pochissimo StackOverflow, perché posso usare l'ottimo help in linea di RStudio e perché la documentazione che accompagna le librerie aggiuntive di R è centralizzata sul [CRAN](https://cran.r-project.org/) (_The Comprehensive R Archive Network_) ed è di altissima qualità. E quando tutto questo non basta, posso trovare decine di siti e di blog che spiegano benissimo gli aspetti più ostici del linguaggio. Quando passo a Python (un linguaggio che, sia chiaro, mi piace parecchio), StackOverflow diventa quasi una necessità, perché la frammentazione e la mancanza di sistema di gestione centralizzata delle librerie di Python rendono molto più complicato trovare documentazione aggiornata di qualità.

Decaduto o semplice?

Swift è un linguaggio semplice con una ottima documentazione ufficiale, un eccellente strumento di apprendimento del linguaggio (e non solo) come Swift Playgrounds e un numero relativemente ridotto di librerie aggiuntive, c’è davvero bisogno di passare un sacco di tempo su StackOverflow per usarlo al meglio?

Guardando il grafico relativo al numero di domande relative a Swift ci si accorge che i picchi di interesse corrispondono alle date di presentazione della versione 1.0 (giugno 2014) e al rilascio delle versioni 2.0 (settembre 2015), 3.0 (settembre 2016) e 5.0 (marzo 2019) e, come è naturale, dopo ogni presentazione l’interesse tende a decadere, proprio perché per usare il linguaggio c’è davvero poco da chiedere su StackOverflow.

A supporto di questa tesi c’è il risultato di questa semplice query SQL, con la quale ho provato a calcolare il numero di domande poste su StackOverflow ogni anno. Di SQL ne so pochissimo per cui dovete prendere i risultati con le pinze, ma sembra che il numero di domande su StackOverflow sia in progressiva diminuzione, da un massimo di 2.2 milioni di domande nel 2016 a 1.6 milioni nel 2021.

Una volta raggiunta una base di conoscenza sufficientemente ampia non ha molto senso porre sempre delle nuove domande (che su StackOverflow sono fortemente scoraggiate) ma ci si può limitare ad utilizzare il materiale già esistente. Questo almeno per le tecnologie più stabili, come possono essere HTML, CCS, PHP, Wordpress, MySQL… oppure Swift. Quando invece abbiamo a che fare con strumenti in rapidissima evoluzione, come Python o JavaScript, StackOverflow diventa davvero il modo migliore per imparare.

Conclusioni

C’è bisogno di dilungarsi ancora? Non credo, dico solo che basarsi su ipotesi fantasiose o metriche poco affidabili per ipotizzare scenari catastrofici per Swift (o, al contrario, scenari entusiasmanti per Julia⁴) mi pare francamente insensato.

– Fonte: Dilbert di Scott Adams.

Capo: Non si possono confrontare mele e arance.

Dilbert: È chiaramente sbagliato, perché li hai appena confrontati e dichiarati diversi.

Wally: Mele e arance sono entrambi alimenti che crescono sugli alberi. Sarebbe assolutamente valido confrontarli dal punto di vista nutrizionale.

Dilbert: Ho notato che molte delle cose che escono dalla tua bocca non hanno senso.

Capo: Parli come mia moglie.

Wally: Non puoi paragonare tua moglie al tuo subordinato. Sono mele e arance.

Capo: Cosa sta succedendo qui?

Wally: Non lo so, ma non lo paragonerei a lavoro.

Ari sembra avere le idee un po’ confuse sul futuro di Python, dato che su Medium ha anche pubblicato Why Python is not the programming language of the future, oppure Bye-bye Python. Hello Julia! e perfino Why TensorFlow for Python is dying a slow death. ↩︎
E non è un caso, perché alla base di tutti questi linguaggi c’è sempre il buon vecchio BASIC, il primo linguaggio di programmazione davvero per tutti, che è stato il linguaggio di base dei computer personali degli anni ‘80 su cui si sono fatti le ossa tutti i grandi nomi dell’informatica di quegli anni. ↩︎
Le sole domande sulla libreria pandas di Python (una libreria fondamentale per chi usa Python per l’analisi dei dati) assommano al 3% del totale, le principali librerie per il machine learning (TensorFlow, Keras, PyTorch, scikit-learn, OpenCV, NLTK) fanno un altro 2%, mentre quelle su Django e Flask (le principali librerie Python per lo sviluppo di applicazioni per il web) sono quasi al 2.5% del totale generale. Chiaramente queste domande vengono anche conteggiate come domande relative a Python. ↩︎
Perché sì, l’interesse per Julia sembra essere in aumento su StackOverflow, ma parliamo di non più dello 0.16% (1/10 dei valori di Swift) e anche in questo caso i picchi corrispondono al rilascio delle varie versioni del linguaggio. ↩︎

JuliaCon 2021

Fri, 23 Jul 2021 12:00:00 +0000

Julia è l’ultimo arrivato fra i linguaggi di programmazione scientifici, che ambisce a combinare la velocità del Fortran con la semplicità sintattica e l’interattività di Python.

Un’altra particolarità molto interessante di Julia è il supporto nativo agli ambienti: ciascun progetto scritto in Julia può avere un suo ambiente specifico, contenente il compilatore,¹ le librerie e gli eventuali package aggiuntivi necessari, nelle versioni che garantiscono il perfetto funzionamento del progetto. La gestione degli ambienti è ancora oggi una delle principali debolezze di Python, averli integrati direttamente nel linguaggio di programmazione dovrebbe rendere più semplice la scrittura di codice riproducibile, il Santo Graal del software scientifico odierno.

– Fonte: JuliaCon 2021.

Perché parlo di Julia? Perché la settimana prossima inizia il JuliaCon 2021, un’ottima occasione per iniziare a conoscere questo interessante linguaggio di programmazione. La registrazione è gratuita per cui non ci sono rischi, nemmeno per il portafoglio.

In attesa dell’inizio della Conferenza, si stanno tenendo dei workshop preliminari molto interessanti che possono già essere visti su YouTube (o potranno essere visti in diretta nei prossimi giorni), senza nemmeno la necessità di installare l’ennesimo sistema di videoconferenza. Per quanto mi riguarda, finito il post mi guarderò Statistics with Julia from the ground up, mentre lunedì mi aspetta Introduction to Bayesian Data Analysis.

Per chi preferisce leggere, consiglio questo articolo generale del sempre bravissimo Jeffrey Perkel, Julia: come for the syntax, stay for the speed, e questo post su Towards Data Science, Bye-bye Python. Hello Julia!.

Buona visione (o buona lettura)!

Julia è un linguaggio compilato ma funziona anche in modo interattivo. ↩︎

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

Imparare Python

Sun, 16 Feb 2020 06:00:00 +0000

– Fonte: David Clode su Unsplash.

Di strumenti per imparare ad usare Python ce ne sono a iosa. Fra libri e corsi online come Think Python: How to Think Like a Computer Scientist e la relativa edizione interattiva, i più tradizionali Full Stack Python e Python Practice Book, o il corso online del MIT Introduction to Computer Science and Programming Using Python, c’è solo l’imbarazzo della scelta.

E poi, quando si inizia a masticare i rudimenti del linguaggio, c’è il favoloso Python Tutor, che mostra in modo interattivo quello che succede quando si esegue ogni singola linea di codice.

Senza dimenticare Real Python, che negli ultimi anni è diventato il sito di riferimento per il programmatore in Python, pieno di tutorial scritti benissimo, utili sia per il programmatore alle prime armi che per il professionista scafato che passa le giornate (e spesso anche le notti) davanti al monitor del computer. Il professionista non può farsi farsi sfuggire anche The Python Corner, un sito scritto in inglese (come tutti gli altri citati qui) ma italiano al 100%, e nemmeno Python Tricks: The Book, un libro pieno di trucchi fantastici, indispensabili per utilizzare Python al pieno delle sue potenzialità.

Insomma, per imparare Python non c’è che l’imbarazzo della scelta.

Ma la chicca me la sono lasciata per ultimo. Perché c’è chi non si accontenta di tutto questo ben di Dio e tanto fa che riesce ad avere accesso al corso di Python utilizzato internamente dalla NSA, l’agenzia USA che si occupa della raccolta e dell’elaborazione di dati e informazioni da tutto il mondo, nonché della sicurezza delle reti di comunicazione degli Stati Uniti. Evidentemente anche alla NSA pensano che Python sia un linguaggio di programmazione molto ben fatto, e ora anche noi comuni cittadini possiamo renderci conto di come l’insegnano, scaricando il corso introduttivo alla programmazione in Python scritto dai loro stessi insegnanti.

Non so voi, ma io sono curioso di dargli una occhiata. E poi è bello sapere che c’è in giro qualcuno molto più tignoso di me!

Buon Natale dal Terminale

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

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

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

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

oppure, se preferite la versione tradotta in italiano,

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

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

Buon Natale!!!

Script per tutti i giorni: lo script è il comando

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

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

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

$ chmod u+x nomescript

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

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

$ ./nomescript

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

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

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

Variabili di ambiente

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

$ env

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

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

$ echo $HOME

stampa nel Terminale il valore della variabile di ambiente HOME.

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

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

Shell e PATH

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

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

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

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

Siete avvertiti!!!

Modificare il PATH

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

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

$ cd ~

ed eseguire

$ emacs .bashrc

oppure

$ vi .bashrc

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

$ nano .bashrc

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

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

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

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

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

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

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

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

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

export PATH=$PATH:~/Development

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

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

$ nomescript

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

Ma non è ancora finita…

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

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

$ cd
$ mkdir bin

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

export PATH=$PATH:~/bin

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

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

$ chflags hidden ~/bin

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

Conclusioni

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

#!/bin/bash

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

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

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

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

E per oggi è davvero tutto.

Articoli precedenti

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

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

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

Script per tutti i giorni: entra in scena awk

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

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

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

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

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

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

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

AWK, questo sconosciuto

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

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

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

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

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

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

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

     END { istruzione
           istruzione
           ....
         }

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

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

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

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

$ brew install gawk

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

Un programma banale in awk

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

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

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

che applicato ad un elenco di indirizzi come questo,

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

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

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

$ awk -f swap.awk address.csv

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

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

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

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

Rinominare automaticamente un post

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

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

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

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

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

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

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

---

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

In questo caso particolare,...

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

$ cd ~/Development

e lanciamo lo script in awk con il comando

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

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

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

Conclusioni

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

Bibliografia

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

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

Script per tutti i giorni: shell e parametri

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

– Foto: Trammell Hudson su Flickr.

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

Una casa per i programmi

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

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

$ cd ~
$ mkdir Development

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

Volendo potremmo anche eseguire semplicemente

$ mkdir ~/Development

che crea la directory desiderata con un unico comando.

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

Andare con le proprie gambe

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

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

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

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

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

$ cd ~/Development

ed eseguiamo lo script con il comando

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

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

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

$ bash convert_title.sh

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

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

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

$ chmod u+x convert_title.sh

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

$ chmod u-x convert_title.sh`

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

$ chmod a+x convert_title.sh

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

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

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

Dato che qui usiamo bash, il nostro script diventa

#!/bin/bash

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

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

$ which bash
/bin/bash

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

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

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

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

Parametri sulla linea di comando

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

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

#!/bin/bash

string=$1

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

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

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

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

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

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

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

Conclusioni (per ora)

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

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

Revisioni

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

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

E sono cinque!

Tue, 18 Dec 2018 06:00:00 +0000

Oggi il blog compie cinque anni. Purtroppo me ne sono ricordato solo all’ultimo momento e non ho avuto il tempo di fare una analisi dettagliata come mi ero ripromesso di fare. Pazienza, magari ci sarà occasione in una circostanza meno “tonda”.

Una cosa che mi colpisce sempre è che, nonostante il blog sia in italiano, ben il 10% degli accessi provenga da fuori Italia. Chissà cosa riescono a capire i poveri visitatori che leggono gli articoli tramite Google Traduttore!

Un’altra cosa che mi colpisce è che, oltre ai tanti lettori affezionati che non mi stancherò mai di ringraziare per la loro immensa pazienza, circa due terzi dei vsitatori arrivano al blog tramite i motori di ricerca. Anzi, tramite Google, gli altri motori di ricerca, anche Bing o DuckDuckGo (e mi dispiace soprattutto per quest’ultimo), praticamente non esistono. Il che significa da un lato che il blog si posiziona abbastanza bene nelle ricerche sul web (anche se io non faccio nulla per spingere in su la SEO del blog), dall’altro che gli articoli hanno una vita piuttosto lunga e vengono cercati e letti anche molti anni dopo la pubblicazione. L’articolo più letto in assoluto quest’anno, Usare un Mac con PowerPC oggi è del 2016 e ha un numero di letture che tende a crescere ogni mese. Lo stesso sta succedendo all’articolo più letto pubblicato nel 2018, Ma il Fusion Drive serve ancora?, che ogni mese ha più che raddoppiato il numero di letture rispetto al mese precedente.

Fra le cose che non mi piacciono c’è quella di aver diminuito fortemente la cadenza di pubblicazione dei nuovi articoli, passando dai due articoli a settimana del 2014 a un solo articolo ogni dieci giorni di quest’anno. Sono valori medi, ma riflettono bene la scarsa velocità con la quale riesco a pubblicare nuovo materiale. Non che mi manchino gli spunti e le idee, anzi, quello che mi manca è il tempo per scrivere in pace e poi per rivedere quello che scrivo. In compenso la lunghezza media di ciascun articolo è cresciuta significativamente nel tempo, anche se non so se questa sia una cosa positiva o no.

Altra cosa che non mi piace è il numero di commenti, che si è ridotto anch’esso in modo molto significativo. Dal picco di circa 550 commenti del 2015 si è scesi ad appena 159 nel 2018, nonostante nello stesso periodo di tempo il numero di visitatori sia quasi raddoppiato. Mi piacerebbe che ci fosse maggiore interazione con chi legge il blog, e vorrei anche sapere se posso fare qualcosa per favorire questa interazione.

Prima di concludere, un piccolo consiglio di lettura. Ho scoperto da poco il libro Automate the Boring Stuff with Python, che si può leggere gratuitamente sul web o comprare in edizione elettronica o cartacea sul sito della casa editrice o sul solito Amazon. È una vera bomba, ed è pure perfettamente in tema con la serie dedicata al Terminale e allo scripting di questo periodo. Consigliatissimo!

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

Imparare a programmare per iOS

Mon, 12 Mar 2018 12:00:00 +0000

Lo so che tendo spesso a dimenticarlo, ma questo blog dovrebbe essere dedicato soprattutto alla programmazione e al Mac. E allora non posso non segnalare il volume di Craig Clayton, iOS 10 Programming for Beginners, edito da Packt e disponibile oggi (e solo oggi) in download gratuito.

Lo so che siamo a iOS 11 e che attendiamo iOS 12, ma sono anche convinto che per un principiante sia meglio concentrarsi sulle funzioni di base del sistema operativo, disponibili anche nelle versioni precedenti di iOS, piuttosto che provare a sfruttare le ultimissime bells and whistles (in italiano non esiste una espressione equivalente, diciamo più o meno “fronzoli”, “orpelli”) messe a disposizione ogni anno dagli ingegneri di Apple.

Inoltre, a differenza di tante altre introduzioni alla programmazione per iOS, questo volume usa Swift, il linguaggio di programmazione sviluppato negli ultimi anni da Apple e che sta avendo un successo molto superiore alle aspettative, sia perché funziona su tutte le piattaforme hardware/software dell’azienda (quindi non solo macOS e iOS ma anche tvOS e watchOS), sia perché è enormemente più semplice da imparare ed usare di Objective C, il linguaggio usato tradizionalmente per le applicazioni per iOS e per gran parte di quelle per il Mac.

Se siete appena appena interessati alla programmazione e ad iOS, secondo me non dovreste farvi sfuggire l’occasione.

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

Una linea di codice

Thu, 07 Sep 2017 18:00:00 +0000

A proposito di programmazione, cosa si può fare con una linea di codice? A volte si può fare moltissimo, come dimostra questa singola linea di codice JavaScript.

[code language=“javascript” htmlscript=true]


[/code]

Sono appena 128 caratteri, meno di un tweet, che però riescono a produrre questa bella immagine dinamica.

Ma come fa?

Alex Kras ha accettato la sfida e ha scritto un bellissimo articolo, Reverse Engineering One Line of JavaScript, in cui descrive il suo viaggio nei meandri di un codice solo apparentemente semplice.

È una splendida dimostrazione di capacità tecnica, sia di chi ha scritto il codice originale ma anche di chi si è dato tanto da fare per decodificarlo e per descriverne il funzionamento fin nei minimi particolari.

Capire tutti i dettagli dell’articolo non è facile, ma non credo che sia la cosa più importante. Ciò che importa è l’idea generale, è provare a mettersi nella testa di un programmatore per capire il suo modo di ragionare, è rendersi conto di quello che si può fare con una conoscenza più o meno approfondita di un linguaggio di programmazione (e delle basi matematiche che gli stanno dietro).

Il nostro codice non sarà mai così elegante e compatto? Che importa, l’importante è iniziare a provarci. Tanto si può solo migliorare.

Per la cronaca, questo è il codice finale dopo la decodifica.

[code language=“javascript” ] const DELAY = 64; // approximately 15 frames per second 15 frames per second * 64 seconds = 960 frames var n = 1; var p = document.getElementById(“p”); // var draw = “for(n+=7,i=delay,P=‘p.\n’;i-=1/delay;P+=P[i%2?(i%2*j-j+n/delay^j)&1:2])j=delay/i;p.innerHTML=P”;

/**
 * Draws a picture
 * 128 chars by 32 chars = total 4096 chars
 */
var draw = function() {
    var i = DELAY; // 64
    var P ='p.\n'; // First line, reference for chars to use
    var j;
 
    n += 7;
 
    while (i > 0) {
 
        j = DELAY / i;
        i -= 1 / DELAY;
 
        let index;
        let iIsOdd = (i % 2 != 0);
 
        if (iIsOdd) {
            let magic = ((i % 2 * j - j + n / DELAY) ^ j); // < ------------------
            let magicIsOdd = (magic % 2 != 0); // &1
            if (magicIsOdd) { // &1
                index = 1;
            } else {
                index = 0;
            }
        } else {
            index = 2;
        }
 
        switch (index) { // P += P[index];
            case 0:
                P += "p"; // aka P[0]
                break;
            case 1:
                P += "."; // aka P[1]
                break;
            case 2:
                P += "\n"; // aka P[2]
        }
    }
    //Update HTML
    p.innerHTML = P;
};
 
setInterval(draw, 64);

[/code]

Incredibile, no?

I più volonterosi possono anche provare a giocare con il codice, modificandolo a loro piacimento. Si può ad esempio cambiare colore e dimensioni del testo, inserendo queste righe nella sezione CSS (e poi andando a leggere qui per capire perché).

#p {
    color: blue;
    font-size: 10px;
}

Oppure modificare le le strighe "p" e ".", rispettivamente alle linee 39 e 42 del codice JavaScript, per cambiare i caratteri mostrati sullo schermo. Ancora più interessante è variare il valore di DELAY nella prima riga del codice JavaScript e vedere l’effetto che fa.

Sembra solo un giochetto un po’ stupido, ma si impara a programmare (anche) così.

Emulare il Macintosh online (seconda parte)

Sun, 07 May 2017 06:00:00 +0000

Nella puntata precedente abbiamo visto che da qualche settimana è disponibile un emulatore online del primo Macintosh, con il quale si possono provare parecchie applicazioni storiche per il Mac direttamente dal browser.

Le applicazioni presenti in questo momento sono 77, non tantissime, ma è probabile che aumentino con il tempo.

Ci sono due versioni di MacOS (proprio così, con Sierra siamo tornati allo stesso nome ma con una maiuscola in meno), un System 6 ridotto all’osso e un System 7 (del 1991) con un buon numero di applicazioni installate, a mostrare cosa poteva fare un Mac un quarto di secolo fa (System 7 è praticamente contemporaneo a Windows 3.0, uno dei sistemi operativi più inutili e pieni di bachi che abbia mai utilizzato).

Ci sono poi un po’ di giochi classici, che continuamo a vedere riproposti ancora oggi in tutte le salse, con solo un vestito più carino. Non mancano le applicazioni di produttività personale e qualche numero delle prime riviste in formato elettronico (e-zine).

Per lo sviluppo ci sono alcuni BASIC, ma c’è soprattutto HyperCard (con qualche stack relativo) a dimostrare la genialità di un programma troppo avanzato per i suoi tempi.

Insomma, con questo emulatore si possono provare parecchie cose interessanti, utili per mostrare ai più giovani le virtù (e i limiti) dei Mac degli anni ‘80 e ‘90, e che fanno respirare un soffio di nostalgia a chi c’era già e quei Mac e quei sistemi operativi li ha usati davvero.

Ma fra le tutte applicazioni disponibili, quella che mi ha incuriosito di più è stata DataFlow Version 0.0 (attenzione al numero di versione).

Non ne avevo mai sentito parlare, però non pretendo di certo di conoscere tutto il software sviluppato per il Mac (o per qualunque altra piattaforma). Forse quello che mi ha colpito è la finestra scarna e quasi vuota del programma, molto diversa rispetto a tutti gli altri programmi disponibili.

Lancio l’emulatore e la prima impressione è che DataFlow sia un programma come tanti, qualcosa per realizzare diagrammi di flusso o simili.

Ma poi guardo con più attenzione e mi accorgo che in realtà DataFlow è molto di più, è un sistema, anche se assai rudimentale, di programmazione visuale basato sul concetto di programma a flusso di dati (da cui il nome).

In pratica un programma di questo tipo è composto da un certo numero di blocchi fondamentali che eseguono una operazione predefinita sui dati in ingresso e poi li trasmettono al blocco successivo. Poiché i blocchi di elaborazione sono indipendenti fra loro, questo semplice concetto porta naturalmente al calcolo parallelo, senza i trucchi e gli inganni di tanti linguaggi adattati in modo un po’ raffazzonato allo scopo.

L’idea era relativamente nuova per l’epoca (con DataFlow siamo più o meno alla fine degli anni ‘80) ma ha generato sistemi di programmazione molto avanzati, utilizzati ancora oggi in ambiti estremamente diversi. Come ad esempio LabVIEW di National Instruments per il controllo della strumentazione elettronica, Simulink di MathWorks per la modellazione di sistemi dinamici, Quartz Composer di Apple per la composizione grafica e, più recentemente, TensorFlow di Google, diventato in pochissimo tempo uno degli strumenti più popolari, anzi direi proprio hot, nel campo della programmazione e dell’intelligenza artificiale.

Insomma DataFlow è un anticipo del futuro, una vera chicca buttata lì con noncuranza fra un foglio elettronico ed un giochino senza tante pretese.

Usarlo non è semplice, almeno per le abitudini odierne. L’interfaccia è rozza, i blocchi grafici non si possono spostare dopo averli posizionati sul foglio (io almeno non ci sono riuscito), le linee di connessione vanno un po’ troppo per i fatti loro, si vede che è una versione molto acerba (versione 0.0, oggi la chiameremmo una versione alfa se non meno). Alla fine comunque sono riuscito a fare un programmino semplice semplice, che prende due numeri interi e ne calcola somma, prodotto e quoziente.

Niente di che, è chiaro, ma quello che è particolarmente bello è che il programma è dinamico, se si cambiano i numeri in ingresso mentre il programma è in esecuzione le caselle di uscita aggiornano immediatamente i risultati. Oggi è scontato, ma trent’anni fa?

Naturalmente i programmi moderni fanno molto di più e in modo molto più comodo, ma i fondamenti ci sono già tutti in DataFlow. È bello che l’Internet Archive l’abbia sottratto all’oblio del tempo.

Un semplice programma in LabVIEW (sopra), e in una vecchia versione di Simulink (sotto).

Regolarizziamo

Mon, 20 Feb 2017 18:00:00 +0000

Le espressioni regolari sono uno degli argomenti più ostici che ci si può trovare ad affrontare quando si usa un computer. Purtroppo sono anche una delle cose più utili, in particolare quando si cerca qualcosa che è sepolto nel disco rigido o quando si devono estrarre informazioni da grosse moli di dati.

Ma prima di tutto, cos’è una espressione regolare, o come si dice normalmente in gergo informatico, una regexp?

Definizione. Una espressione regolare è una sequenza di caratteri che definisce uno schema di ricerca (search pattern) di informazioni strutturate in modo più o meno preciso.

Ecco, la chiave di tutto sta proprio nella espressione “più o meno preciso”. Cercare una parola precisa in un file è piuttosto facile, molto meno facile è cercare tutte le possibili variazioni della stessa parola, oppure intere classi di parole.

Arrivato a questo punto dovrei fare qualche esempio più o meno complicato di uso delle espressioni regolari per risolvere qualche problema pratico, come scambiare il nome con il cognome in una lista di indirizzi, aggiungere http://, o meglio https://, a tutti gli indirizzi web presenti in un file, cercare i numeri degli ordini di acquisto di una azienda e trasformarli in un formato standardizzato.

Ma non mi sogno nemmeno di farlo, scappereste quasi tutti a gambe levate. Perché le espressioni regolari si apprezzano solo quando servono veramente, quando permettono di risparmiare tempo e fatica facendo svolgere al computer, invece che a noi, le noiose operazioni ripetitive per le quali è così portato.

Imparare ad usare le espressioni regolari

E allora come si può imparare ad usare queste benedette espressioni regolari?

Ci sono decine di libri e di tutorial che ne trattano, ne ho elencati alcuni nella bibliografia. Devo però ammettere che i libri e la maggior parte dei tutorial non li ho mai non dico letti ma nemmeno guardati, mi annoierebbero troppo con le loro sequenze di regole e regolette, terra-terra e quasi inutili o così acrobatiche da essere incomprensibili.

Molto meglio i siti web che insegnano ad usare in pratica le espressioni regolari: inserisci da una parte l’espressione regolare e dall’altra il testo in cui cercare e l’applicazione mette in evidenza tutte le sequenze di caratteri che soddisfano l’espressione inserita (le occorrenze), con una spiegazione più o meno dettagliata di quello che succede.

Fra tutti i siti di questo tipo, il mio preferito è regex101, veloce e con spiegazioni chiare e prive di inutili dettagli. Al secondo posto Debuggex, ottimo ma più complesso da usare, soprattutto le prime volte. Non male anche RegExr, che però interpreta le espressioni regolari inserite utilizzando il motore JavaScript del browser, che non è sempre compatibile al 100% con le espressioni regolari di altri linguaggi.

Ci sporchiamo le mani?

Tutto qui? Per ora si, questa voleva essere solo una piccolissima introduzione al mondo oggettivamente complicato delle espressioni regolari. Più o meno come mettere il dito nell’acqua per vedere se è fredda.

Se l’argomento interessa, si può andare avanti con l’esplorazione, magari partendo da problemi pratici non troppo banali (affrontabili con tecniche meno complesse), ma nemmeno tanto complicati da risultare ostici.

Che ne dite? Aspetto il vostro feedback nei commenti.

Bibliografia

Libri

Fitzgerald, Introducing Regular Expressions (O’Reilly 2012).
Goyvaerts, Regular Expressions Cookbook, 2a edizione (O’Reilly 2012).
López, Romero, Mastering Python Regular Expressions (Packt 2014).

Tutorial

RegexOne: learn regular expressions with simple, interactive exercises.
Regular-Expressions.info: the premier website about regular expressions.
Regex Tutorial: from regex 101 to advanced regex.
Guida alla sintassi delle espressioni regolari (con esempi).
Guida alle espressioni regolari (regex).
Using Grep & Regular Expressions to Search for Text Patterns in Linux.
Sculpting text with regex, grep, sed, awk, emacs and vim.

Servizi online

regex101: an online regex tester and debugger.
Debuggex, an online visual regex tester.
RegExr: learn, build, & test regex.

Compleanno con permessi

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

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

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

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

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

Introduzione

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

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

Me li do io i permessi

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

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

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

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

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

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

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

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

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

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

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

$ nano cambia_permessi

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

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

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

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

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

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

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

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

$ cat cambia_permessi

che dovrebbe mostrare sullo schermo lo script appena inserito.

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

$ chmod u+x cambia_permessi

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

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

$ ~/bin/cambia_permessi

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

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

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

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

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

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

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

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

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

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

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

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

Nota finale

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

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

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

Duecento

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

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

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

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

$ cd ~/cartella/del/blog/

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

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

$ ls 20*.md | wc

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

La risposta del Terminale è

201     202    8704

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

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

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

Per cercare il file in questione, eseguo questa volta

$ ls 20*.md | grep " "

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

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

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

$ ls 20*.md | wc
     201     201    8704

e questa volta ottengo il risultato che mi aspetto.

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

$ cat 20*.md

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

$ cat 20*.md | less

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

$ cat 20*.md | wc
   10639  113141  836099

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

Ogni post è quindi composto in media da

$ echo "113183 / 200" | bc
565

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

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

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

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

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

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

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

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

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

Eseguendo il comando così modificato,

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

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

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

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

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

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

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

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

Input, un font per programmare

Thu, 24 Mar 2016 06:00:00 +0000

Di font non capisco niente, distinguo a malapena Arial da Times Roman. Ho provato a leggere gli articoli di Nick Keppol su San Francisco, il nuovo font di sistema di Apple Watch e delle versioni più recenti di OS X e iOS (sia la prima che la seconda parte), ma ammetto di averci capito ben poco.

Ammetto anche di non riuscire a cogliere appieno il legame fra la leggibilità di un font e le sue caratteristiche tecniche. Per fortuna non faccio il grafico, e quindi va benissimo così.

Però la letture delgli articoli di Nick Keppol mi è stata utilissima lo stesso, perché mi ha fatto scoprire, Input, un font monospaziato gratuito, particolarmente adatto non solo per chi programma, ma anche per tutti coloro che preferiscono scrivere con un editor, magari perché usano LaTeX o Markdown.

Io ormai lo uso sempre più spesso, alternandolo ai miei font preferiti, Menlo, Consolas e soprattutto Inconsolata.

Il bello di Input è che, prima di scaricarlo, può essere configurato a piacere. Alcune opzioni mi sembrano particolarmente utili, come la possibilità di definire la forma della “l” (odio la l che si confonde con la i), dello zero o delle parentesi graffe, con l’anteprima immediata del risultato direttamente nel browser.

Decisamente consigliato!

Due anni

Fri, 18 Dec 2015 06:00:00 +0000

Oggi il blog festeggia il secondo compleanno. Sono riuscito a ricordarmene, anche se purtroppo negli ultimi mesi ho avuto veramente poco tempo da dedicarvi.

Mi fa molto piacere che quest’anno il numero degli accessi sia raddoppiato rispetto al 2014 e che si mantenga abbastanza costante nel corso delle settimane e dei mesi. Significa che gli articoli durano nel tempo e vengono letti anche dopo parecchi mesi dalla pubblicazione.

La metà dei visitatori è costituita da lettori fedeli, che ricevono gli aggiornamenti via email o visitano il blog periodicamente. Li ringrazio tutti per l’attenzione e la pazienza, a volte la pubblicazione dei nuovi post è veramente troppo aleatoria.

L’altra metà ci arriva tramite i motori di ricerca. Praticamente solo Google, ma ci sono anche una ventina di accessi rispettivamente da Bing o Yahoo e perfino qualcuno che ha usato Libero, Virgilio o DuckDuckGo.

Anche la distribuzione geografica degli accessi è piuttosto interessante. Come è ovvio la stragrande maggioranza proviene dall’Italia e dalla Svizzera (italiana?), ma ci sono centinaia di visite dagli USA e dai principali paesi europei, nell’ordine Regno Unito, Francia, Germania e Spagna.

Ci sono comunque visitatori da quasi tutto il mondo. Mancano solo i paesi dell’Africa centrale, il Medio Oriente e la Cina. Quasi un miliardo e mezzo di abitanti ma nessun cinese interessato al blog, forse mi devo preoccupare. ;)

[caption id=“attachment_2277” align=“aligncenter” width=“605”] Distribuzione geografica degli accessi al blog nel 2015.[/caption]

Non trovo le parole

Fri, 04 Dec 2015 06:00:00 +0000

Non trovo le parole per descrivere al meglio questo sito (e la tecnologia che c’è dietro).

Le animazioni sono realistiche, lo scroll velocissimo e naturale, tutto succede nel browser senza pause o impuntature. Perfino la musica, anche se ripetitiva, è affascinante.

Altro che Flash, qui si dimostra al meglio la potenza e la flessibilità dell’HTML5. Questo è il futuro.

Programmare l'inutilità

Mon, 23 Nov 2015 06:00:00 +0000

Come tanti ricevo ogni giorno una o più email che mi propongono di visitare questo o quel sito. Non è sempre tempo perso, spesso si trovano delle vere e proprie gemme.

Altre volte però scopro siti o applicazioni la cui utilità è perlomeno dubbia.

img2css

La palma del programma più inutile degli ultimi mesi vorrei assegnarla a img2css, una applicazione web scritta in JavaScript che converte una immagine bitmap (in formato png, jpg o simili) in un file CSS, che può qundi essere inserito direttamente in una pagina web.

In teoria l’idea è ottima, perché permette di integrare un’immagine in una pagina web senza bisogno di collegamenti a file esterni, ma nella pratica fallisce miseramente.

Anche con immagini semplicissime il file CSS generato diventa di dimensioni abnormi, ed è molto più pesante da gestire e da trasmettere in rete rispetto all’immagine originale.

Proviamo img2css

Proviamo ad usare img2css con una immagine semplicissima composta da un quadrato di 10x10 pixel con bordo nero e interno bianco. L’immagine si può creare da Terminale tramite convert, uno dei comandi più potenti di ImageMagick, in grado non solo (come dice il nome) di convertire le immagini da un formato grafico all’altro, ma anche di generare delle immagini ex-novo in praticamente qualunque formato conosciuto.

Il comando

	$ convert -size 10x10 xc:white -fill white \
	-stroke black -draw "rectangle 0,0 9,9" square_10x10.png

produce l’immagine , che occupa esattamente 127 byte (per maggiore chiarezza l’immagine è visualizzata al doppio della dimensione originale).

Convertendo l’immagine con img2css, il codice CSS corrispondente

<div style="height:1px;width:1px;box-shadow:#000 0 0, #000 1px 0, #000 2px 0, #000 3px 0, #000 4px 0, #000 5px 0, #000 6px 0, #000 7px 0, #000 8px 0, #000 9px 0, #000 0 1px, #000 1px 1px, #000 2px 1px, #000 3px 1px, #000 4px 1px, #000 5px 1px, #000 6px 1px, #000 7px 1px, #000 8px 1px, #000 9px 1px, #000 0 2px, #000 1px 2px, #fff 2px 2px, #fff 3px 2px, #fff 4px 2px, #fff 5px 2px, #fff 6px 2px, #fff 7px 2px, #000 8px 2px, #000 9px 2px, #000 0 3px, #000 1px 3px, #fff 2px 3px, #fff 3px 3px, #fff 4px 3px, #fff 5px 3px, #fff 6px 3px, #fff 7px 3px, #000 8px 3px, #000 9px 3px, #000 0 4px, #000 1px 4px, #fff 2px 4px, #fff 3px 4px, #fff 4px 4px, #fff 5px 4px, #fff 6px 4px, #fff 7px 4px, #000 8px 4px, #000 9px 4px, #000 0 5px, #000 1px 5px, #fff 2px 5px, #fff 3px 5px, #fff 4px 5px, #fff 5px 5px, #fff 6px 5px, #fff 7px 5px, #000 8px 5px, #000 9px 5px, #000 0 6px, #000 1px 6px, #fff 2px 6px, #fff 3px 6px, #fff 4px 6px, #fff 5px 6px, #fff 6px 6px, #fff 7px 6px, #000 8px 6px, #000 9px 6px, #000 0 7px, #000 1px 7px, #fff 2px 7px, #fff 3px 7px, #fff 4px 7px, #fff 5px 7px, #fff 6px 7px, #fff 7px 7px, #000 8px 7px, #000 9px 7px, #000 0 8px, #000 1px 8px, #000 2px 8px, #000 3px 8px, #000 4px 8px, #000 5px 8px, #000 6px 8px, #000 7px 8px, #000 8px 8px, #000 9px 8px, #000 0 9px, #000 1px 9px, #000 2px 9px, #000 3px 9px, #000 4px 9px, #000 5px 9px, #000 6px 9px, #000 7px 9px, #000 8px 9px, #000 9px 9px;"></div>

occupa 1259 byte, circa 10 volte in più del file png di partenza. Le cose peggiorano rapidamente se si usano immagini più complesse. Questa immagine da 20x20 pixel , composta da alcuni rettangoli concentrici colorati e generata tramite

$ convert -size 20x20 xc:white -fill white \
-stroke black  -draw "rectangle 0,0 19,19" \
-stroke red    -draw "rectangle 2,2 17,17" \
-stroke green  -draw "rectangle 4,4 15,15" \
-stroke blue   -draw "rectangle 6,6 13,13" \
-stroke yellow -draw "rectangle 8,8 11,11" concentric_color.png

occupa solo 481 byte in formato png, che diventano ben 6.491 byte quando di converte l’immagine in CSS con img2css.

Con immagini reali a colori, o peggio ancora fotografie (ad esempio questa), le immagini CSS possono diventare anche 150-200 volte più grandi di quella originale, mettendo in ginocchio il browser (e il computer!) durante il processo di conversione o quando si copia il file CSS ottenuto in una pagina web.

Provare per credere, ma se poi il Mac si pianta non prendetevela con me.

Dentro il codice

Il programma img2css è molto semplice ed è composto poche centinaia di linee di codice JavaScript. Ma è perfino troppo lungo per quello che fa.

In fondo si tratta solo di determinare il codice RGB di ogni pixel dell’immagine, convertirlo in formato esadecimale ed associarlo alle coordinate orizzonantali e verticali del pixel considerato.

Ogni pixel viene quindi convertito nella sequenza #AAA Xpx Ypx, dove #AAA indica il colore in esadecimale (la stringa può essere composta da 3 o 6 numeri a seconda del colore RGB determinato) e Xpx Ypx indicano le coordinate orizzonantali e verticali del pixel.

Tutto questo si può fare tranquillamente da Terminale, con poche righe di codice ben piazzate.

img2css da Terminale

Per convertire un file grafico in una sequenza di colori RGB si può usare ancora convert di ImageMagick,

$ convert square_10x10.png -compress none square_10x10.ppm

ottenendo un file in formato ppm, in cui ciascun pixel dell’immagine è rappresentato da tre numeri interi decimali, corrispondenti ai tre colori RGB del pixel stesso (il formato grafico ppm è molto inefficiente, ma è utilissimo dal punto di vista didattico perché mostra chiaramente come è fatto un file grafico).

Le sequenze di tre numeri decimali sono disposte per righe orizzontali a partire dalla quarta riga del file. Le prime tre righe contengono rispettivamente il numero magico che definisce il tipo di file, le dimensioni dell’immagine in pixel e il valore massimo del colore RGB del file.

La rappresentazione in formato ppm del quadrato di 10x10 pixel con bordo nero e interno bianco mostrato sopra è

P3
10 10
255
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 
0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 
0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 
0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 
0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 
0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Sequenze di dati come questa possono essere facilmente analizzate e trasformate tramite awk, uno dei tanti potenti strumenti specifici disponibili nei sistemi operativi basati su Unix.

Basta uno script awk di poche righe per convertire le informazioni RGB decimali contenute nel file ppm in formato esadecimale

#!/usr/bin/awk -f

/^255/  { while (getline == 1)
          { for (i = 1; i <= NF; i += 3)
              printf "0x%02X%02X%02X ", $i, $(i+1), $(i+2);
              printf "\n"
          }
        }

Eseguendo lo script img2css.awk sul file ppm precedente si ottiene

$ ./img2css.awk square_10x10.ppm 
0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 
0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 
0x000000 0x000000 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0x000000 0x000000 
0x000000 0x000000 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0x000000 0x000000 
0x000000 0x000000 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0x000000 0x000000 
0x000000 0x000000 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0x000000 0x000000 
0x000000 0x000000 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0x000000 0x000000 
0x000000 0x000000 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0xFFFFFF 0x000000 0x000000 
0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 
0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000 0x000000

Per riprodurre l’output prodotto da img2css, è sufficiente modificare leggermente il modo in cui lo script stampa i valori dei colori RGB, aggiungere la stampa della le coordinate di ciascun pixel e inserire le parti iniziali e finali del tag <div>, ottenendo

#!/usr/bin/awk -f

BEGIN   { out = sprintf("<div></div>");
          print out;
        }

che produce un output equivalente a quello di img2css

$ ./img2css_v2.awk square_10x10.ppm
<div style="height:1px;width:1px;box-shadow:#000000 0 0px, #000000 1px 0px, #000000 2px 0px, #000000 3px 0px, #000000 4px 0px, #000000 5px 0px, #000000 6px 0px, #000000 7px 0px, #000000 8px 0px, #000000 9px 0px, #000000 0 1px, #000000 1px 1px, #000000 2px 1px, #000000 3px 1px, #000000 4px 1px, #000000 5px 1px, #000000 6px 1px, #000000 7px 1px, #000000 8px 1px, #000000 9px 1px, #000000 0 2px, #000000 1px 2px, #FFFFFF 2px 2px, #FFFFFF 3px 2px, #FFFFFF 4px 2px, #FFFFFF 5px 2px, #FFFFFF 6px 2px, #FFFFFF 7px 2px, #000000 8px 2px, #000000 9px 2px, #000000 0 3px, #000000 1px 3px, #FFFFFF 2px 3px, #FFFFFF 3px 3px, #FFFFFF 4px 3px, #FFFFFF 5px 3px, #FFFFFF 6px 3px, #FFFFFF 7px 3px, #000000 8px 3px, #000000 9px 3px, #000000 0 4px, #000000 1px 4px, #FFFFFF 2px 4px, #FFFFFF 3px 4px, #FFFFFF 4px 4px, #FFFFFF 5px 4px, #FFFFFF 6px 4px, #FFFFFF 7px 4px, #000000 8px 4px, #000000 9px 4px, #000000 0 5px, #000000 1px 5px, #FFFFFF 2px 5px, #FFFFFF 3px 5px, #FFFFFF 4px 5px, #FFFFFF 5px 5px, #FFFFFF 6px 5px, #FFFFFF 7px 5px, #000000 8px 5px, #000000 9px 5px, #000000 0 6px, #000000 1px 6px, #FFFFFF 2px 6px, #FFFFFF 3px 6px, #FFFFFF 4px 6px, #FFFFFF 5px 6px, #FFFFFF 6px 6px, #FFFFFF 7px 6px, #000000 8px 6px, #000000 9px 6px, #000000 0 7px, #000000 1px 7px, #FFFFFF 2px 7px, #FFFFFF 3px 7px, #FFFFFF 4px 7px, #FFFFFF 5px 7px, #FFFFFF 6px 7px, #FFFFFF 7px 7px, #000000 8px 7px, #000000 9px 7px, #000000 0 8px, #000000 1px 8px, #000000 2px 8px, #000000 3px 8px, #000000 4px 8px, #000000 5px 8px, #000000 6px 8px, #000000 7px 8px, #000000 8px 8px, #000000 9px 8px, #000000 0 9px, #000000 1px 9px, #000000 2px 9px, #000000 3px 9px, #000000 4px 9px, #000000 5px 9px, #000000 6px 9px, #000000 7px 9px, #000000 8px 9px, #000000 9px 9px;"></div>

perfettamente funzionante, come si può verificare inserendo pari pari il tag <div> ottenuto in un documento html (come questo):

Conclusioni

È chiaro che usare convert ed awk non risolve il problema di fondo, le immagini CSS generate rimangono comunque molto più grosse di quelle originali, ma almeno sono prodotte con poche righe di codice ed usando solo degli strumenti standard di Unix.

Alcuni anni fa si parlava in senso negativo di bloatware, di quei programmi inutilmente grossi e tanto poco ottimizzati da richiedere grosse risorse hardware anche per svolgere funzioni relativamente semplici.

A volte i programmatori dimenticano due concetti fondamentali della buona programmazione, cercare la semplicità e usare lo strumento più adatto per il compito specifico, e si perdono in inutili (e stucchevoli) esercitazioni di stile. Succede a chi propone banalmente di usare file CSS enormi al posto di semplici immagini grafiche, ma succede anche in tanti altri casi ben peggiori.

A parte questo, il post è stato anche un’occasione per parlare di awk, uno strumento poco conosciuto ma molto otente, in particolare quando si tratta di analizzare e trasformare dati contenuti in file di testo.

Uno strumento che è diventato parte integrante da anni della mia routine di lavoro quotidiana. Sarebbe bello poterne riparlare.

La settimana di Python

Tue, 13 Oct 2015 18:00:00 +0000

La solita Packt sta celebrando da ieri la settimana di Python, nel corso della quale offrirà uno sconto del 20% sui suoi libri su Python e un volume gratuito al giorno sull’argomento.

Python è a mio modesto parere il linguaggio di programmazone più interessante che ci sia in giro, facile da imparare ma anche veloce, potente ed estensibile. Un aspetto non trascurabile è che può essere utilizzato sia in modo procedurale, come il Fortran o il C, che nella più moderna modalità ad oggetti (e perfino in modo misto), rendendo più semplice padroneggiare i concetti, piuttisto astrusi a dire il vero, della programmazione orientata agli oggetti.

Non voglio fare sempre pubblicità a Packt, ma trovo molto lungimirante la sua politica di offrire gratis tanti volumi stimolanti e che coprono uno spettro di interessi molto vasto. Prendi quelli gratis ma prima o poi qualcuno lo compri pure.

Mi sembra una occasione da non farsi sfuggire.