\articolo{EVPaths: Path ricorsivi per \TeX{} \& co.}{Giuseppe Ghibò}

\paragrafo{Introduzione}
\TeX{} è un programma di composizione tipografica creato nel 1978 dal
professor D.E.~Knuth.

Per sua natura, \TeX{} è particolarmente adatto alla composizione di
testi che contengono molta matematica. Knuth scrisse quello che possiamo
denominare \TeX 78\footnote{\TeX 78 era scritto in linguaggio
SAIL e funzionava solamente su DEC-10 e DEC-20.} inizialmente per
uso personale, per la composizione tipografica del volume 2
(e dei successivi) della sua opera magna: \emph{The Art of Computer
Programming}, tutt'ora oggetto di continue revisioni e sviluppi.
Nel 1982 Knuth riscrisse completamente \TeX{} in \web\footnote{\p{\scriptsize WEB}
è un linguaggio che si appoggia al Pascal e consente
di documentare il codice Pascal usando comandi di \TeX. Un'altra
caratteristica di \p{\scriptsize WEB} è che il codice può essere riorganizzato in
{\it moduli}. Un {\it modulo} può contenere una o più procedure
o anche una singola linea di codice. Ciascun modulo può essere preceduto
da un prologo scritto in \TeX{} che ne descrive il codice contenuto.
Per \p{\scriptsize WEB} è stato coniato il termine {\em literate programming}.}
curando soprattutto la portabilità verso altri sistemi e
rilasciò la versione 0 di \TeX.
Lo sviluppo di \TeX{} proseguì, con continue revisioni, fino
al settembre del '90, quando venne rilasciata la versione 3.1.
Da allora numerose altre versioni sono state rilasciate; l'ultima,
la 3.14159\footnote{Dalla versione 3.1 di \TeX{} e dalla
2.7 di \MF{}, la numerazione delle release di \TeX{} converge
asintoticamente al numero $\pi$ (a ogni release viene aggiunta una
cifra) mentre quella di \MF{} converge al numero \textit{e}, base dei
logaritmi naturali.}, proprio nel marzo di quest'anno\footnote{\MF{}
è stato aggiornato alla versione 2.718.}.  Tuttavia, a partire
proprio dalla versione 3.1 i sorgenti sono stati per così dire
``congelati'', e le successive revisioni riguardano soltanto
la correzione di bug esistenti, ma non l'aggiunta di nuove
caratteristiche. La prossima revisione è prevista per l'anno 1998.

Il port di \TeX{} è stato eseguito per numerosi sistemi, tra cui
anche l'\A, e gran parte di questi port è basato su una versione di
pubblico dominio scritta per Unix. Tale versione utilizza il programma
\p{WEB2C}\footnote{Il programma \p{\scriptsize WEB2C} fu inizialmente scritto da
Tom Rokicki, autore anche di \p{\scriptsize dvips} e di una versione commerciale
di \TeX{} per \A, ma altri autori vi hanno in seguito apportato
numerose modifiche e miglioramenti.} per convertire in maniera automatica il
codice Pascal del \TeX{} originale in linguaggio C\footnote{Nonostante
la conversione automatica, è stato riscontrato che la versione di
\TeX{} compilata dai sorgenti convertiti in C è spesso più
veloce della versione compilata (sulla medesima macchina) dai sorgenti
in Pascal. Bontà dei compilatori o del linguaggio C?}.

Veniamo ora all'\A e a \evpaths. I vari port di \TeX{} per \A, nonché
i port dei programmi accessori al \TeX{}, quali \MF, Bib\TeX,
MakeIndex, ecc., utilizzano le variabili environment per indicare
i {\it path}\footnote{In questo contesto per {\it path} intendiamo
un elenco di directory in cui ricercare un file.}. Ciascuno di questi
programmi, per funzionare, necessita infatti di file ``esterni'' (ad esempio
file di macro, file metrici per i font, ecc.) e i path sono necessari
proprio per indicare al programma in quale directory (o gruppo di directory)
ricercare i file di cui ha bisogno. Nell'ambito \A i port di questi
programmi sono spesso opera di persone differenti, ciascuna delle
quali ``adatta'' alla propria maniera le routine di gestione dei path
originariamente scritte per Unix. Questa pratica ha però condotto
inevitabilmente ad avere programmi che utilizzano per i path regole
differenti. Talvolta programmi diversi utilizzano la stessa variabile
environment, ma il fatto di avere regole differenti per i path, ne
rende alquanto difficoltosa, se non impossibile, la coesistenza
nell'ambito di una medesima installazione \TeX.
Un secondo problema riguarda la lunghezza delle variabili
environment: con la disponibilità di numerosi pa\-cka\-ge di macro
e font, la necessità di mantenere package differenti
in directory separate è di gran lunga cresciuta, tuttavia
la lunghezza massima ammissibile per le variabili environment, generalmente
di 255 caratteri\footnote{Questo non è un limite
imposto dall'AmigaDOS, bensì dal fatto che spesso le routine
di gestione dei path utilizzano la funzione C, di derivazione Unix,
chiamata \c{\scriptsize getenv()}.}, si è rivelata spesso insufficiente per
contenere l'elenco completo delle directory in cui sono disposti
tali pa\-cka\-ge. Queste sono alcune delle ragioni che mi hanno
spinto alla scrittura di \evpaths, con l'obiettivo di creare
un certo livello di ``standardizzazione'' per i path indicati nelle
variabili environment, nonché di superare i limiti di cui sopra.

\evpaths{} si presenta come una libreria linkabile contenente un
insieme di funzioni, da utilizzare nell'ambito di un programma C,
per la gestione dei path indicati nelle variabili environment.

\paragrafo{Caratteristiche}
Le caratteristiche principali di \evpaths{} sono le seguenti.
\begin{enumerate}
\item Le variabili environment usate per indicare un path possono avere
      lunghezza arbitraria.
\item Possibilità di ricercare le directory e le sottodirectory
      ricorsivamente.
\item Possibilità di nidificare più variabili environment fra loro.
\item Possibilità di usare i seguenti caratteri come separatori fra
      le directory di un path: la virgola, lo spazio, il punto e virgola,
      il carattere di tabulazione, il carattere di line-feed e quello di
      form-feed, in qualunque combinazione e in numero arbitrario.
\item Compatibilità con qualunque sistema operativo compreso tra
      l'1.3 e il 3.1.
\item Possibilità di linkare \evpaths{} anche con programmi che non
      facciano uso di alcun codice di startup.
\end{enumerate}
%
Esaminiamo ora i singoli punti.
%
\begin{enumerate}
\item {\bf Lunghezza arbitraria} delle variabile environment. Le variabili
      environment usate per specificare un path possono avere lunghezza
      arbitraria. È ovvio che se variabile sarà impostata da CLI tramite
      il comando DOS \c{setenv}, la sua lunghezza sarà troncata ai
      primi 255 caratteri; in tal caso non si potranno inoltre usare i
      line-feed come separatori fra le directory del path. Per
      avere variabili più lunghe di 255 caratteri occorrerà editare
      direttamente la variabile tramite un editor\footnote{Ad esempio per
      impostare un path nella variabile \c{\scriptsize TEXINPUTS}, basterà editare
      il file \c{\scriptsize ENV:TEXINPUTS}.}.
\item {\bf Ricorsione.} Aggiungendo semplicemente un \c{*} o
      \c{**} al nome di una directory di un path, apparterranno al
      path anche le rispettive sottodirectory; con il singolo \c{*}
      si includerà nel path tutto il primo livello di sottodirectory,
      mentre con \c{**} verrà incluso l'intero sotto-albero.
      Ad esempio, supponiamo di impostare la variabile \c{TEXINPUTS}
      tramite

\begin{codestyle}
Setenv TEXINPUTS TeXMF:tex**,Old:inputs*
\end{codestyle}

      \noindent in tal caso l'elenco delle directory del path assegnato alla variabile
      \c{TEXINPUTS} potrebbe essere del tipo

\begin{codestyle}
TeXMF:tex
TeXMF:tex/uno
TeXMF:tex/uno/due
TeXMF:tex/uno/due/tre
.
.
.
Old:inputs/uno
Old:inputs/due
\end{codestyle}

      \noindent Ciò significa che quando il programma cerca un file usando il
      path indicato in \c{TEXINPUTS}, esso verrà cercato in ciascuna
      delle directory sopra elencate\footnote{Ovviamente la ricerca si
      arresta non appena il file viene trovato.}.

      La possibilità di poter estendere la ricerca di un file a tutte le
      sottodirectory  di una data directory semplicemente aggiungendo un
      \c{*} o \c{**} al nome di quella directory è un indubbio
      vantaggio: consente una notevole economia di scrittura, nonché la
      possibilità di aggiungere o eliminare package di macro
      dall'installazione senza dover aggiornare ogni volta tutti i path.

      Qualcuno potrebbe obiettare che è sempre possibile disporre tutti
      i vari package di macro utilizzati, in un'unica directory (ad es.~\f{TeX:inputs}
      e che quindi, l'avere path ricorsivi (o più
      lunghi di 255 caratteri) sarebbe inutile o perlomeno superfluo. In
      realtà in un'installazione così ``monolitica'' si
      complicherebbe alquanto ogni tentativo di aggiornamento: non sapremmo
      più a quali package appartengono i file e dunque quali file
      aggiornare e quali rimuovere quando si installa una nuova versione.
      La situazione peggiorerebbe ulteriormente qualora due o più package
      avessero file con lo stesso nome oppure volessimo mantenere installate
      due versioni diverse del medesimo package (ad es.~\LaTeX{} 2.09 e \LaTeXe).

      Con la crescita del numero di package, font e ``accessori'' disponibili
      per \TeX{}, l'organizzazione della struttura delle directory è divenuta
      di notevole importanza, tant'è che il TUG\footnote{\TeX{}
      User Group.} ha fondato un gruppo, il TWG\footnote{TUG Working Group.},
      preposto alla definizione della migliore struttura di directory
      in cui organizzare i vari package di macro, i font, ecc.; tale struttura
      è stata denominata ``\TeX{} Directory Structure'', o brevemente
      TDS\footnote{Il documento TDS descrive una struttura ``base'', comune
      a tutti i sistemi.}.
      Nelle specifiche TDS\footnote{Per ulteriori informazioni sul TWG-TDS
      si rimanda l'attenzione del lettore al documento originale, contenuto
      nel file \f{\scriptsize TeXMF:doc/tds-1.1.1/tds.dvi}.} si raccomanda vivamente
      agli implementatori, il supporto dei path ricorsivi
      ({\it recursive path searching}).

      Un altro tipo problema che si aveva con le vecchie routine,
      era che in alcuni programmi i nomi delle directory nei path andavano
      indicati con il carattere `\c{/}' alla fine, mentre in altri
      programmi quel carattere non andava indicato. \evpaths{} supporta
      invece entrambe le notazioni e quindi avere \f{TeXMF:tex/latex/} o
      \f{TeXMF:tex/latex} è esattamente la stessa cosa, come pure per
      \f{TeXMF:tex/latex/**} e \f{TeXMF:tex/latex**}.

\item {\bf Variabili nidificate.} Nel path assegnato a una variabile
      environment è possibile specificare il nome di una o più altre
      variabili environment\footnote{Sono possibili fini a 5 livelli di
      nidificazione.}.
      Ad esempio, in un path di questo tipo

\begin{codestyle}
TeXMF:tex/plain,$LATEX,TeXMF:tex/eplain
\end{codestyle}

\noindent il contenuto della variabile \c{LATEX} verrà aggiunto all'elenco
      delle directory del path iniziale.

      Una caratteristica del genere
      apparentemente può sembrare inutile, ma in alcuni casi si rivela
      assai importante, come nel caso seguente.
      Supponiamo di avere un path ben più lungo di quello indicato
      sopra e di voler usare con \TeX{} sia \LaTeXe{}, sia \LaTeX{} 2.09. Questi
      due macro package presentano alcuni file col medesimo nome e dunque
      non è possibile includere le directory di ambedue i package nello
      stesso path, perché in tal caso, sarebbero comunque e soltanto
      letti i file del package che nel path è stato indicato per primo.
      La cosa più ragionevole da fare sarebbe quella di cambiare di
      volta in volta l'intero path, includendo ora le directory di
      \LaTeXe, ora le directory di \LaTeX{} 2.09. Questa pratica indubbiamente
      funziona, ma il cambiare ogni volta l'intero path associato a una
      variabile può risultare un'operazione decisamente
      noiosa\footnote{Alternativamente si potrebbe creare un batch file
      che svolga automaticamente l'intera operazione.}, soprattutto se
      il path iniziale è piuttosto lungo.

      Poiché \evpaths{} supporta la ricorsione anche nelle variabili
      environment, tanto vale usare questa caratteristica per ottenere
      lo stesso risultato. Basta creare altre due variabili environment,
      ad esempio \c{LATEXE} e \c{LATEX209}, così:

\begin{codestyle}
setenv LATEXE TeXMF:tex/latexe*
setenv LATEX209 TeXMF:tex/latex209*
\end{codestyle}

\noindent A questo punto quando vorremo usare \LaTeXe{} basterà dare
      (ovviamente prima di lanciare \p{virtex}):

\begin{codestyle}
setenv LATEX "$"LATEXE
\end{codestyle}

      \noindent mentre per \LaTeX{} 2.09 basterà usare:

\begin{codestyle}
setenv LATEX "$"LATEX209
\end{codestyle}

\noindent In questo modo, cambiando solamente la variabile \c{LATEX}
      (che ovviamente deve essere inclusa nella variabile iniziale)
      possiamo utilizzare \LaTeXe{} e \LaTeX{} 2.09 senza dover cambiare
      l'intero path.

\item {\bf Separatori.} Per separare le varie directory di un path fra
      loro, possiamo utilizzare ciascuno di questi caratteri:
      \begin{itemize}
      \item la virgola,
      \item il punto e virgola,
      \item lo spazio,
      \item il carattere di tabulazione,
      \item il carattere di line-feed e
      \item il carattere di form-feed
      \end{itemize}
      in qualunque combinazione e in numero arbitrario. Ad esempio
      possiamo editare la variabile \c{TEXINPUTS} in modo che contenga
      quanto segue:

\begin{codestyle}
TeXMF:tex/plain,  TeXMF:tex/latex**
CWeb:macros;  Old:inputs
^L^L
TeX:texinputs
\end{codestyle}

\noindent dove \c{\^{ }L} indica il carattere di form-feed.
      Notare che possiamo tranquillamente indicare nomi di directory
      contenenti spazi, virgole e punti e virgola (che sono appunto
      separatori) semplicemente includendo il nome della directory fra
      virgolette. Ad esempio, nomi ``esotici'' di questo tipo sono ammessi:

\begin{codestyle}
"Il LaTeX:",, "una,, ,,dir"
"una;;;,,,  ; altra dir"
\end{codestyle}

\noindent Per indicare la \emph{directory corrente}, \evpaths{} supporta
      la seguente simbologia

\begin{codestyle}
.   ""   "."
\end{codestyle}

      \noindent Per includere il path di default\footnote{Per ciascuna variabile
      environment è possibile assegnare un path di default, da utilizzare
      quando questa variabile non viene trovata dal programma.}
      in un punto arbitrario del path incluso nella variabile environment
      si può utilizzare il carattere \c{?}. Ad esempio supponiamo
      di avere il seguente path di default:

\begin{codestyle}
defp = "MF:fonts/ams/euler,MF:inputs";
\end{codestyle}

      \noindent e di impostare la variabile environment \c{MFINPUTS} tramite:

\begin{codestyle}
setenv MFINPUTS .,MF:inputs,?,CTAN:fonts
\end{codestyle}

      \noindent In tal caso l'elenco delle directory del path diviene

      \begin{tabular}{ll}
      \c{`'} &directory corrente,\\
      \c{`MF:inputs'} &da \c{MFINPUTS},\\
      \c{`MF:fonts/ams/euler'} &dal path di default,\\
      \c{`CTAN:fonts'} &da \c{MFINPUTS}.\\
      \end{tabular}

      \noindent Come si può notare, la directory \f{MF:inputs} è inclusa
      nell'elenco directory una sola volta: \evpaths{} cancella infatti
      i doppioni.

\item {\bf Compatibilità.} \evpaths{} è compatibile con qualunque
      versione del KickStart, a partire dalla versione 1.3. Poiché
      molti dei programmi relativi al \TeX{} e a cui doveva essere
      applicato \evpaths{} erano ancora compatibili con il KickStart
      1.3 (sebbene questo sia ormai praticamente in disuso) non ho
      ritenuto opportuno che fosse proprio la presenza di \evpaths{} la
      causa della perdita della compatibilità con quella release
      del sistema operativo. L'estensione della compatibilità
      di \evpaths{} anche al KickStart 1.3 non ne ha comunque condizionato le
      prestazioni, poiché laddove possibile sono state utilizzate
      funzioni della \f{dos.library} della release 2.1 del sistema operativo.
      In tal caso si è altresì provveduta l'emulazione delle
      funzioni utilizzate, anche per il KickStart 1.3.

\item {\bf Moduli di startup.} Come ho già accennato poc'anzi, \evpaths{} si
      presenta come una libreria linkabile. È possibile linkare
      \evpaths{} anche con programmi che non facciano uso\footnote{Il
      programma deve almeno definire e inizializzare \c{\scriptsize DOSBase}.} di
      alcun modulo di startup.
\end{enumerate}

\paragrafo{Programmazione}
L'uso delle routine di \evpaths{} all'interno dei propri programmi è
estremamente semplice e la procedura operativa da seguire è così
riassunta:
\begin{enumerate}
\item Definire un puntatore alla struttura \c{EnvVarPath}.\label{prog:one}
\item Specificare le dimensioni del buffer e il nome della variabile
      environment da associare al puntatore di cui al punto
      \ref{prog:one}, tramite la funzione \c{Alloc\_EnvVarPath()}.
\item Inizializzare la struttura di cui al punto \ref{prog:one} con il
      path di default\footnote{Per venire incontro alle esigenze dei
      programmatori è possibile specificare il path di default sia
      passando un'unica stringa in cui le varie directory del path sono
      separate da virgole, ecc., sia passando un array di stringhe,
      in cui ciascun elemento contiene una directory del path.}, tramite una
      chiamata alla funzione \c{Init\_EnvVarPath()}. Con questa chiamata
      verrà letto il contenuto della variabile environment e risolti
      eventuali path ricorsivi.
\item A questo punto siamo pronti per cercare un file. A tal scopo si
      può usare la funzione \c{EVP\_FileSearch()} che richiede tra gli
      argomenti il nome del file da cercare e il puntatore alla struttura
      inizializzata tramite la funzione \c{Init\_EnvVarPath()}. Quando
      si chiama la funzione \c{EVP\_FileSearch()} il file è cercato
      in ciascuna delle directory del path associato alla variabile
      environment. Se il file è trovato in qualche directory, allora
      verrà restituito il nome completo di quel file, altrimenti
      verrà restituito \c{NULL}. Accanto alla funzione
      \c{EVP\_FileSearch()} esistono le funzioni \c{EVP\_Open()} e
      \c{EVP\_fopen()}\footnote{La funzione \c{\scriptsize EVP\_fopen()} è
      disponibile solo nella libreria \f{\scriptsize EVPaths\_no.lib}.} che invece
      del nome del file, restituiscono rispettivamente il suo
      \c{BPTR} (come la funzione della \f{dos.library} \c{Open()})
      e \c{FILE *} (come la funzione \c{fopen()}).
\item Prima di terminare il programma occorre de-allocare tutti i puntatori
      allocati con \c{Alloc\_EnvVarPath()}, chiamando per ciascuno di
      essi la funzione \c{Free\_EnvVarPath()}.
\end{enumerate}

Vorrei infine aggiungere che le librerie linkabili di \evpaths{} sono
in realtà due\footnote{A seconda delle esigenze del programmatore,
un programma può essere linkato con l'una o l'altra di queste due
librerie.}: \c{EVPaths.lib} e \c{EVPaths\_no.lib}. Queste due
librerie contengono sostanzialmente le medesime funzioni, eccetto una:
nella libreria \c{EVPaths\_no.lib} la funzione \c{EVP\_Open()}
è stata sostituita dalla funzione \c{EVP\_fopen()}. Il motivo
di avere due librerie diverse è legato sostanzialmente all'allocazione
e alla deallocazione della memoria utilizzata dalle funzioni di
\evpaths{} per memorizzare le varie directory di un path. Se si usa la
libreria \c{EVPaths.lib}, tutte le variabili allocate con
\c{Alloc\_EnvVarPath()} devono essere {\it obbligatoriamente}
deallocate con \c{Free\_EnvVarPath()}, pena la perdita
definitiva\footnote{Per {\it perdita definitiva di memoria}, in questo contesto
si intende che i blocchi di memoria allocati dal programma che usa
\evpaths{} non saranno più disponibili al sistema operativo una
volta che il programma è terminato.} dei blocchi di memoria allocati. Questo
può essere un problema se il programma termina da più punti
diversi o in caso di interruzione da parte dall'utente tramite un
CTRL-C. In tal caso si deve essere sicuri che il programma termini in
un unico punto e inoltre occorre provvedere un signal handler che
intercetti i CTRL-C e chiami una funzione che provveda a deallocare
le variabili allocate, prima che il programma termini definitivamente.
Se il programmatore decide, o per necessità, o per scelta, di evitare
di scrivere un signal handler\footnote{Un signal handler si può
semplicemente aggiungere chiamando la funzione di libreria C,
\c{\scriptsize signal()}.} può sempre linkare il programma con la libreria
\c{EVPaths\_no.lib}. In questa libreria, infatti, tutte le funzioni allocano
la memoria di cui hanno bisogno tramite la funzione di libreria C
\c{malloc()} e quindi tutta la memoria allocata viene rilasciata
automaticamente non appena il programma termina (in qualunque punto) sia a
causa del flusso stesso del codice, sia per un'interruzione (CTRL-C) da
parte dell'utente. Lo svantaggio nell'uso della libreria
\c{EVPaths\_no.lib} è che non può essere linkata con un programma
che non faccia uso di alcun modulo di startup, come invece avviene per
la libreria \c{EVPaths.lib}.

\paragrafo{L'installazione \TeX{} di IPISA~'95}
L'installazione \TeX{} di IPISA~'95 comprende una
raccolta di programmi PD e freeware completa e, ovviamente, relativa
al \TeX.

Oltre al \TeX{} vero e proprio vi sono numerosi altri programmi, al
\TeX{} accessori, tra cui Bib\TeX, \MF, \MP, \dvips, ecc.; sono altresì
presenti numerosi package di macro e oltre 500 font appartenenti
a decine di famiglie differenti. L'intera installazione
comprende circa 25\,000 file e occupa quasi 300\,Mbyte!

Per quanto riguarda gli eseguibili essi sono principalmente basati
sulle distribuzioni di Pas\TeX{} 1.4 di Georg He{\ss}mann e
AmiWeb2C di Andreas Scherer. In quest'installazione alcuni dei
programmi installati sono i seguenti:
\begin{itemize}
\item \TeX{} 3.1415 (distrib.~Pas\TeX, comprende
        \p{initex}, \p{virtex}, \p{biginitex}, \p{bigvirtex})
\item \TeX{} 3.14159 (distrib.~AmiWeb2C, comprende
        \p{hugeinitex}, \p{hugevirtex})
\item \MF\footnote{In questa versione di \MF{} ho ottimizzato
        l'{\it inner loop} in linguaggio assembly. Ciò ha permesso
        di ottenere un guadagno in termini di prestazioni velocistiche
        dell'ordine del 30\%; tanto per dare un'idea, la font
        \f{\scriptsize cmr10} viene generata a 300 dpi in poco più di 8 minuti
        col solo 68000.} 2.718 (distrib.~AmiWeb2C, comprende
        \p{virmf}, \p{inimf}). \MF{} è un programma per la creazione
        di font da utilizzare con \TeX.

\item \MP{} 0.63 (distrib.~AmiWeb2C, comprende \p{mp}, \p{dvitomp}).
      \MP{} è un linguaggio grafico sostanzialmente simile a \MF. A
      differenza  di \MF, il suo output è in Post\-Script, il che ne
      fa uno strumento utile e potente per la creazione di figure e grafici
      da includere, per esempio, nei documenti \LaTeX{} (ovviamente in
      formato EPS). Documentazione: \f{TeXMF:doc/metapost}.

\item \dvips{} 5.58. È un \emph{DVI processor} e consente di convertire un
      file \f{.dvi} in PostScript, pronto per essere stampato.
      Documentazione: \f{TeXMF:doc/dvips}.

\item afm2tfm 7.9. Converte un file metrico, dal formato AFM (Adobe Font
      Metric) al formato TFM di \TeX.

\item Bib\TeX{} 0.99c (distrib.~AmiWeb2C). È un programma per la creazione
      di bibliografie per \LaTeX{}, partendo da informazioni bibliografiche
      raccolte sotto forma di database.
      Documentazione: \f{TeXMF:doc/bibtex}.

\item MakeIndex 2.13. Consente l'ordinamento degli indici creati con \LaTeX.

\item Midi2\TeX{} 1.2. Converte un file Midi \f{.mid} in un formato adatto a
      essere elaborato da Music\TeX.

\item \showdvi/\dviprint{} 1.42 (distrib.~Pas\TeX). \showdvi{} è un
      previewer di file DVI. \dviprint{} è un {\it DVI printer driver}
      e consente la stampa di file DVI.

\item \shost{} 1.29. È un programma usato da \showdvi{} e \dviprint{} per
      la gestione delle direttive {\small\verb+\special+}.

\item GFtoPK 2.3, DVICopy 1.4, PKType 2.3, PoolType 3,
      PatGen 2.0, VPtoVF 1.4, VFtoVP 1.2, PLtoTF 3.5,
      TFtoPL 3.1, Tangle 4.4, Weave 4.4. Tutte queste
      utility fanno parte della distribuzione
      \TeX{} di Knuth (\TeX ware e MFware) e sono state generate
      utilizzando AmiWeb2C.
\end{itemize}

Gran parte di questi programmi utilizzano \evpaths.
Tutti i programmi (tranne tre\footnote{\showdvi, \dviprint{} e
\shost{} necessitano di almeno la versione 2.1 del sistema
operativo; in più \shost{} necessita di MUI.}) funzionano su
qualunque \A dotato di almeno la versione 1.3 del sistema operativo e
di processore 680x0 (x=0, 1, 2, 3, 4, 6).

Oltre ai suddetti eseguibili l'installazione comprende numerosi package
di macro, tra cui:
\begin{itemize}
\item \LaTeXe, issue 3 (giugno 1995). Documentazione: \f{TeXMF:doc/latex}.
\item \LaTeX{} 2.09.
\item AMS\TeX, AMS\LaTeX. Sono due package che contengono macro per la
      costruzione di formule matematiche particolarmente complesse.
      Documentazione: \f{TeXMF:doc/ams}.
\item Music\TeX, Musix\TeX. Sono package di macroistruzioni che consentono
      la creazione di spartiti musicali. Documentazione: \f{TeXMF:doc/musictex}
      e \f{TeXMF:doc/musixtex}.
\item Babel 3.5. È un package per l'uso del \LaTeX{} in più lingue.
      Documentazione: \f{TeXMF:doc/babel}.
\item Xy-Pic 3.1. È un package di per la creazione di grafici e
      diagrammi commutativi. Documentazione: \f{TeXMF:doc/generic/xypic}.
\item \TeX draw. È un package per la creazione di disegni generici (ad
       esempio diagrammi a blocchi). Documentazione: \f{TeXMF:doc/texdraw}.
\item PSTricks. È un package per la creazione di disegni generici.
      Documentazione: \f{TeXMF:doc/pstricks}.
\item eplain. Documentazione: \f{TeXMF:doc/eplain}.
\end{itemize}

La struttura in cui sono organizzate le directory di quest'installazione
è ispirata\footnote{Si è detto ``ispirata'' e non ``conforme''
perché per questioni di efficienza nella ricerca dei file, si è
omesso di suddividere ulteriormente i font \f{\scriptsize pk} in base al
``font supplier'' e al ``typeface''. D'altro canto le specifiche TDS
consigliano di seguire questa ulteriore suddivisione solo se le
routine di gestione dei path hanno opportuni meccanismi di {\it cache}
o supportano qualche sorta di {\it file database}.} alla specifiche TDS.

\paragrafo{\TeX{} \& \LaTeX: cenni}

Nell'ambito di quest'articolo molto si è detto di \evpaths{} e ben poco di
\TeX{} e \LaTeX. Di \TeX{} si è infatti soltanto detto che è un programma
di composizione tipografica particolarmente orientato alla composizione
di testi che contengono molta matematica.

Per quanto riguarda \TeX, occorre anzitutto puntualizzare che esso
non fa parte di quella categoria di programmi generalmente classificati
con la sigla {\it wysiwyg}\footnote{{\it What you see is what you get.}},
in cui si può vedere subito il risultato della composizione. Nell'ambiente
\TeX, invece, il testo da impaginare deve essere scritto con un comune
editor in un file, avente generalmente estensione \f{.tex}. In
questo file, oltre al testo vero e proprio, devono essere riportate
alcune informazioni su come il testo deve essere composto
(ad esempio quali parti del testo devono essere composte in grassetto, quali
in neretto, ecc.). Dopodiché si ``lancia'' \TeX{} su questo file
\f{.tex} e come risultato dell'elaborazione si ottiene un file
avente estensione \f{.dvi}\footnote{Il file \f{\scriptsize.dvi} è
un file binario e contiene istruzioni per i cosiddetti {\it DVI processor},
programmi in grado di eseguire un'elaborazione delle informazioni contenute
nei file DVI.} ({\it device indipendent}). Questo file
conterrà il testo impaginato, che potrà essere visualizzato sullo
schermo tramite un programma denominato {\it DVI previewer} o
semplicemente {\it previewer}.

Per capire che relazione intercorre tra \TeX{} e \LaTeX{} è opportuno
fare una precisazione. \TeX{}, più che un semplice programma di
composizione tipografica, è un {\it linguaggio di macroistruzioni} e
come tutti i linguaggi è dotato di un certo numero di primitive. Queste
primitive sono tuttavia di basso livello e non possono essere utilizzate
direttamente da un'autore per comporre il testo, ma occorre un file
di macroistruzioni che utilizzi alcune di queste primitive
per la costruzione di comandi ad alto livello, facilmente utilizzabili
dall'autore-compositore. Il file di macroistruzioni di default
fornito col \TeX{} e scritto da Knuth è il file
\f{plain.tex}\footnote{Questo file viene generalmente pre-elaborato,
insieme a uno o più altri file contenenti i pattern per la divisione
in sillabe e i font da pre-caricare, formando un cosiddetto file
di formato (\it format file).}. Esso contiene istruzioni che
definiscono i font da usare per la composizione del testo e delle formule
matematiche, il carattere da usare per i commenti, ecc., nonché un discreto
numero di macroistruzioni elementari di uso generico.

\LaTeX{}\footnote{La denominazione \LaTeX{} deriva dal nome del suo autore,
Leslie Lamport.}, non è nient'altro che un package, contenente
macroistruzioni scritte utilizzando le primitive del \TeX{}.
Contiene quasi tutte le macroistruzioni del \f{plain.tex} e in più
ne aggiunge di nuove, facilitando notevolmente il lavoro di un autore nella
composizione di un testo. Utilizzando \LaTeX{} ad esempio è
possibile avere la numerazione automatica delle formule, dei titoli
dei capitoli, dei paragrafi, ecc.
Vediamo ora un semplice esempio di un file scritto per essere compilato
utilizzando \LaTeX:

{\small\begin{verbatim}
\documentclass{article}
\begin{document}
Si possono impaginare le {\em formule
matematiche} così:
\begin{equation*}
e^x = \sum_{n=0}^\infty {\frac{x^n}{n!}}
\end{equation*}
\end{document}
\end{verbatim}}

\noindent che, una volta elaborato da \LaTeX, produce il seguente
risultato:
\vspace{1ex}
\hrule
\vspace{3mm}
Si possono impaginare le {\em formule matematiche}
così:
\begin{equation*}
e^x=\sum_{n=0}^\infty {\frac{x^n}{n!}}
\end{equation*}
\hrule
\vspace{3mm}

Per usare quest'esempio con l'installazione \TeX{} di IPISA~'95
si può seguire la seguente procedura:
\begin{enumerate}
\item Clickare sull'icona ``SetTeX''.
\item Aprire una Shell e lanciare \f{s/texaliases}.
\item Copiare in un file, ad es.~\f{prova.tex}, l'esempio riportato.
\item Lanciare `\c{latex prova.tex}'.
\item Per visualizzare il file elaborato usare `\c{ShowDVI prova.dvi}'.
\item Per stampare il documento si può usare `\c{DVIPrint prova.dvi}' o
      `\c{dvips prova.dvi}'. Nel secondo caso verrà prodotto un file
      PostScript.
\end{enumerate}

\paragrafo{Il futuro di \TeX}
Come ho già accennato in precedenza, lo sviluppo, inteso come
implementazione di nuove caratteristiche, di \TeX, \MF{} e dei
{\it Computer Modern Fonts} è terminato nel 1990, con la release 3.1
di \TeX{} e la 2.7 di \MF. Da allora sono state comunque rilasciate
numerose altre versioni\footnote{Dal '90 al '95 sono state rilasciate
quattro nuove release di \TeX{} (le 3.14, 3.141, 3.1415 e quest'anno
la 3.14159) e due di \MF{} (la 2.71 e quest'anno la 2.718).} di \TeX{}
e \MF{}, in ciascuna delle quali sono stati corretti dei bug.

Il fatto che Knuth abbia terminato lo sviluppo di \TeX{} non vuol
affatto dire che egli abbia abbandonato il \TeX{} definitivamente, ma
semplicemente che ha ritenuto il \TeX{} un linguaggio oramai maturo e
completo. Ne è la prova che mai come in questi ultimi anni \TeX{} ha
avuto un così elevato numero di utenti, implementatori, fan, ecc.

Per quanto riguarda i sorgenti di \TeX{} e \MF, Knuth ha dichiarato
che sono liberi e che chiunque (persona o gruppo) voglia produrre un
sistema superiore al suo è libero di farlo, ma non gli è consentito
l'uso dei nomi \TeX{} e \MF{} a meno che quel sistema non sia
conforme\footnote{Per {\it conforme} si intende che il programma
deve superare dei test, scritti da Knuth e chiamati
``trip and trap tests''.} al 100\% ai suoi programmi.
A tal proposito proposito esiste un progetto, denominato
``The New TypeSetting System'', o brevemente NTS\footnote{Il progetto
NTS è supportato anche finanziariamente da alcune organizzazioni.}, di
un gruppo, guidato da Phillip \hbox{Taylor}, il cui scopo è quello di creare un
sistema migliore di \TeX. Attualmente il progetto è suddiviso
in due parti; una parte, a ``breve termine'', denominata e-\TeX
(extended \TeX) e una, a ``lungo termine'' rappresentata dall'NTS vero
e proprio. Nell'e-\TeX\footnote{Attualmente una prima beta-release di
e-\TeX{} è in fase di completamento.}, alcune nuove caratteristiche non
presenti nel \TeX{} di Knuth (come la possibilità di comporre testi
da ``destra verso sinistra'') sono implementate in un change file
(scritto in \web) da applicare ai sorgenti originali di Knuth (anch'essi
scritti in \web). Nell'NTS, invece, l'intero sistema verrà riscritto,
probabilmente in linguaggio C++ e ovviamente in forma di {\it literate
programming}, come già avviene per il \web.

\paragrafo{Ringraziamenti}
Un ringraziamento particolare a Roberto Tosco, per aver generosamente
messo a disposizione il proprio hardware per la generazione dei circa 200\,Mbyte
di font \c{pk} dell'installazione \TeX.

\begin{thebibliography}{99}
\bibitem{knuth} Donald~E.~Knuth. {\it The \TeX book}. Addison-Wesley, Reading,
        Massachusetts, 1986, ISBN 0-201-13447-0.

\bibitem{lamport} Leslie Lamport. {\it \LaTeX: A Document Preparation
        System}. Reading, Massachusetts, seconda edizione, 1994, ISBN
        0-201-52983-1.

\bibitem{companion} M.~Goossens, F.~Mittelbach, A.~Samarin, {\it The \LaTeX{}
        Companion}. Addison-Wesley, Reading, Massachusetts, 1994, ISBN
        0-201-54199-8.

\bibitem{beccari} Claudio~Beccari, {\it \LaTeX: guida a un sistema di
        editoria elettronica}. Hoepli, Milano, 1991, ISBN 88-203-1931-4.

\bibitem{knuthmf} Donald~E.~Knuth. {\it The \MF book}. Addison-Wesley, Reading,
        Massachusetts, 1986, ISBN 0-201-13445-4.
\end{thebibliography}

\autore{Giuseppe Ghibò\\
Via Sestriere 133\\
I-10090 Cascine Vica (Rivoli) TO}
{Internet: ghibo@galileo.polito.it}

\citazione{\selectlanguage{english}When someone says, ``I want a programming language
in which I nee only say what I wish done,''
give him a lollipop.}
{Alan Perlis, \emph{Epigrams on Programming}, 1982}