Bbedit on Melabit

Fare una Maggie

Mon, 28 Jul 2025 06:00:00 +0000

L’ultimo articolo mi ha fatto letteralmente impazzire. Non per la lunghezza, anche se scrivere un testo di più di tremila parole e ventimila caratteri in due lingue diverse non è una sciocchezza.

Il vero problema è nato dal fatto che a un certo punto il file Markdown dell’articolo si è corrotto. Quando Hugo provava a convertirlo in HTML, il file generato conteneva, al posto delle lettere accentate italiane, il carattere di sostituzione �, quel rombo nero con dentro un punto interrogativo bianco che abbiamo visto in tante email e pagine web.

Ci ho perso ore prima di risolvere il problema.

Quando un file Markdown si corrompe

La prima ipotesi è stata che il file contenesse qualche carattere spurio, come uno spazio che non è davvero uno spazio, oppure una di quelle lettere strane che qualche anno fa hanno creato un certo scompiglio. Un bel problema cercarle nel testo, per cui ho fatto il contrario e ho scritto una espressione regolare che cercasse tutto ciò che non era normale, raffinandola via via che procedevo.

Alla fine l’espressione regolare è diventata questa.

[^a-zA-Z0-9àèéìòùÀÈÉÌÒÙ ,.;:`'"()\[\]\-^/_*#\n]

Una cosa molto terra-terra, ma l’importante è che funzionasse. Purtroppo non ha trovato niente di strano.

Per cercare di restringere il più possibile l’area che poteva contenere l’errore, ho iniziato a togliere parti di testo, prima poche righe e poi intere sezioni, ricompilando ogni volta il file tagliuzzato con Hugo. Niente, non c’era verso di togliere quegli stramaledetti rombi neri!

E qui ho fatto la cosa davvero decisiva: dopo aver provato e riprovato senza successo, ho lasciato perdere e sono andato a cena.

Sì, perché quando non si riesce a risolvere un problema – che sia risolvere un difficile esercizio di matematica, far funzionare un programma o scrivere l’attacco di quel post che ci frulla in testa da ore – la cosa migliore da fare è lasciare perdere e dedicarsi ad altro. Non so voi, ma con me funziona sempre alla grande.

E dopo cena mi è venuta l’idea: ho fatto una Maggie e tutto è andato a posto.

– Immagine generata da Google Gemini.

Fare una Maggie

Maggie è il diminutivo di Margaret Secara, diventata famosa per un trucco, semplice ma molto efficace, per recuperare un documento Word corrotto: cliccare sull’icona ¶ della Barra Multifunzione di Word per attivare la visualizzazione dei caratteri di formattazione (se la finestra di Word è stretta, l’icona potrebbe nascondersi all’interno della sezione dedicata ai paragrafi), poi selezionare tutto il testo tranne l’ultimo carattere di Invio (come mostrato in figura) e incollarlo in un nuovo documento vuoto.

Se non funziona, si può ripetere il procedimento copiando parti successive del testo in un nuovo documento, in modo da circoscrivere il più possibile la porzione corrotta.

La prima volta che ho usato questo trucco stavo lavorando su un documento di più di cento pagine, passato per parecchi colleghi e differenti versioni di Word, che era diventato ingestibile: ogni nuovo carattere impiegava secondi per comparire sullo schermo e Word andava continuamente in crash. Con la procedura descritta ho risolto il problema in un battibaleno.¹

Il trucco di Maggie funziona perché i file Word hanno una doppia struttura. La prima è quella che mostrata sullo schermo del computer, fatta di testo, immagini e tabelle, con divisioni in capitoli, sezioni e paragrafi, con grassetti, italici, sottolineature, con interruzioni di pagina, liste, rientri, tutte cose messe lì un po’ a casaccio dall’utente.

La seconda struttura è quella del file XML sottostante, che dopo un po’ di aggiunte, correzioni, cancellazioni, ripensamenti, diventa un fritto misto di tag XML innestati uno sull’altro, che rimangono però sempre invisibili all’utente e non vengono mai ripuliti e ristrutturati in modo coerente dal programma.

A meno di non farlo noi a mano, copiando tutto il testo in un nuovo documento, ma evitando come la peste l’ultimo carattere di Invio che, per qualche motivo arcano, contiene la chiave di accesso alle porcherie nascoste del documento Word.

Margaret Maggie Secara avrà scoperto questo trucco per caso, ma si è rivelato così utile da trasformare il suo soprannome in una parola vera e propria, come Kleenex, Band-Aid, Post-It, Tupperware o Google.

Ma sono documenti di testo!

Però i miei post li scrivo in Markdown, mica con Word. Ma anche così, ripartire da un documento fresco e copiarci dentro il contenuto di quello corrotto può rivelarsi il metodo più veloce per risolvere tanti problemi.

Ovviamente il trucco funziona con qualunque tipo di documento in testo puro, che sia scritto in Markdown, LaTeX, HTML, XML, JSON, Org mode… o in qualsiasi altro formato più o meno arcano che vi venga in mente.

Anzi, proprio perché, a differenza di Word, un documento di testo non nasconde nulla all’utente, non serve nemmeno evitare di copiare l’ultimo carattere di Invio; si può selezionare tranquillamente tutto il testo, copiarlo e incollarlo in un nuovo file vuoto.

Prima di farlo è sempre bene controllare che il testo non contenga dei caratteri spuri, utilizzando una espressione regolare simile a quella riportata più sopra.

E con questo l’articolo è finito. Le due sezioni qui sotto sono riservate solo ai più curiosi, che vogliono sapere cosa mi era successo davvero.

Solo per i più curiosi…

Perché il metodo funziona?

Una volta risolto il problema immediato, la curiosità ha avuto il sopravvento e mi sono chiesto perché il metodo descritto funziona con i documenti di testo. Come succede spesso, lavorare dal Terminale aiuta a risolvere i problemi più spinosi.

In un normale editor come BBedit o TextMate, il file corrotto appare perfettamente normale, ma se lo si visualizza nel Terminale con cat, si nota subito che tutti i caratteri accentati vengono sostituiti da dei ?, più o meno come succede convertendolo in HTML.

Il comando file dà poi la risposta definitiva. Se lo applico al file corrotto, file 2025-07-22-macos-tahoe-developer-beta-3.md, ottengo in risposta

Non-ISO extended-ASCII text, with very long lines (1264)

mentre con un qualunque altro file Markdown il risultato è (come è giusto che sia)

Unicode text, UTF-8 text, with very long lines (1264)

In altri termini, il file aveva perso la codifica UTF-8, trasformandosi in un generico file di testo non-standard.

Se me ne fossi accorto prima, avrei potuto usare iconv per correggere la codifica del file, ma in questo caso non c’è dubbio che il copia-e-incolla è molto più pratico.

Cos’è successo davvero?

Difficile a dirsi, ma ci sono degli indizi. Dato che l’articolo era molto lungo, l’ho scritto in più riprese un po’ sul Mac Mini e un po’ sull’Air.

In genere copio i file di lavoro in locale e li sincronizzo solo in un secondo momento. Ma questa volta cambiavo continuamente computer, per cui ho preferito lavorare direttamente sulla cartella sincronizzata (usando Syncthing, ma non credo che sia stato lui il responsabile; in quel caso avrei trovato dei file in conflitto, che invece non ci sono). Invece ci sono stati ogni tanto dei problemi di rete, e penso che sia stato proprio questo che ha finito per corrompere la codifica del file.

La morale? Lavorare in locale e sincronizzare solo quando si è finito. Oppure lavorare direttamente in rete solo quando il collegamento è stabile.

Ma quando non si può, meglio ricordarsi dei consigli della buona vecchia Maggie.

Pare che si possa recuperare un documento Word senza perdere traccia delle modifiche effettuate. La guida usa delle combinazioni di caratteri tipiche di Word per Windows, e quindi non è immediato applicarla alla versione per macOS. ↩︎

SubEthaEdit, scrivere insieme in tempo reale

Mon, 30 Oct 2023 06:00:00 +0000

– Fonte: Annie Spratt su Unsplash.

SubEthaEdit è in giro da un bel po’ di tempo, se la memoria non mi inganna più o meno dai tempi di Tiger.¹ Quando uscì fece scalpore, perché per la prima volta dava la possibilità a più utenti di lavorare contemporaneamente allo stesso documento, con il limite che tutti i Mac dovevano essere connessi alla stessa rete locale.

Oggi, fra Office 365, Teams, Google Documents (e naturalmente Overleaf), scrivere un testo in collaborazione fra vari utenti sparsi nel mondo sembra una cosa scontata,² ma 20 anni fa era una funzione mai vista prima su un computer personale.

Infatti, secondo uno degli autori, la scrittura collaborativa di un testo è stata inventata intorno alla metà degli anni ‘90 presso il solito Xerox PARC, ma fino a SubEthaEdit nessuno aveva pensato di applicarla ad un prodotto commerciale.

L’editor

SubEthaEdit (SEE per gli amici) è un editor di testo puro, proprio come TextMate, BBEdit, Sublime Text o il defunto Atom, ormai soppiantato da Visual Studio Code.³

SEE ha tutte le funzioni di base di un editor moderno, riconosce la sintassi dei principali linguaggi di programmazione (tranne R, accidenti!), così come di Markdown e di LaTeX, e può essere configurato in modo abbastanza dettagliato, per adattarsi al meglio ai gusti personali.

A questo proposito, io preferisco visualizzare i caratteri nascosti (Show: Invisible Characters) e sostituire i tab con gli spazi (una abitudine da programmatore). Entrambe le modifiche si fanno nel pannelo Editing delle Preferenze di SEE. Mi piace anche ingrandire leggermente il font di default a 12 punti e aumentare la spaziatura fra le linee al 110% per rendere il testo più leggibile e più consistente con gli altri editor che uso (pannello Styles).

Rispetto ai mostri sacri citati prima, SEE manca di parecchie funzioni, fra cui alcune che ormai fanno parte del normale corredo di un editor moderno, come la possibilità di commentare rapidamente un blocco di codice, di aggiungere delle parentesi aperte e chiuse oppure dei simboli attorno ad un blocco di testo selezionato,⁴ oppure di effettuare una selezione per colonne, utile in particolare quando si lavora con le tabelle.⁵

SEE non ha nemmeno il completamento automatico del codice ma insomma, questa è una funzione supportata solo dagli editor più avanzati, quindi è un peccato veniale. Anche gli stili, i temi, o come volete chiamarli, sono pochi, ma almeno per me, che uso quasi sempre lo stile di default, questo è un non-problema.

Peccato anche che non metta in evidenza automaticamente gli errori ortografici, ma che io sappia questo lo fa nativamente solo BBEdit ed è uno dei motivi per usarlo per scrivere dei testi in Markdowno o LaTeX.

Molto utile, invece, la possibilità di avere visualizzazioni diverse dello stesso documento sia nella stessa finestra che in finestre separate, così come il conteggio in tempo reale del numero di caratteri, parole o linee di cui è composto un documento, una funzione che mi avrebbe aiutato moltissimo qualche mese fa.

Per averlo, bisogna attivare dal menu View la visualizzazione della barra di stato superiore e inferiore (che servirà fra poco), che riportano una serie di informazioni utili sul documento aperto fra cui, a destra della barra di stato superiore, proprio il numero di caratteri, parole o linee del documento. Cliccando sul numero si può cambiare ciclicamente il tipo di conteggio riportato.

Scrittura collaborativa

La caratteristica più interessante di SSE è il supporto nativo per la scrittura collaborativa, che permette a due o più utenti collegati alla stessa rete locale di lavorare contemporaneamente allo stesso documento.

Prima di condividere un documento bisogna aprire il pannello Collaboration delle Preferenze di SEE e assicurarsi di aver attivato l’opzione relativa (Enable Collaboration) e di non essere invisibili agli altri utenti della rete (Invisible to others on the Network).

È sufficiente ora cliccare sull’icona in basso a destra nella barra di stato (quella che assomiglia al simbolo del Wi-Fi ruotato) per rendere il documento disponibile agli altri utenti della rete. Questa circostanza viene indicata in modo evidente nella stessa barra di stato, dove compare una grossa icona colorata con le iniziali dell’utente che ha iniziato la condivisione. Per differenziare meglio i vari utenti è possibile personalizzare l’icona ed il colore associato a ciascun utente nel solito pannello Collaboration delle Preferenze, come si può vedere nelle due immagini qui sotto.

A questo punto, se un altro utente esegue SubEthaEdit su un Mac collegato alla stessa rete locale, potrà accedere non solo alla lista dei suoi documenti locali più recenti, ma anche a quelli condivisi su cui può collaborare.

Per farlo, dovrà cliccare sul nome del documento condiviso e aspettare di essere autorizzato a modificare o eventualmente soltanto a leggere il documento in questione, potendo così iniziare la sua attività di scrittura a quattro (o più) mani.

Anche la barra di stato di SEE cambierà, mostrando le icone dei due (o più) utenti che stanno lavorando in contemporanea, con i colori associati a ciascun utente.

Questi colori sono fondamentali, perché permettono di valutare a colpo d’occhio chi ha effettuato ciascuna modifica. È anche possibile lavorare sulla stessa porzione di testo, correggendo e integrando ciò che ha scritto l’altro.

SEE non ha problemi nemmeno quando si prova a scrivere in contemporanea esattamente nello stesso punto, ma si limita ad inserire entrambi i caratteri, differenziandoli in base all’utente. Per quanto ci abbia provato non sono mai riuscito a mandarlo in crash con giochetti di questo tipo.

In alternativa alla trafila di condivisione descritta prima, è anche possibile invitare esplicitamente a collaborare un altro utente che ha già aperto SEE sul suo Mac.

Inoltre, cliccando con il tasto destro del mouse sull’icona simil-Wi-Fi in basso a destra, è possibile definire a priori se il documento su cui si sta lavorando è modificabile dagli altri utenti, solo leggibile oppure è bloccato. In quest’ultimo caso non viene condiviso in rete e potrà essere modificato solo in locale.

Insomma, le possibilità non mancano, ed anche se ormai dovremmo essere abituati a lavorare in rete sullo stesso file, qui tutto si svolge in modo molto fluido e intuitivo. Peccato solo per il limite della rete locale e per il fatto che SEE giri solo su macOS, due fattori che rendono il programma utile solo ad un numero piuttosto ristretto di utenti.

Conclusioni

SubEthaEdit è un discreto editor di testo per macOS, che diventa insostituibile quando si ha bisogno di utilizzare le sue funzioni di scrittura collaborativa. Devo ammettere, però, che finora ho sempre preferito i suoi fratelli maggiori, in particolare TextMate e BBEdit.

Ma ultimammente ho scoperto una funzione piccola-piccola e molto specialistica di questo programma che, quando serve, si dimostra davvero insostituibile. Però di questo ne parlerò la prossima volta.

Mi sono sbagliato di poco, secondo Wikipedia la prima versione di SubEthaEdit risale ai tempi di Panther (Mac OS X 10.3), il sistema operativo immediatamente precedente a Tiger (10.4). ↩︎
Ma conosco fin troppi utenti rimasti ancorati allo scambio via email di una sequenza interminabile di documento_v1.docx,documento_v2.docx, documento_v2b.docx, documento_v2b_ultima_versione.docx, seguiti inevitabilmente da documento_v2b_straultimissima_versione.docx e da documento_v2b_sara_la_volta_buona.docx ↩︎
Chi rimpiange Atom può provare Pulsar, un fork open source di Atom che aspira ad essere una versione migliorata e più moderna del genitore, ma che su macOS ha sembra avere ancora problemi di prestazioni. ↩︎
Con gli altri editor quando scrivo in Markdown sono abituato a selezionare un blocco di testo e a scrivere _ o ** per circondarlo con i tag che lo fanno visualizzare rispettivamente in italico o in grassetto. Con SEE non funziona e questa mancanza mi ha fatto penare durante la scrittura di questo articolo. ↩︎
Ho proposto di aggiungere queste funzioni sul repository GitHub del programma ma finora non ho ricevuto alcun feedback dagli sviluppatori. Vedo anche che la maggior parte delle richieste rimangono inascoltate ed è probabile che la mia farà la stessa fine. ↩︎

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