Shell on Melabit

Script per tutti i giorni: shell e parametri

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

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

Una casa per i programmi

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

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

$ cd ~
$ mkdir Development

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

Volendo potremmo anche eseguire semplicemente

$ mkdir ~/Development

che crea la directory desiderata con un unico comando.

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

Andare con le proprie gambe

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

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

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

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

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

$ cd ~/Development

ed eseguiamo lo script con il comando

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

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

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

$ bash convert_title.sh

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

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

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

$ chmod u+x convert_title.sh

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

$ chmod u-x convert_title.sh`

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

$ chmod a+x convert_title.sh

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

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

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

Dato che qui usiamo bash, il nostro script diventa

#!/bin/bash

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

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

$ which bash
/bin/bash

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

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

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

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

Parametri sulla linea di comando

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

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

#!/bin/bash

string=$1

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

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

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

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

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

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

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

Conclusioni (per ora)

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

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

Revisioni

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

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

Script per tutti i giorni: 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. ↩︎