Se Evolution (mail) non ripristina il proprio backup

Tema

Come hai passato il fine settimana appena trascorso?
(Hai fretta? Non ti va di leggere tutta la storia? Salta alle conclusioni!)

Svolgimento

Questo weekend il tempo era perfetto per andare al mare. Cosa poteva trattenermi dopo una settimana di passione? L’ultima cosa da fare prima di un meritato riposo era sostituire il disco ad un computer che cominciava a fare le bizze. Continua a leggere “Se Evolution (mail) non ripristina il proprio backup”

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”

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.

Quando Firefox esegue due volte lo stesso script

Promemoria:

Tutto un pomeriggio perso dietro ad un problema che, al giorno d’oggi, non dovrebbe neanche porsi:

No, non sto criticando Firefox, sto criticando me stesso che mi atteggio ad essere uno pseudoprogrammatore. Analisi dei flussi, pattern, programmazione agile (magari) e poi mi perdo in un bicchier d’acqua.

Mi è capitato che un banale script:

<script type="text/javascript" >
//<!--
var stats = "toolbar=no, location=no, directories=no, "
    stats +="status=yes, menubar=no, scrollbars=no, top=0, "
    stats +="resizable=no, width=1100, height=678, left=0";
window.open("indexFraming.php", "", stats);
window.opener=self;
self.close();
//-->
</script>

Venisse eseguito due volte da Firefox ed una volta sola da Internet Explorer 6. Non ho testato altri browser per mancanza di tempo e voglia. Chi volesse integrare con commenti è, al solito, benvenuto.

Racchiudere il codice all’interno di una funzione, anche anonima, ed eseguirlo al termine del caricamento della pagina, risolve il problema.

<script type="text/javascript" >
//<!--
window.onload=function () {
   var stats =  "toolbar=no, location=no, directories=no, "
       stats += "status=yes, menubar=no, scrollbars=no, top=0, "
       stats += "resizable=no, width=1100, height=678, left=0";
window.open("indexFraming.php", "", stats);
window.opener=self;
self.close();
}
//-->
</script>

E questo è tutto.

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.

L’importanza di chiamarsi Vim

Riprendo, dopo un lungo silenzio, a riportare qualche appunto su queste pagine.

Ovviamente lo faccio con una annotazione di scarsa utilità :).

Chi  usa vi/vim si sarà trovato, voglio sperare di non essere il solo, ad avere alcuni problemi con lo spostamento del cursore in modalità editing. Se, per distrazione, si usano le frecce di direzione per spostarlo prima di aver premuto il nostro fidato <esc>, ci si trova con una nuova riga contenente un solo carattere che cambia a seconda della direzione che volevamo far prendere al nostro cursore. E più volte lo si preme (repetita juvant) più righe appaiono.

Se il problema si verifica, non è detto, infatti, che la vostra installazione lo evidenzi, la soluzione è tanto breve quanto banale: invocare vim con il suo nome esteso, vim appunto, piuttosto che con il più tradizionale e conciso vi (che mette vim in modalità compatibile con vi e genera il problema).

Se volete continuare ad invocare vi ma non volete che il problema si ripresenti non vi serve altro che un semplice alias per risolvere il tutto: alias vi=’vim’

E questo e tutto (che per un post che può essere riassunto in – chiamate vim con il suo nome invece che vi – mi sembra abbastanza)

Bash: Trasposizioni

Venerdì mattina, tempo soleggiato e pomeriggio in permesso, domani è sabato, nulla potrà rovinarmi la giornata. A parte un mio collega che entra in ufficio e se ne esce con una frase che comincia con – abbiamo trovato il baco ieri sera – e finisce con – dobbiamo trasporre le cinquecento matrici che usiamo per i test. L’entusiasmo per la prima parte della frase si smorza subito non appena realizzo cosa sottindende la seconda: niente pausa caffè (tè nel mio caso) prima di aver modificato i file visto che con i test fermi nessun altro potrà lavorare.

Mi metto subito al lavoro ed inizialmente penso di fare un programmino in C. Quando mi ricordo (shame on me) che non ho tanto fresca la sintassi del linguaggio penso che farei prima con un paio di righe di bash piuttosto che rinfrescarmi la memoria.

Il problema che devo risolvere consiste nel manipolare i file che contengono le matrici (una per file) e salvare al loro posto la matrice trasposta.

La trasposta di una matrice è una matrice in cui sono state scambiate le righe con le colonne (in pratica la prima riga della matrice diventa la prima colonna della trasposta, la seconda riga rappresenta la seconda colonna e così via…)

La soluzione è più semplice del previsto e la riporto subito prima di commentarla. In particolare mi è piaciuto (perché risalito d’un tratto dagli abissi della memoria) l’uso di xargs che forse potrebbe lasciare qualcuno interdetto

#!/bin/bash
for i in $(seq 1 $3)
do
  head $1 -n $2 | cut -d \  -f $i | xargs
done

Lo script non fa altro che predere una matrice, rivoltarla e stamparla in standard output. A questo punto redirigere l’output in un nuovo file diventa banale, come è banale processare tutti i file in automatico. Torniamo allo script ed al suo commento, Chiamiamolo ad esempio trasponi.

Viene invocato come trasponi file 4 3 per trasporre una matrice, file, di 4 righe per 3 colonne. Sull’output avremo una matrice di 3 righe per 4 colonne. Nel file le matrici sono memorizzate per righe ed in ogni riga un elemento è separato dagli altri da uno spazio.

La riga di codice che crea le diverse righe è head $1 -n $2 | cut -d \ -f $i | xargs e potrebbe anche essersi ridotta in cut $1 -d \ -f $i | xargs ma l’ho scritta in quel modo per evidenziare il numero di righe della matrice da elaborare.

La prima parte del pipe seleziona la colonna da trasformare, l’ultima si occupa di assemblarla come riga.

xargs, di solito, si usa per leggere dallo standard input dei parametri da passare ad un comando. Se non viene specificato si assume che il comando a cui passare i parametri sia echo.
Un altro utilizzo di xargs, magari non così convenzionale, è mettere tutti su una riga i parametri che gli vengono passati in input uno per volta (sfruttando il fatto che il parametro predefinito sia echo).

Le potenzialità di xargs, tra l’altro, non si esaurscono qui, ci sono altre funzioni a cui può assolvere oltre quella canonicamente riconosciuta di “fornitore di parametri”. Potenzialità che saranno oggetto di un ulteriore post.

E questo, per ora, è tutto