Capitolo 12. Programmazione

Indice

12.1. Script shell
12.1.1. Compatibilità con la shell POSIX
12.1.2. Parametri di shell
12.1.3. Costrutti condizionali della shell
12.1.4. Cicli di shell
12.1.5. Variabile d'ambiente della shell
12.1.6. La sequenza di elaborazione della riga di comando di shell
12.1.7. Programmi di utilità per script di shell
12.2. Creazione di script in linguaggi interpretati
12.2.1. Fare il debug di codice di linguaggi interpretati
12.2.2. Programma GUI con script di shell
12.2.3. Azioni personalizzate per un gestore di file con GUI
12.2.4. Pazzie con corti script Perl
12.3. Scrivere codice in linguaggi compilati
12.3.1. C
12.3.2. Semplice programma in C (gcc)
12.3.3. Flex - un Lex migliorato
12.3.4. Bison - Yacc migliorato
12.4. Strumenti di analisi statica del codice
12.5. Debug
12.5.1. Esecuzione base di gdb
12.5.2. Fare il debug di pacchetti Debian
12.5.3. Ottenere un backtrace
12.5.4. Comandi gdb avanzati
12.5.5. Controllare le dipendenze dalle librerie
12.5.6. Strumenti per tracciamento di chiamate dinamiche
12.5.7. Fare il debug di errori X
12.5.8. Strumenti per rilevazione di memory leak
12.5.9. Disassemblatore di binari
12.6. Strumenti di compilazione
12.6.1. Make
12.6.2. Autotools
12.6.2.1. Compilare ed installare un programma
12.6.2.2. Disinstallare un programma
12.6.3. Meson
12.7. Web
12.8. Traduzione di codice sorgente
12.9. Creare pacchetti Debian

Vengono forniti in questo capitolo alcune informazioni base da cui partire per imparare a programmare su un sistema Debian abbastanza da seguire il codice sorgente impacchettato. Quello che segue è un elenco dei pacchetti importanti per la programmazione e dei corrispettivi pacchetti di documentazione.

Guide di riferimento in linea sono disponibili digitando "man nome" dopo aver installato i pacchetti manpages e manpages-dev. Le guide di riferimento in linea per gli strumenti GNU sono disponibili digitando "info nome_programma", dopo aver installato i pertinenti pacchetti di documentazione. Può essere necessario includere gli archivi "contrib e non-free, oltre all'archivio main, dato che alcune documentazioni GFDL non sono considerate conformi alle DFSG.

Considerare l'uso degli strumenti dei sistemi di controllo di versione. Vedere Sezione 10.5, «Git».

[Avvertimento] Avvertimento

Non usare "test" come nome di un file di prova eseguibile. "test" è un comando interno della shell.

[Attenzione] Attenzione

I programmi software compilati direttamente dai sorgenti andrebbero installati in "/usr/local" o "/opt" per evitare conflitti.

[Suggerimento] Suggerimento

Esempi di codice per creare la "Canzone 99 bottiglie di birra" dovrebbe dare buone idee per praticamente tutti i linguaggi di programmazione.

Uno script di shell è un file di testo con il bit di esecuzione impostato e contiene i comandi nel formato seguente.

#!/bin/sh
 ... command lines

La prima riga specifica l'interprete di shell che legge ed esegue il contenuto di questo file.

Leggere script di shell è il modo migliore per capire come funzioni un sistema *nix. In questa sezione vengono forniti alcune nozioni di riferimento e promemoria per la programmazione di shell. Vedere "Errori in shell" (http://www.greenend.org.uk/rjk/2001/04/shell.html) per imparare dagli errori.

A differenza della modalità interattiva della shell (vedere Sezione 1.5, «Il semplice comando di shell» e Sezione 1.6, «Elaborazione di testo stile Unix»), gli script di shell usano spesso parametri, costrutti condizionali e cicli.

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.

  • con ":" l'operatore = controlla che il suo operando esista e sia non nullo

  • senza ":" l'operatore = controlla solo che il suo operando esista


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

  • Successo: 0 ("Vero")

  • Errore: non 0 ("Falso")

[Nota] Nota

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

[Nota] 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.

  • "comando && se_successo_esegue_anche_questo_comando || true"

  • "comando || se_non_successo_esegue_anche_questo_comando || true"

  • Una porzione su più righe di script come la seguente

if [ conditional_expression ]; then
 if_success_run_this_command
else
 if_not_success_run_this_command
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".

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

  • La shell legge una riga.

  • La shell raggruppa parte della riga come un unico elemento se è racchiusa in "…" o '…'.

  • La shell spezza le altre parti della riga in elementi in base ai caratteri seguenti.

    • Spazi bianchi: spazio tabulazione <a capo>

    • Metacaratteri: | ; & ( )

  • La shell controlla, per ciascun elemento non racchiuso tra "…" o '…', la presenza di parole riservate per regolare il proprio comportamento.

    • Parole riservate: if then elif else fi for in while unless do done case esac

  • La shell espande gli alias se non sono racchiusi in "…" o '…'.

  • La shell espande il carattere tilde se non è racchiuso in "…" o '…'.

    • "~" → directory home dell'utente attuale

    • "~utente" → directory home di utente

  • La shell espande parametri nei loro valori, se non sono racchiusi in '…'.

    • Parametro: "$PARAMETRO" o "${PARAMETRO}"

  • La shell espande sostituzioni di comandi, se non sono racchiuse in '…'.

    • "$( comando )" → output di "comando"

    • "` command `" → output di "comando"

  • La shell espande glob di nomi percorso nei nomi di file corrispondenti, se non sono racchiusi in "…" o '…'.

    • * → qualsiasi carattere

    • ? → un carattere

    • […] → uno qualunque dei caratteri in ""

  • La shell cerca comando tra le cose seguenti e lo esegue.

    • Definizione di funzione

    • comando interno

    • file eseguibile in "$PATH"

  • La shell si sposta alla riga seguente e ripete nuovamente questo processo dall'inizio di questa sequenza.

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.


Quando si desidera automatizzare un compito in Debian, si dovrebbe prima creare uno script per esso con un linguaggio interpretato. Le linee guida per la scelta del linguaggio interpretato sono:

  • Usare dash se il compito è semplice e combina programmi CLI con un programma della shell.

  • Usare python3 se il compito non è semplice e si sta cercando di scriverlo da zero.

  • Usare perl, tcl, ruby, ... se è disponibile del codice preesistente in Debian che usa uno di questi linguaggi e che deve essere ritoccato per fare il compito.

Se il codice risultante è troppo lento, si può riscrivere solo la porzione critica per la velocità d'esecuzione in un linguaggio compilato e chiamarla dal linguaggio interpretato.

Uno script di shell può essere migliorato per creare un attraente programma GUI. Il trucco è di usare uno dei cosiddetti programmi di dialogo invece di interazioni tristi che usano i comandi echo e read.


Ecco un esempio di programma con GUI per dimostrare come è semplice facile farlo con uno script di shell.

Questo script usa zenity per selezionare un file (in maniera predefinita /etc/motd) e visualizzarlo.

L'avviatore GUI per questo script può essere creato seguendo Sezione 9.4.10, «Avviare un programma dalla GUI».

#!/bin/sh -e
# Copyright (C) 2021 Osamu Aoki <osamu@debian.org>, Public Domain
# vim:set sw=2 sts=2 et:
DATA_FILE=$(zenity --file-selection --filename="/etc/motd" --title="Select a file to check") || \
  ( echo "E: File selection error" >&2 ; exit 1 )
# Check size of archive
if ( file -ib "$DATA_FILE" | grep -qe '^text/' ) ; then
  zenity --info --title="Check file: $DATA_FILE" --width 640  --height 400 \
    --text="$(head -n 20 "$DATA_FILE")"
else
  zenity --info --title="Check file: $DATA_FILE" --width 640  --height 400 \
    --text="The data is MIME=$(file -ib "$DATA_FILE")"
fi

Questo tipo di approccio ad un programma GUI con script di shell è utile solamente per casi di scelta semplice. Se si sta scrivendo un programma con funzioni complesse, considerare l'idea di scriverlo con una piattaforma con più potenzialità.


Qui sono inclusi Sezione 12.3.3, «Flex - un Lex migliorato» e Sezione 12.3.4, «Bison - Yacc migliorato» per indicare come programmi simili a compilatori possono essere scritti in linguaggio C compilando descrizioni di più alto livello in linguaggio C.

Si può impostare l'ambiente appropriato per compilare programmi scritti nel linguaggio di programmazione C nel modo seguente.

# apt-get install glibc-doc manpages-dev libc6-dev gcc build-essential

Il pacchetto libc6-dev, cioè la libreria GNU C, fornisce la libreria standard C che è una raccolta di file header e routine di libreria usati dal linguaggio di programmazione C.

Vedere come documenti di riferimento per C i seguenti.

  • "info libc" (documento di riferimento per le funzioni della libreria C)

  • gcc(1) e "info gcc"

  • ogni_nome_di_funzione_della_libreria_C(3)

  • Kernighan & Ritchie, "The C Programming Language", 2nd edition (Prentice Hall)

Flex è un veloce generatore di analizzatori lessicali compatibile con Lex.

Un tutorial per flex(1) viene fornito da "info flex".

È necessario fornire i propri "main()" e "yywrap()". Altrimenti il proprio programma flex dovrebbe apparire così per compilare senza una libreria. Questo è dovuto al fatto che "yywrap" è una macro e "%option main" abilita implicitamente "%option noyywrap".

%option main
%%
.|\n    ECHO ;
%%

In alternativa si può compilare con l'opzione per linker " -lfl" alla fine della propria riga di comando cc(1) (come "-ll" per AT&T-Lex). In questo caso non è necessario usare "%option".

Strumenti simili a lint possono aiutare nell'analisi statica del codice.

Strumenti simili ad Indent possono aiutare nella revisione manuale del codice riformattando in modo coerente il codice sorgente.

Strumenti simili a Ctags possono aiutare nella revisione manuale del codice generando un file indice (o tag) dei nomi trovati nel codice sorgente.

[Suggerimento] Suggerimento

Configurare il proprio editor preferito (emacs o vim) in modo che usi plugin per motori per lint asincroni aiuta nella scrittura di codice. Questi plugin stanno diventando molto potenti poiché sfruttano il Language Server Protocol. Dato che sono in continuo sviluppo, usare il codice originale a monte, invece dei pacchetti Debian, potrebbe essere una buona opzione.

Tabella 12.12. Elenco di strumenti per l'analisi statica del codice

pacchetto popcon dimensione descrizione
vim-ale I:0 2167 motore per lint asincrono per Vim 8 e NeoVim
vim-syntastic I:3 1240 trucchi per controllo della sintassi per vim
elpa-flycheck V:0, I:1 792 controllo della sintassi al-volo moderno per Emacs
elpa-relint I:0 133 strumento per trovare errori in regexp per Emacs Lisp
cppcheck-gui V:0, I:1 6253 strumento per l'analisi statica del codice C/C++ (GUI)
shellcheck V:2, I:10 15883 strumento lint per script di shell
pyflakes3 V:0, I:15 23 controllo passivo di programmi Python 3
pylint V:4, I:17 1653 strumento di controllo statico del codice Python
perl V:611, I:991 719 interprete con controllore interno statico del codice: B::Lint(3perl)
rubocop V:0, I:0 2390 strumento di analisi statica del codice Ruby
clang-tidy V:1, I:7 25 strumento per ling per C++ basato su Clang
splint V:0, I:3 2320 strumento per controllare staticamente la presenza di bug in programmi C
flawfinder V:0, I:0 205 strumento per esaminare codice sorgente C/C++ e per cercare punti deboli per la sicurezza
black V:1, I:6 559 formattatore di codice Python senza compromessi
perltidy V:0, I:5 2101 strumento per rientri e riformattazione di script Perl
indent V:0, I:11 425 programma per formattazione di codice sorgente in linguaggio C
astyle V:0, I:3 761 strumento per rientri in codice sorgente per C, C++, Objective-C, C# e Java
bcpp V:0, I:0 110 abbellitore di C(++)
xmlindent V:0, I:1 53 riformattatore di flussi XML
global V:0, I:3 1896 strumenti per ricerca e navigazione di codice sorgente
exuberant-ctags V:4, I:29 345 costruzione di file indice di tag di definizioni di codice sorgente

Il debug è un'importante fase del processo di programmazione. Sapere come fare il debug dei programmi rende buoni utenti Debian in grado di creare segnalazioni di bug sensate.


Lo strumento di debug principale in Debian è gdb(1) che permette di ispezionare un programma mentre viene eseguito.

Installare gdb e i programmi correlati nel modo seguente.

# apt-get install gdb gdb-doc build-essential devscripts

Un buon tutorial per gdb può essere trovato su:

  • info gdb

  • “Debugging with GDB” in /usr/share/doc/gdb-doc/html/gdb/index.html

  • tutorial sul web

Quello che segue è un piccolo esempio d'uso di gdb(1) su di un "programma" compilato con l'opzione "-g" per produrre informazioni di debug.

$ gdb program
(gdb) b 1                # set break point at line 1
(gdb) run args           # run program with args
(gdb) next               # next line
...
(gdb) step               # step forward
...
(gdb) p parm             # print parm
...
(gdb) p parm=12          # set value to 12
...
(gdb) quit
[Suggerimento] Suggerimento

Molti comandi gdb(1) possono essere abbreviati. L'espansione del tasto di tabulazione funziona come nella shell.

Dato che tutti i binari installati in un sistema Debian dovrebbero avere, in maniera predefinita, le informazioni di debug rimosse, la maggior parte dei simboli di debug non sono presenti nei normali pacchetti. Per poter fare il debug dei pacchetti Debian con gdb(1), è necessario installare i pacchetti *-dbgsym (es. coreutils-dbgsym in the case of coreutils). I pacchetti sorgente generano automaticamente pacchetti *-dbgsym insieme ai pacchetti binari normale e tali pacchetti di debug vengono messi nell'archivio separato debian-debug. Per maggiori informazioni fare riferimento agli articoli nel Wiki Debian.

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

$ mkdir /path/new ; cd /path/new
$ sudo apt-get update
$ sudo apt-get dist-upgrade
$ sudo apt-get install fakeroot devscripts build-essential
$ apt-get source package_name
$ cd package_name*
$ sudo apt-get build-dep ./

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 package_name*.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 da gdb(1) utilizzando uno dei seguenti approcci:

Per situazioni con cicli infiniti o tastiera bloccata, si può forzare il crash del programma premendo Ctrl-\ o Ctrl-C o eseguendo “kill -ABRT PID”. (Vedere Sezione 9.4.12, «Uccidere un processo».)

[Suggerimento] 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

Make è un'utilità per mantenere gruppi di programmi. Quando make(1) viene eseguito legge il file di regole, "Makefile" e aggiorna il file target se dipende da file prerequisiti che sono stati modificati dall'ultima volta che esso stesso è stato modificato oppure se il file target non esiste. L'esecuzione di questi aggiornamenti può avvenire in modo concorrente.

La sintassi del file di regole è la seguente.

target: [ prerequisites ... ]
 [TAB]  command1
 [TAB]  -command2 # ignore errors
 [TAB]  @command3 # suppress echoing

Qui "[TAB] è il codice di TAB. Ciascuna riga è interpretata dalla shell dopo la sostituzione delle variabili di make. Usare "\" alla fine di una riga per continuare lo script. Usare "$$" per inserire "$" per valori di ambiente per uno script di shell.

Regole implicite per il target ed i prerequisiti possono essere scritte, per esempio, nel modo seguente.

%.o: %.c header.h

In questo caso il target contiene il carattere "%" (esattamente un carattere). Il "%" fa corrispondenza con qualsiasi sottostringa non vuota nei nomi di file dei target effettivi. Similmente i prerequisiti usano "%" per mostrare come i loro nomi trovino corrispondenza nei nomi dei target effettivi.



Eseguire "make -p -f/dev/null" per vedere le regole interne automatiche.

Autotools è una suite di strumenti per programmazione progettata per assistere nella creazione di pacchetti di codice sorgente portabili su molti sistemi simil-UNIX.

  • Autoconf è uno strumento per produrre uno script di shell chiamato "configure" da "configure.ac".

    • "configure" è successivamente usato per produrre "Makefile" da un modello "Makefile.in".

  • Automake è uno strumento per produrre "Makefile.in" da "Makefile.am".

  • Libtool è uno script di shell per affrontare il problema della portabilità del software quando si compilano librerie condivise da codice sorgente.

Il sistema di compilazione del software si sta evolvendo:

  • Autotools basato su Make è stato lo standard di fatto per le infrustrutture di compilazione portabili sin dagli anni '90. È estremamente lento.

  • CMake inizialmente rilasciato nel 2000 ha migliorato significativamente la velocità, ma era ancora costruito sulla base dell'intrinsicamente lento Make.

  • Ninja inizialmente rilasciato nel 2012 è pensato per rimpiazzare Make per una velocità ulteriormente migliorata, ma è anche progettato per avere i propri file di input generati da un sistema di compilazione di più alto livello.

  • Meson rilasciato inizialmente nel 2013 è il nuovo popolare e veloce sistema di compilazione di più alto livello che usa Ninja come suo backend.

Vedere la documentazione in "The Meson Build system" e "The Ninja build system".

Pagine web dinamiche interattive di base possono essere create nel modo seguente.

  • Le interrogazioni vengono presentate all'utente del browser usando moduli HTML.

  • La compilazione e il cliccare sulle voci nel modulo invia una delle stringhe URL seguenti con i parametri codificati dal browser al web server.

    • "http://www.foo.dom/cgi-bin/program.pl?VAR1=VAL1&VAR2=VAL2&VAR3=VAL3"

    • "http://www.foo.dom/cgi-bin/program.py?VAR1=VAL1&VAR2=VAL2&VAR3=VAL3"

    • "http://www.foo.dom/program.php?VAR1=VAL1&VAR2=VAL2&VAR3=VAL3"

  • "%nn" nell'URL viene sostituito dal carattere con valore esadecimale nn.

  • Viene impostata la variabile d'ambiente: "QUERY_STRING="VAR1=VAL1 VAR2=VAL2 VAR3=VAL3"".

  • Il programma CGI (uno qualsiasi dei "program.*") sul server web è eseguito con la variabile d'ambiente "$QUERY_STRING".

  • Lo stdout del programma CGI viene inviato al browser web ed è presentato come pagina web dinamica interattiva.

Per ragioni di sicurezza è bene non creare a mano nuovi metodi per analizzare i parametri CGI. Per loro esistono moduli Perl e Python comprovati. PHP è fornito con queste funzionalità. Quando è necessaria l'archiviazione dei dati client vengono usati i cookie HTTP. Quando è necessaria l'elaborazione dei dati lato client, viene spesso usato Javascript.

Per maggiori informazioni vedere CGI (Common Gateway Interface), Apache Software Foundation e JavaScript.

Cercare "CGI tutorial" su Google digitando l'URL codificato http://www.google.com/search?hl=en&ie=UTF-8&q=CGI+tutorial direttamente nell'indirizzo del browser è un buon modo per vedere lo script CGI in azione sul server di Google.

Esistono programmi per convertire codice sorgente.


Se si desidera creare un pacchetto Debian, leggere i documenti seguenti.

Ci sono pacchetti come debmake, dh-make, dh-make-perl, ecc., che aiutano nella creazione dei pacchetti.