Magazine Tecnologia

How-Thunar: automatizzare l’aggiornamento delle copie locali dai revision control system

Creato il 10 giugno 2011 da M0rf3us @alex_morfeus

How-Thunar: automatizzare l’aggiornamento delle copie locali dai revision control system

Con questo articolo dò il via ad una serie di piccoli how-to dedicati alla personalizzazione di Thunar, principalmente saranno degli script da associare ad una voce nel menù contestuale del suddetto File Manager. Si spera possano venire utili anche a Morfeus per introdurre tramite esempi qualche argomento della sua guida allo scripting. Con ogni probabilità saranno esempi negativi. Verranno subito dopo la dicitura:

Ecco la maniera sbagliata di mettere in pratica ciò di cui abbiamo parlato finora…

Thunar-uca: User Customizable Action

Indice Contenuti
  • Thunar-uca: User Customizable Action
  • Aggiornamento di copie locali di repository gestiti dai maggiori revision control system
    • Creazione dello Script
  • Utilizzo dello Script dal Menù Contestuale di Thunar
    • Tab Base
    • Tab Condizioni di Visibilità

Cominciamo con l’introdurre gli strumenti messi a disposizione dal nostro esploratore di file per l’estensione del suo menù contestuale. La UCA è estremamente limitata, sopratutto se confrontata con i suoi omologhi appartenenti ad altri file-manager. Tempo fa vi era in progetto una sua evoluzione molto più potente, Thunar-Actions-Plugin, ma non se ne seppe più nulla :( . Se non ricordo male1 lo sviluppo si era temporaneamente interrotto qualche anno fa ( -.-’ …il concetto di “temporaneo” è quanto di più labile possa esistere) a causa degli impegni scolastici dell’unico sviluppatore. No, non era professore, era studente.
Vediamo di osservare quel poco che abbiamo allora:
si accede al menu di configurazione da qualsiasi finestra di thunar cliccando su Modifica→Imposta azioni personalizzate; cliccando sulla prima icona in alto a destra si aprirà la finestra per la creazione di una nuova azione; esaminiamo ciò che questa mette a disposizione:

Tab Base

Nome: il nome che comparirà nel menù contestuale per l’azione che andremo a creare
Descrizione: verrà mostrato nella barra di stato, quella in fondo alla finestra di Thunar, ogni volta che il mouse passerà sul nome dell’azione
Comando: lo script o il programma vero e proprio che verrà eseguito al click sull’azione
Usa notifica di avvio: flaggando questa opzione si fa in modo che il sistema, in particolare il window manager, sia avvisato dell’avvio del comando. Può essere utile ad esempio per evitare che le finestre del programma lanciato, una volta creato prendano il focus, (è questo il significato della meravigliosa traduzione nel tooltip di questo campo dell’UCA che recita “…la prevenzione al furto del fuoco…”, giorni duri per Prometeo…) togliendolo ad una finestra nella quale magari stiamo digitando qualcosa (magari informazioni da non rivelare in chiaro).
Icona:l’icona che verrà mostrata nel menù contestuale affianco al nome
Parametri: importantissimi! Questo elenco mostra le variabili da usare nel lanciare il nostro script, a seconda del/i parametro/i in input di cui questo avrà bisogno per funzionare.

Tab Condizioni di Visibilità

 

Schema del file:in questo campo si specifica per quali nomi (compresi di estensioni) di file si vuole visualizzare l’azione che stiamo impostando. Ovviamente la cosa più utile è sfruttarlo sull’estensione: *.txt ad esempio, visualizzerà l’azione nel menù ogni volta che daremo un click destro su un file con estensione .txt. Se non vogliamo porre alcun limite ai nomi+estensioni di file per i quali visualizzare l’azione, sarà sufficiente lasciare solo un *
Appare se la selezione contiene: ha lo stesso scopo dell’opzione precedente, ma filtra i file in base al loro tipo (suppongo riconoscendolo attraverso i mime-type) anzichè al loro nome.

Aggiornamento di copie locali di repository gestiti dai maggiori revision control system

Creazione dello Script

Diamo inizio allo scripting vero e proprio. Cercherò di usare solo funzioni semplici e generiche, non vincolanti quindi all’uso di Bash (che è la shell che uso io).
A molti (tutti?) di voi sarà capitato di utilizzare almeno una volta un programma di version control, magari in sola lettura (se non siamo programmatori, difficilmente avremo mai effettuato qualche commit), principalmente per copiare in locale la versione in sviluppo di un software che ci interessa. Sappiamo tutti che per mantenerla aggiornata, dovremo fare ogni tot di tempo un checkout, procedura che può variare a seconda del sistema di versioning utilizzato. I principali sono bazaar, git e subversion (so che ce ne sarebbero degli altri, tipo cvs o mercurial ma per semplicità renderò lo script compatibile solo con questi tre). In realtà queste poche righe di codice avranno un’utilità molto relativa, per farle diventare meritevoli di attenzione si dovrebbe rendere molto più complesso (ed efficace) lo script, cosa che vedrò di trattare in futuro.
In soldoni, cosa fa questa benedetta azione? Cliccando sulla directory che contiene la copia locale del repo, riconosce il sistema di controllo di revisione usato ed effettua l’aggiornamento dalla copia remota. Ecco il codice:

1
2
3
4
5
6
7
8
9
10
11
12
#!/bin/bash
if [ -d .svn ]
then echo $PWD "è un archivio svn"; svn up
elif [ -d .git ]
then echo $PWD "è un archivio git"; git pull
elif [ -d .bzr ]
then echo $PWD "è un archivio bzr"; bzr up
else
echo $PWD "non è un repo gestito da un sistema di controllo di versione"
fi
echo "finito"
exit


A grandi linee: verifica che all’interno della directory vi sia la radice di una copia locale di un repo gestito da uno dei revision control system presi in considerazione, se la verifica dà esito positivo, lancia l’aggiornamento coerentemente col sistema rilevato.
Ricordatevi ovviamente di rendere eseguibile il vostro script una volta salvato.
Si notano due cose:

  1. il metodo grossolano di verifica di repo o semplice directory: verifica la presenza di una directory di nome .svn, .git oppure .bzr
  2. la stupidità dello script: effettua la verifica solo nella directory nel quale viene lanciato.

Utilizzo dello Script dal Menù Contestuale di Thunar

Vediamo ora come assegnarlo ad un’azione di Thunar:

Tab Base

Nome: Come vi pare
Descrizione: Idem con patate
Comando: roxterm -d %f -e revision_control

su questo è necessario fare una precisazione: come vedete io ho specificato che l’emulatore di terminale nel quale lanciare lo script (voglio vedere cosa fa, quindi lo lancio in una finestra di terminale) sia roxterm (splendido software del quel scriverò in futuro). In realtà thunar, appoggiandosi alle librerie exo fornirebbe il comando
exo-open --launch TerminalEmulator
che, previa impostazione della sua variabile TerminalEmulator renderebbe la regola portabile su altri sistemi indipendentemente dall’emulatore di terminale utilizzato. Purtroppo ho riscontrato un problema che rende il sistema inservibile: non vengono passati gli switch ed i vari parametri all’emulatore di terminale, quindi richiamo direttamente l’eseguibile del programma. Con lo switch -d dovrei indicare a roxterm in quale directory spostarsi alla sua apertura, siccome in questo caso la posizione varia di volta in volta che l’azione viene lanciata, utilizziamo le variabili accenntate in precedenza parlando della Tab Base. In particolare, leggiamo che %f equivale a il percorso del primo file selezionato, che è esattamente ciò che ci serve. Se noi quindi andremo ad esempio a clickare col tasto destro sulla cartella ~/dati/vattelapesca, e selezioneremo dal menù contestuale l’azione creata, il comando diverrà
roxterm -d /home/nome_utente/vattelapesca -e revision_control
Il secondo switch invece, serve ad indicare a roxterm che deve eseguire la stringa successiva (revision_control) come comando.
Tenete presente che -d ed -e sono opzioni specifiche di roxterm (anche se comuni a molti altri emulatori di terminale), cercate nel man del vostro terminale le equivalenti. Spesso la -e viene sostituita da -x.
Nel caso specifico usiate xfce4-terminal (noto anche semplicemente come Terminal), ricordatevi di passargli anche l’opzione -H, che fa in modo che la finestra del terminale non si chiuda immediatamente alla fine del processo di aggiornamento, consentendovi quindi di leggere comodamente l’output. Per ottenere lo stesso comportamento in roxterm si utilizza un’opzione tra le sue preferenze.
Se il vostro script è stato salvato in una directory non presente nella variabile di sistema $PATH, sarà necessario esplicitare completamente il suo percorso alla voce Comando al posto del solo nome.
Usa notifica di avvio: a vostra discrezionalità
Icona: indovinate un po’?

Tab Condizioni di Visibilità

Schema del file: lasciamo solo un asterisco *
Appare se la selezione contiene: mettiamo la flag alla casella Cartelle

La nostra azione sarà ora disponibile ogni qualvolta daremo un click destro su di una cartella all’interno di Thunar. :)
Ribadisco che questo è solo un articolo introduttivo alle opzioni di personalizzazione di Thunar, spero in futuro di avere tempo e modo di pubblicare qualcosa di realmente utile. Ogni proposta o richiesta è ben accetta.

  1. cosa che mi capita spessissimo, la seguente è quindi una potenziale ca****a

Potrebbero interessarti anche :

Ritornare alla prima pagina di Logo Paperblog

Possono interessarti anche questi articoli :

Magazine