Capitolo 12. Programmazione

Il comando "echo" deve essere usato con le precauzioni seguenti dato che la sua implementazione è diversa negli svariati comandi interni della shell ed esterni.

	Nota
	Sebbene l'opzione "-n" non faccia veramente parte della sintassi POSIX, è generalmente accettata.

	Suggerimento
	Se è necessario inserire sequenze di escape nella stringa in output, usare il comando "printf" al posto del comando "echo".

Negli script di shell vengono spesso usati parametri speciali.

Le nozioni base da ricordare riguardanti la espansione dei parametri sono le seguenti.

I due punti ":" in tutti gli operatori nell'elenco precedente sono di fatto opzionali.

Ogni comando restituisce uno stato di uscita che può essere usato in costrutti condizionali.

	Nota
	"0" nel contesto condizionale della shell significa "Vero", mentre "0" nel contesto condizionale in C significa "Falso".

	Nota
	"[" è l'equivalente del comando "test che valuta i propri argomenti sino a "]" come un'espressione condizionale.

Le espressioni condizionali di base che è bene ricordare sono le seguenti.

if [ <espressione_condizionale> ]; then
 <se_successo_esegue_questo_comando>
else
 <se_non_successo_esegue_questo_comando>
fi

In questo caso il "|| true" finale era necessario per assicurare che lo script non termini accidentalmente a tale riga quando la shell è invocata con l'opzione "-e".

Gli operatori aritmetici di comparazione di interi nelle espressioni condizionali sono "-eq", "-ne", "-lt", "-le", "-gt" e "-ge".

Ci sono diverse espressioni per cicli usabili nella shell POSIX.

	Suggerimento
	L'iterazione numerica in stile linguaggio C può essere realizzata usando seq(1) come "pippo1 pippo2 …"

	Suggerimento
	Vedere Sezione 9.3.9, «Ripetere un comando su diversi file».

A grandi linee la shell elabora uno script nel modo seguente.

Virgolette singole all'interno di virgolette doppie non hanno alcun effetto.

L'esecuzione di "set -x" nella shell o l'invocazione della shell con l'opzione "-x" fanno sì che la shell stampi tutti i comandi eseguiti. Ciò è piuttosto utile per il debug.

Per far sì che il proprio programma di shell sia il più portabile possibile tra i sistemi Debian, è una buona idea limitare i programmi di utilità a quelli forniti dai pacchetti essenziali.

L'interfaccia utente di un semplice programma shell può essere migliorata dalla banale interazione con i comandi echo e read ad una più interattiva con l'uso dei cosiddetti programmi di dialogo ecc.

Questo è un semplice script che crea un'immagine ISO con dati RS02 forniti da dvdisaster(1).

#!/bin/sh -e
# gmkrs02 : Copyright (C) 2007 Osamu Aoki <osamu@debian.org>, Public Domain
#set -x
error_exit()
{
  echo "$1" >&2
  exit 1
}
# Inizializza le variabili
DATA_ISO="$HOME/Desktop/iso-$$.img"
LABEL=$(date +%Y%m%d-%H%M%S-%Z)
if [ $# != 0 ] && [ -d "$1" ]; then
  DATA_SRC="$1"
else
  # Seleziona la directory per creare l'immagine ISO dalla cartella sul desktop
  DATA_SRC=$(zenity --file-selection --directory  \
    --title="Seleziona la radice dell'albero di directory per creare l'immagine ISO") \
    || error_exit "Uscita durante la selezione della directory"
fi
# Controlla la dimensione dell'archivio
xterm -T "Controllo dimensione $DATA_SRC" -e du -s $DATA_SRC/*
SIZE=$(($(du -s $DATA_SRC | awk '{print $1}')/1024))
if [ $SIZE -le 520 ] ; then
  zenity --info --title="Dvdisaster RS02" --width 640  --height 400 \
    --text="La dimensione dei dati va bene per un CD di backup:\\n $SIZE MB"
elif [ $SIZE -le 3500 ]; then
  zenity --info --title="Dvdisaster RS02" --width 640  --height 400 \
    --text="La dimensione dei dati va bene per un DVD di backup:\\n $SIZE MB"
else
  zenity --info --title="Dvdisaster RS02" --width 640  --height 400 \
    --text="Dimensione dei dati troppo grande per farne il backup: $SIZE MB"
  error_exit "Dimensione dei dati troppo grande per farne il backup :\\n $SIZE MB"
fi
# solo xterm sicuramente ha un'opzione -e funzionante
# Crea immagine raw ISO
rm -f "$DATA_ISO" || true
xterm -T "genisoimage $DATA_ISO" \
  -e genisoimage -r -J -V "$LABEL" -o "$DATA_ISO" "$DATA_SRC"
# Crea dati ridondanti RS02 supplementari
xterm -T "dvdisaster $DATA_ISO" -e  dvdisaster -i "$DATA_ISO" -mRS02 -c
zenity --info --title="Dvdisaster RS02" --width 640  --height 400 \
  --text="dati ISO/RS02 ($SIZE MB) \\n creati per: $DATA_ISO"
# EOF

Si potrebbe voler creare un lanciatore sul desktop con un comando definito in modo simile a "/usr/local/bin/gmkrs02 %d".

Un semplice esempio "esempio.c" può essere compilato con una libreria "libm" in un eseguibile "eseg_esempio" nel modo seguente.

$ cat > esempio.c << EOF
#include <stdio.h>
#include <math.h>
#include <string.h>

int main(int argc, char **argv, char **envp){
        double x;
        char y[11];
        x=sqrt(argc+7.5);
        strncpy(y, argv[0], 10); /* previeni buffer overflow */
        y[10] = '\0'; /* riempi per assicurare che la stringa finisca con '\0' */
        printf("%5i, %5.3f, %10s, %10s\n", argc, x, y, argv[1]);
        return 0;
}
EOF
$ gcc -Wall -g -o eseg_esempio esempio.c -lm
$ ./eseg_esempio
        1, 2.915, ./run_exam,     (null)
$ ./eseg_esempio 1234567890qwerty
        2, 3.082, ./run_exam, 1234567890qwerty

In questo esempio, l'uso di "-lm" è necessario per fare il link alla libreria "/usr/lib/libm.so" nel pacchetto libc6 per sqrt(3). La libreria reale è in "/lib/" con nome file "libm.so.6", che è un collegamento simbolico a "libm-2.7.so".

Si guardi l'ultimo elemento nel testo di output: ci sono più di 10 caratteri anche se è stato specificato "%10s".

L'uso di funzioni che operano su puntatori di memoria senza controlli sui limiti, come sprintf(3) e strcpy(3) è deprecato per prevenire exploit di tipo buffer overflow che sfruttano gli effetti di superamento dei limiti di grandezza dei dati.

Dato che tutti i binari installati in un sistema Debian dovrebbero essere, in modo predefinito, snelliti con strip, la maggior parte dei simboli di debug non è presente nei normali pacchetti. Per poter fare il debug di pacchetti Debian con gdb(1) devono essere installati i corrispondenti pacchetti *-dbg (ad esempio libc6-dbg per libc6).

Se un pacchetto di cui si deve fare il debug non fornisce il proprio pacchetto *-dbg corrispondente, è necessario installarlo dopo averlo ricompilato nel modo seguente.

$ mkdir /percorso/nuovo ; cd /percorso/nuovo
$ sudo apt-get update
$ sudo apt-get dist-upgrade
$ sudo apt-get install fakeroot devscripts build-essential
$ sudo apt-get build-dep nome_pacchetto_sorgente
$ apt-get source nome_pacchetto
$ cd nome_pacchetto*

Correggere i bug se necessario.

Spostare la versione del pacchetto ad una che non crei conflitti con le versioni ufficiali di Debian, ad esempio una che termini con "+debug1" quando si ricompilano versioni di cui esiste un pacchetto, o una che termini con "~pre1" quando si ricompilano versioni non ancora rilasciate in pacchetti nel modo seguente.

$ dch -i

Compilare ed installare i pacchetti con i simboli di debug nel modo seguente.

$ export DEB_BUILD_OPTIONS=nostrip,noopt
$ debuild
$ cd ..
$ sudo debi nome_pacchetto*.changes

È necessario controllare gli script di compilazione del pacchetto ed assicurarsi di usare "CFLAGS=-g -Wall" per la compilazione di binari.

Quando un programma va in crash, è una buona idea inviare un segnalazione di bug riportando le informazioni di backtrace.

Il backtrace può essere ottenuto eseguendo le azioni seguenti.

Nel caso in cui in programma si blocca, si può farlo andare in crash premendo Ctrl-C nel terminale in cui è in esecuzione gdb, ottenendo così il prompt di gdb.

	Suggerimento
	Spesso si vede un backtrace in cui una o più delle prime righe sono in "malloc()" o "g_malloc()". Quando ciò accade è probabile che il backtrace non sia molto utile. Il metodo più semplice per trovare informazioni utili è di impostare la variabile d'ambiente "$MALLOC_CHECK_" al valore 2 (malloc(3)). Lo si può fare mentre si esegue gdb nel modo seguente.

 $ MALLOC_CHECK_=2 gdb hello

Se un programma gnome preview1 ha ricevuto un errore X, si dovrebbe leggere un messaggio del tipo seguente.

The program 'preview1' received an X Window System error.

Se ciò avviene, si può provare ad eseguire il programma con "--sync" ed interrompere alla funzione "gdk_x_error" per ottenere un backtrace.

Per scoprire le dipendenze di un programma da librerie, usare ldd(1) nel modo seguente.

$ ldd /bin/ls
        librt.so.1 => /lib/librt.so.1 (0x4001e000)
        libc.so.6 => /lib/libc.so.6 (0x40030000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40153000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Affinché ls(1) funzioni in un ambiente "chroot", le librerie in questione devono essere disponibili nell'ambiente "chroot".

In Debian sono disponibili svariati strumenti di rilevazione di memory leak.

Si può disassemblare codice binario con objdump(1) nel modo seguente.

$  objdump -m i386 -b binary -D /usr/lib/grub/x86_64-pc/stage1

	Nota
	Per disassemblare codice in modo interattivo si può usare gdb(1).

	Avvertimento
	Non sovrascrivere mai file di sistema quando si installano programmi compilati in proprio.

Debian non tocca i file in "/usr/local/" o "/opt". Perciò se si compila un programma dai sorgenti, installarlo in "/usr/local/" in modo che non interferisca con Debian.

$ cd src
$ ./configure --prefix=/usr/local
$ make
$ make install # questo mette i file nel sistema

Se si hanno i sorgenti originali e questi usano autoconf(1)/automake(1), e se ci si ricorda la configurazione usata, eseguire quanto segue per disinstallare un programma.

$ ./configure "tutte-le-opzioni-che-erano-state-usate"
# make uninstall

In alternativa, se si è assolutamente certi che il processo di installazione mette i file solo in "/usr/local/" e lì non c'è nulla di importante, si può cancellare tutto ciò che contiene con la riga di comando seguente.

# find /usr/local -type f -print0 | xargs -0 rm -f

Se non si è sicuri di dove siano installati i file, si dovrebbe prendere in considerazione l'uso di checkinstall(8) dal pacchetto checkinstall, che fornisce un percorso di disinstallazione pulita. Ora permette di creare un pacchetto Debian con l'opzione "-D".