Awk on Melabit

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

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

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.

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

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

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

Come orientarsi in questa moltitudine?

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

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

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

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

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

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

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

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

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

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