Categoria: bash

Bash: a spasso tra le directory.

La mia home directory è piena zeppa di cartelle e sottocartelle, immagino anche la vostra, perchè preferisco perdere i miei file in una gerarchia ben ordinata di cartelle che mi dia l’illusione, almeno finché non li cerco, che sia facile ritrovare i dati che mi servono.

Per chi utilizza principalmente l’interfaccia grafica la cosa può anche funzionare per chi invece consuma la tastiera e risparmia il mouse spesso questa scelta significa digitare path chilometrici.

Non più. Directory dai nomi lunghi? Path complicati da digitare? $CDPATH è la soluzione a tutti i vostri problemi. Non previene la caduta dei capelli, questo no, ma vi permetterà di risparmiare qualche decina di migliaia di battiture all’anno. I polpastrelli delle vostre dita ve ne saranno grati e voi passerete più piacevolmente il vostro tempo alla tastiera.

Non c’è neanche bisogno di installare pacchetit esoterici, tutto quello che dovrete fare è aggiornale la configurazione di bash.

Continua a leggere “Bash: a spasso tra le directory.”

Cavare una copertina da un file pdf

Se anche non si riesce a cavare sangue da una rapa, sicuramente è possibile creare un file immagine che rappresenti la copertina di un libro in pdf. Avendo cominciato a segnalare ebook da scaricare gratuitamente e legalmente ho dovuto imparare a creare, o estrarre delle immagini dai loro pdf per creare le copertine che accompagnano i post.

Ci sono diversi sistemi per risolvere il problema e ne vedremo alcuni, da quelli più alla portata di tutti ad altri, più comodi ma che necessitano di un terminale, che sono ugualmente alla portata di chiunque, sempre che chiunque ne sia a conoscenza o che lo scopra per errore. 🙂

Continua a leggere “Cavare una copertina da un file pdf”

Libri da scaricare: Bash scripting avanzato

Bash Scripting Avanzato
Bash Scripting Avanzato

Tutto quello che non avete mai osato chiedere sulla programmazione bash. Questo manuale, parliamo di più di ottocento pagine (nell’ultima versione in lingua originale), ha accompagnato spesso le mie nottate insonni, lo so che avrei potuto avere migliore compagnia, ma l’esame di Sistemi Operativi pretende questo ed altro.

A dispetto del titolo non c’è bisogno di alcuna esperienza pregressa, si parte dalle basi della programmazione shell, la programmazione tout court dovrete comunque padroneggiarla, per arrivare a sviscerate tutte le più recondite caratteristiche della bash.

E’ un’altro di quegli ebook da tenere sul desktop e da commentare pesantemente (in tutti i sensi), è un’utile reiferimento a cui attingere quando man bash non basta a risolvere il problema “che ronza nel vostro cervello come un insetto in una coppa di Champagne.”
Continua a leggere “Libri da scaricare: Bash scripting avanzato”

Icone Funzionali

Mettete il caso di dover convertire alcune immagini e di aver deciso di scrivere un post. Oggi vi appesterò con una storia breve sul problema di questa sera ma, siccome scrivere

convert -size 1024×768 *.jpg [1]

non sarebbe stato di grande aiuto, e neanche un gran post, ho pensato di parlare delle icone che stanno alla destra del mio desktop.

Le chiamo icone funzionali perché sono dei lanciatori (launcher) che fanno capo a piccoli programmi bash che mi aiutano in piccoli compiti.
Continua a leggere “Icone Funzionali”

XMLstar: Manipolazione XML a linea di comando

Oggi mi sono imbattuto in una utility interessante: XMLstarlet. Mi ha colpito perché permette di fare, con una discreta velocità, tutto quello che vi può venire in mente con i file xml.

In pratica si tratta di una interfaccia bash verso la libxml2. E’ possibile tra le altre cose, validare, trasformare, selezionare nodi, editare documenti (in batch) formattare e rendere in forma canonica dei documenti xml.

Interessante, ma poco più che una curiosità, il comando ls che rende in xml la directory corrente.

Altra particolarità è la possibilità che offre di passare da formato xml a formato pyx e viceversa. Si tratta di un formato comodo da manipolare con gli strumenti a linea di comando quali ad esempio grep, tail, head e sed che ha la stessa espressività di xml. Chi non ha familiarità con le trasformazioni con le query Xpath, e non volesse spendere tempo a colmare la lacuna, potrà utilizzare strumenti più congeniali per ottenere lo stesso risultato.

Prima di chiudere non mi resta che riportare un’altro link ad un altro rapido tutorial, vecchiotto ma molto valido, sul formato.

Un’ultima cosa: tra la documentazione segnalata troverete riferimento a due programmi xmln e xmlv che non sono altro che il convertitore xml->pyx ed il suo omologo pyx->xml.

Ed ora è davvero tutto.

Basta un click …

… Una spruzzata di pseudo xml e qualche riga di bash per creare applicazioni grafiche.

Stavo pascolando per tutta internet per ingannare il caldo quando mi sono imbattuto in questo programma che, se pur con delle pecche di gioventù mostra buone potenzialità.

Se non volete pasticciare con zenity per dare un’interfaccia grafica ai vostri script bash troverete in BUC una alternativa, a mio parere non altrettanto valida ma sicuramente promettente.

La prospettiva è rovesciata. Se in zenity sono disponibili delle finestre predefinite per interagire con  l’utente, buc vi permette di definire un’interfaccia grafica associando ai controlli degli script bash, che possono anche interagire tra loro. Cuore del sistema sono dei particolari file di configurazione che sul sito ufficiale vengono definiti come file xml.

L’xml di questi file è a dir poco particolare, può, in alcuni casi essere malformato e non passare le verifiche di xmllint. Ho fatto qualche prova perché mi sono stupito quando un piccolo e banale script di hello world non ha prodotto alcun risultato se non una finestra vuota. E’ saltato fuori che avevo saltato un tag e quindi l’xml non poteva essere interpretato correttamente.

L’unico motivo che possa impedire una validazione formale dell’input sarebbe la necessità di dover interpretare file malformati e così ho potuto valutare: le redirezioni vengono interpretate da xmllint come entità e la validazione non va a buon fine. La soluzione di un simile problema potrebbe essere banale, basterebbe inserire gli script con le redirezioni in un elemento CDATA per poter affrontare la validazione. Il programma non lo fa, almeno per ora, anche se lo sforzo per poter inserire questa feature non dovrebbe essere particolarmente importante.

Un altro peccato veniale del progetto è una certa mancanza di coerenza tra i tag, alcuni hanno opzioni specificate come sottoelementi, mentre in altri la stessa opzione viene specificata, per me più naturalmente, come attributo del tag. Mi riferisco agli elemento title dei tag tab ed all’attributo title dell’elemento button.

Altra pecca, l’attributo filter del tag file che può essere multiplo e sarebbe stato espresso più naturalmente come una sequenza di sottoelementi.

A parte questi appunti, che non sono altro che questioni di lana caprina, il progetto è interessante ed è già usabile e ne consiglio il test e l’utilizzo. I ragazzi del Sicilinux stanno facendo un bel lavoro.

Qualche riferimento per approfondire:

Traduzione a linea di comando

Questa mattina mi son svegliato, ed ho trovato un post stuzzicante che promette, e mantiene, di aggiungere alla linea di comando un semplice traduttore. Si tratta di uno script di una riga che si appoggia a http://www.wordreference.com per effettuare la traduzione.

Alla fine del post c’è la richiesta di spendere qualche minuto attorno a google ed al suo sistema di traduzioni per poter fare la stessa cosa.

una prima versione la trovate quì sotto, non si tratta più di un one line script perché ho l’ossessione di aggiungere parametri a tutto il codice che posso manipolare. Mi passerà.

Il codice non è elegantissimo ma più che qualche minuto non potevo assolutamente dedicargli.

#!/bin/bash
S='auto'
T='it'
if [ "$2" != "" ]; then
  S="$2"
fi
if [ "$3" != "" ]; the
  T="$3"
fi

lynx "http://translate.google.com/translate_t?sl=$S&tl=$T&text=$1" -dump | \
     grep "Suggest a better translation" -B2 | head --lines=1

I parametri sono semplicissimi da usare, ammesso di chiamare tran il file, basta invocarlo con la parola da tradurre come unico parametro. Google cercherà di individuare la lingua della parola e ne restituirà, se riesce, il corrispettivo in italiano.

In caso sia necessario allora si possono specificare anche il codice iso della parola da tradurre, ed il codice della lingua in cui tradurre, rispettivamente come secondo e terzo parametro.

Le migliorie possibili sono tante, ad esempio usare l’opzione -source invece che -dump in lynx in modo da essere sicuri di individuare la parola tradotta nell’html che google restituisce ma il tempo, per ora, è tiranno.

Bash: redirigere i file descriptor / 2

Ci siamo lasciati con l’amaro in bocca, vi avevo promesso giocolerie impreviste, si magari avrò anche esagerato, e vi ho lasciato dopo aver appena introdotto gli operatori di redirezione in bash.

Sono qui per rimediare e ci mettiamo subito a lavoro. La volta scorsa abbiamo parlato dei tre file descriptor predefiniti ma avevo anche accennato alla possibilità di avere anche altri file descriptor aperti. Per aprirne uno non bisogna far altro che reindirizzarlo dove meglio ci aggrada.

Per esempio provate a digitare il comando

echo “ciao 12” >&12

Che genererà un messaggio di errore e poi provate a digitare un comando simile ma funzionante (anche se apparentemente inutile)

echo “Il comando di prima non funzionava, questo si” 12>&1 >&12; echo “anche questo non funziona” >&12

Non è inutile perché ci fa capire due cose: che i reindirizzamenti procedono da sinistra a destra e che i file descriptor non standard vengono chiusi al termine dell’esecuzione di un comando/script.

Per inciso, è possibile chiudere esplicitamente un file descriptor utilizzando la sintassi n>&- dove n è il file descriptor da chiudere.

Possiamo anche rendere permanente una redirezione, o l’apertura di un file descriptor utilizzando exec. Questo comando non fa altro che lanciare una shell che sostituisce quella attuale e, nel fare ciò è possibile aprire dei file descriptor o reindirizzarne altri.

Per provare quest’ultima affermazione proviamo a farci uno scherzo. Apriamo due terminali e lanciamo il comando tty che non fa altro che stampare a video lo pseudofile cui è connesso il terminale. Da X troverete che il risultato sarà qualcosa di simile a  /dev/pts/0 ed a /dev/pts/1 per l’altra finestra.

A questo punto in nella prima delle due invochiamo il comando exec >/dev/pts/X dove X deve essere l’id del terminale della seconda finestra e voilà, l’output della vostra prima console andrà a finire tutto nella seconda (ad eccezione dello standard error che non viene influenzato). Per tornare alla normalità bisognerà semplicemente ridare il comando facendo puntare la redirezione alla console legittima.

Vi lascio con un’ultimo trucco:

command 3>&1 1>&2 2>&3

che non fa altro che scambiare tra di loro i file descriptor di standard output e standard error, nel caso servisse.

E questo è tutto, per ora

bash: Redirigere i file descriptor

In un precedente pezzo ho scritto qualche parola su tee e vi raccontavo che la sua principale limitazione era l’impossibilità di registrare quanto stava accadendo sullo standard error. Vista la natura introduttiva del pezzo ho preferito non tediarvi con le giocolerie possibili con i file descriptor e restare concentrato sul comando.

Ora è venuto il momento, nel frattempo ho studiato, di affrontare il problema e fare qualche gioco di prestigio con stderr e stdout. Tutto questo senza l’ausilio di altro che le nostre dita, una tastiera e la nostra amata, odiata,mai indifferente, bash. La carne al fuoco è tanta e quindi ho deciso di dividere il tutto in più parti.

Partiamo con un minuscolo script d’esempio per introdurre i file descriptor ed i comandi di redirezione.

#!/bin/bash
echo "Questo è un messaggio indirizzato allo standard error" 1>&2
echo "Questo è un messaggio indirizzato allo standard output" 1>&1

Non penso ci sia davvero bisogno di spiegare quello che fa 🙂 . Mi preme solamente illustrare la sintassi >&d, ma, prima, parliamo dei file descriptor, che non sono altro che delle astrazioni, dei segnaposto, di file aperti in lettura o scrittura.

Ad ogni programma, anche agli script bash, a voler essere precisi alla shell che esegue lo script, sono associati almeno tre file descriptor: uno per l’input, stdin, uno per l’output, stdout, ed uno, stderr, per la segnalazione degli errori. Hanno, nell’ordine, indice 0, 1 e 2.

Bash mette a disposizione due operatori, il man li chiama metacaratteri, per la redirezione: < e >.

Il loro uso è semplice e lo conoscerete già, ad esempio

echo 'hello file!' > nome di un file

fa in modo che la shell invii ‘hello file!’ ad un file piuttosto che al mondo intero. Abbiamo appena rediretto l’output su file. Analogamente l’operatore < permette di redirigere l’input e quindi possiamo restituire al mondo il saluto che gli dobbiamo con cat < file.

Se pensate che sia sconveniente salutare il mondo apostrofandolo file provate con

sed “s/file/world/” file | cat 🙂

Utilizzando >& al posto del semplice > è possibile redirigere i file descriptor tra di loro piuttosto che su file presenti sul filesystem (non ho scritto disco perché sarebbe inesatto).

A questo punto possiamo interpretare il comando

echo "Questo è un messaggio indirizzato allo standard error" 1>&2

come invia allo standard outpu (è quello che fa echo) la stringa “Questo è un messaggio indirizzato allo standard error” e subito dopo aggiungiamo: a proposito, invia i dati che passano per standard output (1)  dove vanno a finire i dati destinati allo standard error (2). Solitamente si usa la versione >&2 che sottintende 1 (stdout) come file descriptor di partenza. Il secondo comando presente nello script poteva tranquillamente limitarsi a

echo "Questo è un messaggio indirizzato allo standard output"

ma se non sono prolisso non mi diverto.

La redirezione finisce qui, per ora, abbiamo tutti i concetti base per proseguire con i nostri esperimenti ma ho ormai scritto troppo e vi rimando ad un prossimo approfondimento.