Desriviamo le fasi "standard" di installazione di uno script CGI su un server remoto.

La prima cosa da prendere in considerazione è sicuramente la locazione dell'interprete Perl installato sul server che ospita le vostre pagine web: se notate, in ogni script (quindi file con estensione .pl o .cgi) la prima riga inizia con un

#!

seguito da una directory (nei sistemi Unix, le directory si indicano con le slash [ / ], come si usa fare in internet, e non con le backslash [ \ ] come succede nei sistemi Windows) che altro non è che la directory che contiene l'eseguibile dell'interprete Perl.
Purtroppo, la locazione dell'interprete non è standard, ma varia a seconda del sistema installato sul server e da come lo stesso è stato configurato dall'amministratore.
Alcune locazioni abbastanza standard sono:

#!/usr/bin/perl #!/usr/local/bin/perl

ma non si può mai essere sicuri che una delle due sia quella che fa al caso nostro: per sciogliere questo dubbio basterà collegarci all'home page di chi ospita le nostre pagine e cercare le FAQ (Frequently Asked Questions) dove sarà sicuramente indicata la locazione dell'interprete Perl installato sulle loro macchine. Per chi sia così fortunato da avere un accesso telnet, invece, basterà leggere l'output del comando:

which perl

lanciato ovviamente dalla shell.

La seconda fase solitamente è quella del settaggio delle variabili.
Intanto: perchè esistono le variabili?
Dal nome, dovrebbe essere chiaro: visto che i sistemi sono differenti gli uni dagli altri, directory, percorsi ed URL non possono essere standard. Inoltre, essendo appunto variabili (inteso qui come aggettivo), permettono un certo grado di configurabilità per lo script, in modo che ognuno possa personalizzare alcuni comportamenti dello script come ritiene più opportuno (mi sto riferendo alle directory che contengono i file dei dati degli script, il modo di visualizzarne l'output e simili).
Solitamente, le variabili sono interne agli script veri e propri, ma in alcuni casi possono essere contenute in altri file, il cui nome potrebbe essere qualcosa del tipo:

nomescript.cfg
config.txt
config
setup.pl - .cgi
nomescriptsetup

e via dicendo: in ogni caso, comunque, questi file hanno un nome che vi fa capire subito che si tratta di file di configurazione. Non ci interessa qui vedere come questi file vengono letti ed interpretati dallo script, sappiate solo che questo è il ruolo che tali file ricoprono. Dove si parla di variabili, inoltre, si parla anche di commenti; spesso infatti per ogni variabile vediamo qualcosa del tipo:

# Descrizione
$variabile= ....

E' importante sapere che tutte le righe che iniziano con il cancelletto ( # ) sono chiamate "commenti", ossia vengono tralasciate dall'interprete in fase di compilazione degli script, ma servono solo a chi scrive o legge il codice come "promemoria" o chiarimento. Quindi, le righe sopra ad una variabile che iniziano con il cancelletto altro non sono che una spiegazione del valore della variabile, che è stato introdotto dall'autore presumibilmente per semplificare il procedimento di configurazione-personalizzazione del suo script, e che dovrebbero aiutarci non poco a capire il significato di ogni variabile.

Anche per le variabili non ci sono degli standard: alcune si riferiscono ad URL, altre a percorsi interni, altre ancora a titoli, nomi, colori e quant'altro; ricordiamo quanto detto poche righe sopra e capiremo l'importanza di leggere i commenti introdotti dall'autore.
Ricordiamo ancora un paio di cose che sembrano banalità ma che spesso sono cause di "Error 500"!! Il Perl utilizza dei caratteri speciali e riservati, uno tra tutti la chiocciola ( @ ) per indicare la presenza di un array. Se dovete inserire la chiocciola come valore di una variabile, ricordatevi di inserire davanti a questa anche un backslash che indica all'interprete di interpretare (mi si scusi il gioco di parole) letteralmente il carattere. I caratteri speciali più utilizzati sono: $, ", \, ! (sebbene ve ne siano molti altri).

I percorsi, che nei sistemi Unix si indicano come /percorso/della/directory nei sistemi Windows si indicano come \\percorso\\della\\directory ossia con le backslash precedute da un carattere di escape per il discorso fatto sopra.

Anche se non si parla propriamente di variabili, può accadere di dover modificare, invece che il codice di uno script, il codice di una pagina HTML, ossia l'indice dello script. Molto probabilmente, in queste pagine dovremo andare a modificare dei links che punteranno allo script vero e proprio; sapendo dove lo script sarà caricato, sarà molto semplice far puntare i links allo script stesso, con una piccola attenzione: a volte è necessario passare determinati parametri allo script nel formato http://www.vostroserver.it/cgi-bin/nomescript.cgi?PARAMETRO.
Quindi, nel caso in cui dobbiate modificare un link di tal genere in modo che punti allo script installato sul vostro server, fate grande attenzione a non dimenticare i parametri.

Una volta che le variabili sono impostate (si spera correttamente) si passa al trasferimento dei file: sembra una banalità, ma molto spesso questo passaggio crea non pochi problemi agli utenti. L'upload, sia che venga fatto direttamente dalla linea di comando che tramite qualche programma apposito, deve sempre essere effettuato in ASCII mode: il formato ASCII è lo standard per i file di testo, quali ad esempio i file di cui sono formati i nostri script.

Nei programmi dedicati all'FTP, si noterà da qualche parte nella finestra principale (oppure nelle "opzioni" del programma, se proprio l'autore ha voluto complicare le cose) la possibilità di scegliere come i file devono essere caricati: spesso le opzioni tra cui scegliere sono tre: ASCII, binary ed auto. La prima, che è quella che ci serve per le nostre operazioni, è stata brevemente discussa poche righe sopra, la seconda, invece, fa sì che i nostri script non girino sul server, visto che caricare un file di uno script in binary mode equivale alla certezza che questo non possa mai essere eseguito correttamente dal server. La terza opzione lascia molta discrezionalità al programma che stiamo utilizzando visto che (in teoria) esso fa una rapida scansione dei file da caricare e decide come essi devono essere spostati sul server; questa opzione è utile quando si devono caricare in remoto diversi tipi di file, senza per ognuno andare a decidere la modalità dell'upload.
Ma anche questa, che sembra una grande comodità, ha i suoi svantaggi: spesso infatti i programmi si basano sull'estensione dei file, e tramite questa risalgono al loro tipo, senza curarsi troppo di cosa sia effettivamente contenuto all'interno del file stesso. Esistono dei metodi più esatti per un tale tipo di determinazione, che comunque non vedremo in questa sede.
Per chi utilizzi l'FTP direttamente da linea di comando, invece, la modalità ASCII dovrebbe essere la modalità di default: per accertarvene, lanciate il comando "ascii" una volta che siete collegati all'host.

Una volta che i file sono caricati bisognerà impostarne i permessi: non ci soffermeremo qui a parlare di come si impostano i permessi sui file, ci interesseremo piuttosto a prendere in esame alcuni casi particolari:
· I file con estensione .pl o .cgi: questi file sono a tutti gli effetti i nostri file eseguibili ma, appena caricati sul server, perdono tale caratteristica (a meno che il vostro host remoto non sia uno di quelli che impostano automaticamente i permessi per gli script da voi caricati). Vista la loro condizione di "inutilità" sul server nelle attuali condizioni, dobbiamo per forza renderli eseguibili con il comando chmod 755 nomefile.
La domanda più ovvia a questo punto è: devo rendere eseguibili tutti i file con estensione .pl o .cgi? La risposta è "sarebbe meglio", tuttavia non è sempre necessario. Supponete di avere uno script che consta di tre file .cgi, script1.cgi, script2.cgi e script3.cgi e che script1.cgi sia il file principale dello script: ovviamente, script1.cgi deve da noi essere reso eseguibile, ma gli altri due? Dipende da come è stato scritto lo script! Nel caso gli altri due script siano chiamati all'interno di script1.cgi con comandi del tipo: perl script2.cgi

allora non è necessario che lo script sia eseguibile, in quanto con tale sintassi si chiama in gioco l'interprete che provvede da solo ad eseguire lo script. In altri casi, invece, questo non è possibile, e tutti i tre file devono essere resi eseguibili "a mano". Per chi si chieda come distinguere questi due casi, non disperate, non è necessario leggersi uno ad uno i codici degli script: spesso nei file di aiuto inseriti dall'autore all'interno è ampiamente spiegato quali file necessitano di essere resi eseguibili e quali no. In caso le parole dell'autore siano ambigue o non venga fatta distinzione alcuna, sappiate che rendere eseguibile tutti i file .pl o .cgi non è sbagliato e può togliervi molti problemi.

· Discorso differente va fatto per gli altri file: con la premessa che anche per tutti gli altri file dovreste trovare le istruzioni dell'autore, supponiamo di avere a che fare con un counter: lo script traccia tutte le hits ad un determinato sito e, ovviamente, dovrà anche memorizzarle per poterle incrementare di un'unità ogni volta che un nuovo visitatore arriva sulle pagine del sito.
Ovviamente, i dati del counter sono immagazzinati in un altro file separato dal counter stesso. Immaginate ora due casi: il file (chiamiamolo data.dat) non sia leggibile o non sia scrivibile.

Nel primo caso, il counter si lamenterà per il fatto che il file da cui deve leggere quanti visitatori sono già passati per il sito non è leggibile, e quindi, nel caso in cui non fallisca completamente, interpreterà tale dato come uno zero, e segnerà ogni visitatore come fosse il primo.

Nel secondo caso, invece, riuscirà a leggere il file, ma cosa leggerà mai, se non ha mai potuto scriverci? Ancora, quindi, ogni visitatore sarà il primo (sempre nel caso in cui lo script non fallisca).

Come regolarsi, in questi casi? Sicuramente se l'autore non dice niente la sua serietà è da mettere in dubbio e spetterà a voi capire quali file devono essere scritti e letti dallo script ed impostarne i pemessi di conseguenza; personalmente, comunque, di script ne ho visti davvero tanti, e solo in un paio di occasioni mancavano le istruzioni su come impostare i permessi. In caso anche voi vi troviate in una simile condizione, fate un atto di generosità ed avvertite l'autore per email.
L'ultima fase è il testing dello script appena installato sul server. Cosa succede se non funziona? O, peggio, adesso che abbiamo installato lo script non sappiamo più dove andare a cercarlo.
E' difficile perdersi tra i link del proprio sito, ma a volte qualche script, se richiamato dal browser come:

http://www.vostroserver.it/cgi-bin/nomescript.cgi

risponde con strani messaggi di errore, comunque differenti dall'odiato Error 500. In questo caso, presumibilmente, bisognerà passare allo script qualche parametro, come:

http://www.vostroserver.it/cgi-bin/nomescript.cgi?admin

per fargli capire, ad esempio, che vogliamo entrare nella schermata riservata all'amministratore dello script stesso. Questo succede negli script che richiedono delle impostazioni preliminari che devono essere fatte direttamente dall'amministratore (presumibilmente voi): senza queste impostazioni, non si può accedere direttamente allo script. Comunque, non preoccupatevi: gli autori non si dimenticano mai di dirvi l'URL alla quale collegarvi per la prima esecuzione, compresi i parametri che dovrete passare allo script.

Discorso leggermente differente va fatto nel caso in cui nell'archivio dello script sia presente un file index.html o nomescript.html: probabilmente, questo file sarà appunto l'indice dello script al quale dovrete collegarvi tramite browser.

Passiamo al secondo caso: lo script si blocca ed esce con un messaggio d'errore.
Credo che pochi abbiano accesso diretto al sistema, potendo così andarsi a leggere i log.
Quindi, dovremo procedere per tentativi:

· La prima cosa da controllare sono i permessi dei file: permesso sbagliato = script bloccato

· Bisognerà poi assicurarsi di aver caricato tutti i file relativi allo script in ASCII mode.

Se ancora lo script dà problemi, controllate che la prima riga degli script rifletta la reale locazione dell'interprete Perl installato sul server. Se il webserver non trova l'interprete che deve eseguire lo script, il processo di esecuzione si bloccherà.

· Quarta cosa da controllare sarà l'impostazione delle variabili: se avete indicato directory inesistenti, o avete immesso come valore di una variabile il vostro indirizzo email come nome@host.com (che dovrebbe essere invece nome\@host.com), o ancora vi siete dimenticati di inserire qualche backslash davanti ai caratteri riservati o chissà cos'altro ancora, lo script sarà terminato prematuramente.
Il primo caso da prendere in considerazione è che state utilizzando uno script scritto su un sistema diverso: ad esempio se utilizzate uno script adatto a sistemi Unix (vuoi perchè cerca determinati moduli, vuoi perchè è strutturato in modo particolare) su un sistema Windows: in questo caso c'è veramente poco da fare, a meno di riscriversi lo script.

Il secondo caso è che stiate utilizzando uno script scritto in Unix ("in", non "per") su un server Windows: per curiosità andate ad aprire lo script con il blocco note, e cercate di capirne qualcosa. Questo perchè i due sistemi utilizzano degli standard differenti per i "Carriage Return", non contemplati (o almeno non completamente) da sistemi differenti: la soluzione è quella di aprire i file con potenti editor di testo che dovrebbero riuscire ad importare correttamente i file (da qualunque fonte essi vengano) oppure utilizzare degli appositi tools di conversione, come unix2dos o dos2unix. Ovviamente il discorso appena fatto vale sia per script Unix utilizzato sotto Wondows che viceversa. Per farvi un esempio, se da linux eseguo (direttamente da shell) uno script scritto con un editor Dos, ottengo:

Illegal character \015 (carriage return) at script.cgi line 2.
(Maybe you didn't strip carriage returns after a network transfer?)

L'interprete stesso mi parla di qualche errore legato allo "strip" dei ritorni a capo: con un "dos2unix nome_dello_script" converto il formato del file e l'errore sparisce.

L'ultimo doloroso caso è: lo script ha qualcosa che non va, ossia qualche errore di scrittura del codice (rarissimo, ma si trova). Il suggerimento è di eseguire lo script direttamente dalla shell e vedere cosa vi dice l'interprete, correggendo gli errori che vi riporta.

E con questo abbiamo finito di illustrare i passi standard per l'installazione e la configurazione di uno script sul nostro server. Come certamente avrete notato, le cose da ricordare sono molte e devono essere rispettate dalla prima all'ultima per essere sicuri che lo script non si blocchi o dia problemi: non spaventatevi, con un po' di pratica imparerete a gestire un'installazione senza troppi problemi, l'importante è avere la possibilità di eseguire le vostre prove errando e correggendo gli errori. Ed è per questo che il mio consiglio è sempre quello di installarsi in locale un webserver e l'interprete Perl.