Come aggiungere un watermark ad un video

La potenzialità della linea di comando unix è altissima anche per le attività di tipo grafico, ovviamente quando queste possono essere automatizzate; mettiamo caso che si voglia aggiungere un proprio logo ad un filmato, proprio come avviene nei maggiori portali e di volerlo fare senza usare programmi con la gui, magari per avere la possibilità di automatizzare il processo. Read the rest of this entry »

Sottocomandi custom di git

Da un bel po’ di tempo ormai ho scritto la mia guida git (che peraltro è il mio post più letto) e il tool in questione ormai è andato oltre l’umana comprensione in usabilità e utilità (tranquilli non vengo pagato per questa pubblicità); adesso che sono disoccupato ho un po’ di tempo da dedicare a quello che ho appreso durante quest’anno di lavoro "professionale".

Git come strumento è proprio una toolbox, cioè un insieme di sottocomandi che permettono di eseguire funzioni appropriate su un repository di codice sorgente (e non); come toolbox non potrebbe essere completo se non permettesse di definire comandi custom e non mettesse a disposizione una "libreria" per facilitare le funzioni comuni. Tranquilli, non si parla di linkare codice in C (anche se ha il suo fascino of course) ma di scrivere un semplice (in questo caso di esempio) script per perlustrare le possibilità messe a disposizione.

Partiamo creando un repository di test nella directory temporanea

$ cd /tmp/
$ mkdir testing
$ cd testing
$ git init
Initialized empty Git repository in /tmp/testing/.git/

e di seguito create un file chiamato git-packz

$ cat > git-packz
#!/bin/bash

USAGE="$0 <message>
script di test per sottocomando git
"

PATH=$(git –exec-path):$PATH
. git-sh-setup

if [ $# -lt 1 ]
then
    usage
fi

echo "message: "$1

Adesso dentro questo repository è possibile chiamare il comando eseguendo

$ PATH=.:$PATH git packz miao
message: miao

Questo era solo un esempio, quando avrete scritto uno script che considerate definitivo spostatelo (linkatelo) in una directory puntata dal vostro PATH così da poterlo chiamare tramite un semplice git <nome script da cui si elimina il prefisso "git-">; come potete vedere lo script di esempio è molto semplice e l’unica parte fondamentale è quella in cui viene caricata in memoria dalla shell il contenuto di git-sh-setup. Questo non è altro che uno script che definisce alcune funzioni general purpose proprie di un repository git, cioè

• die
• usage
• set_reflog_action
• git_editor
• is_bare_repository
• cd_to_toplevel
• require_work_tree
• get_author_ident_from_commit

Per sapere cosa servono leggetevi la pagina di manuale.

Indentare file xml

Magari dovete lavorare su file XML di una discreta dimensione e magari usare xpath per estrane info utili ai vostri scopi (uscire con jessica alba?); il casino è che magari il file XML non è formattato in maniera human readable e quindi dovreste indentarlo per capire dove cazzo si trova il nodo che ci interessa. La maniera da manovale è farlo a mano: si parte dall’inizio del file e alla fine di ogni <tag> si inserisce un "nt" e alla fine di </tag> si inserisce un newline e si toglie un TAB dalla lista (non è proprio semplice come pensavo prima di iniziare a scrivere questo post).
Read the rest of this entry »

I segreti della linea di comando – Command substitution

Esistono dei casi in cui un comando prende come argomento uno o più file, mentre noi necessitiamo di dover passare a questo programma il risultato di un altro comando; la prima cosa che verrebbe in mente è sarebbe quella di usare un file intermedio da usare appositamente, ma la shell bash ha pensato anche a questo, la command substitution!!!

La sintassi generale in questo caso è

<( command )
>( command )

il primo caso è da usare nel caso in cui si vuole l’output di command come contenuto di un file di input, mentre il secondo nel caso ci interessi per un file di output.
Read the rest of this entry »

I segreti della linea di comando

A furia di lavorare al computer ho imparato un paio di cosette veramente cool… prima di tutto però una introduzione su cosa è la shell: l’oggetto che ci permette l’interazione su un sistema *nix, chiamato solitamente terminale, benché abbia un’aria così anni 70 permette un macello di azioni simpatiche e performanti.

Prima di tutto la linea di comando di solito è preceduta da un cosidetto prompt, cioè l’indicatore dello stato del terminale (ne esistono 4 diversi) utile per avere informazioni riguardanti la directory in cui ci troviamo, il computer in cui ci troviamo (il cosidetto host) e che utente siamo (cose non date per scontate in un sistema multiutente). Quando viene eseguito un comando all’interno succede una cosa carina:viene eseguita una chiamata di sistema che sostituisce il processo con quello eseguito (la execv e famiglia) con una piccola accortezza dovuta al fatto che ci sono due tipi di programmi, gli eseguibili e gli script; i secondi hanno la particolarità di necessitare di un interprete per funzionare (può essere la stessa shell, può essere l’interprete python, awk etc…). Proprio a questo scopo esiste il cosidetto numero magico del file: siccome il computer non può fidarsi della estensione del file per riconoscerne la natura, visto che l’estensione non è neanche una specifica di nessun tipo se non per winzoz, legge i primi 3/4 byte di un file per riconoscerlo attraverso una segnatura, chiamata appunto numero magico; provate a eseguire su un file PNG il comando head -c 4 e vedrete che uscirà una stringa contenente proprio il formato. Nel caso di un file di script, la sequenza magica è #!, seguita dal percorso dell’interprete. Se quindi viene chiesto di eseguire un file ‘mioscriptpaura.sh‘ che ha al suo interno come prima riga la sequenza #!/bin/sh, il sistema eseguirà invece /bin/sh mioscriptpaura.sh.

Ogni programma *nix può essere immaginato come una scatola nera, di cui non conosciamo l’implementazione, impegnata in un’azione particolare sul suo input per restituire un output diverso, tenendo conto anche di eventuali messaggi di errore o di log relativi all’azione particolare; ad ognuno di questi flussi di dati (detti stream)  è associato un file descriptor, chiamati rispettivamente standard input, standard output e standard error. La cosa carina è che è possibile concatenare comandi per ottenere una cosidetta pipeline e generare tramite sequenza di comandi semplici, azioni complesse; il modo attraverso cui questo è possibile è la pipe, ottenuta attraverso il carattere |. Per fare un esempio, se necessitiamo di controllare se è stata montata la partizione di swap del sistema al boot, dovremmo spulciare le righe di dmesg una ad una, ma usando grep, comando che cerca l’occorrenza di una data stringa in un file, possiamo facilitarci la vita nella seguente maniera

$ dmesg | grep swap
[   28.276971] Adding 2931852k swap on /dev/sda2.  Priority:-1 extents:1 across:2931852k

Ovviamente il carattere | non può essere utilizzato normalmente, ma deve essere trattato con cura (provate a creare una file che lo contenga ;-)). Altre ficate della shell *nix sono la redirezione degli stream descritti sopra: magari noi vogliamo salvare il risultato della elaborazione su un  file oppure prendere un file come standard input per un comando e proprio per questo ecco la magia

COMANDO < INPUT_FILE
COMANDO > OUTPUT_FILE
COMANDO >> OUTPUT_FILE
COMANDO < INPUT_FILE > OUTPUT_FILE
COMANDO < INPUT_FILE >> OUTPUT_FILE

Nel primo caso usiamo le righe di INPUT_FILE come se fossero scritte direttamente sul terminale dopo aver avviato COMANDO (equivalente peraltro a cat INPUT_FILE | COMANDO), nel secondo caso in OUTPUT_FILE viene scritto il risultato dell’esecuzione di COMANDO; il terzo caso è l’unione dei due precedenti. Particolare attenzione riveste l’operatore >> che apre il file in questione e aggiunge alla fine il risultato del comando (l’operatore > nel caso esista già il file e non sia vuoto, lo riscrive da zero).

Esiste anche l’operatore << che permette di ottenere i cosiddetti Here document; eseguendo

cat <<EOF > porcatroia.txt
sei solo una troia, pensi solo ai $soldi
EOF

ottieni nel file porcatroia la riga "sei solo una troia, pensi solo ai ", la mancanza di $soldi è dovuto al fatto che la shell cerca di sostituirlo con una variabile, per essere riprodotto testualmente, bisogna quotare EOF, ma quello del quoting nella prossima puntata.

Per finire mostro solo la presenza di ulteriori operatori logici presenti nella shell: un programma può nella sua esecuzione incontrare dei problemi/errori dovuti a situazioni particolari (disco pieno, file inesistente, digos) e quindi può comunicarlo alla shell tramite il suo valore di ritorno: nel caso questo sia diverso da zero allora c’è stato un problema altrimenti è tutto ok. La variabile che contiene il valore di ritorno è $?.

Bene, questo può essere usato per concatenare comandi; nel caso vogliamo eseguire un dato comando dopo il successo di un altro dobbiamo porre l’operatore && tra di essi. Nel caso in cui vogliamo eseguire un comando nel caso il primo fallisca, si usa l’operatore ||. Ovviamente non potrete utilizzare normalmente questi comandi in nomi di file.

È tutto un simbolo

La mia quest per la compilazione di Xorg con supporto MPX è senza fine: adesso voglio usare jhbuild che se non altro tiene conto in automatico delle dipendenze (ah… le dipendenze) e permette di gestire anche gli errori di compilazione e la generazione in automatico delle variabili necessarie alla compilazione di progetto ampi come X (è nato come supporto a Gnome); dopo vari segfault del driver della scheda video, adesso mi da un errore su un simbolo indefinito che è stato inserito in evdev da quel mago di Hutterer (uno dei pochi che risponde alle mail di un povero adepto della programmazione come me) e che non risulta in nessun file oggetto compilato e presente nei sorgenti. Read the rest of this entry »

Quant’è fico il mio prompt!

Condivido con voi il prompt presente sulla mia shell, copiato spudoratamente da Linux Gazette più qualche commento utile per la personalizzazione. Read the rest of this entry »