Script

Il termine script, in informatica, designa un tipo particolare di programma, scritto in una particolare classe di linguaggi di programmazione, detti linguaggi di scripting. Una classe specifica di tali programmi sono i cosiddetti shell script, ossia script concepiti per essere eseguiti all'interno di una shell di un sistema operativo

Descrizione

La distinzione tra un programma normale ed uno script non è netta, ma generalmente negli script si possono individuare le seguenti caratteristiche:

complessità relativamente bassa;
utilizzo di un linguaggio interpretato;
integrazione in un processo di configurazione automatica del sistema (ad esempio ad ogni avvio, o ad ogni login di un dato utente), in una pagina web (tipicamente utilizzando il linguaggio JavaScript), o comunque per svolgere mansioni accessorie e molto specifiche;
una certa linearità (uno script può anche accettare input dall'utente, ma solitamente input diversi non modificano sostanzialmente la struttura del diagramma a blocchi che descrive il comportamento dello script);
mancanza di una propria interfaccia grafica;
richiamo di altri programmi per svolgere operazioni più sofisticate.

Script di shell

Lo script di shell identifica uno script per una shell testuale di un sistema operativo, ovvero l'interfaccia a riga di comando, il cui linguaggio è considerato un semplice linguaggio di programmazione per un determinato dominio. Uno script di questo genere esegue tipicamente operazioni legate all'amministrazione di sistema come la manipolazione di file (p. es. rinomine, copie o spostamenti), l'esecuzione di altri programmi, la stampa e la manipolazione di testo. Il vantaggio principale, nonché più diffusamente sfruttato, rispetto all'interazione diretta con la shell digitando un comando dopo l'altro, è l'automazione, cioè la possibilità di definire, una volta per tutte attraverso lo script, una serie di operazioni particolarmente simili o caratterizzabili in maniera sofisticata. In tal modo, la scrittura di uno script libera infatti l'autore, nell'ordine, dalla noia della ripetività o dalla necessità di ricordare certi dettagli, lasciandogli il semplice onere di eseguirlo.

Sebbene molti interpreti dei linguaggi di shell siano dotati di interfaccia a riga di comando, come le varie shell dei sistemi Unix-like (p.es. Bash, C shell, Zsh, Debian Almquist), o di quelli Windows (PowerShell, cmd.exe o command.com), diversi altri linguaggi, come AppleScript o Windows Script Host (WScript.exe), ne sono invece sprovvisti. Altri notevoli esempi di linguaggi di shell destinati principalmente alla scrittura di script sono il DCL (Digital Command Language) dei sistemi DEC o il JCL (Job Control Language) dei sistemi IBM.

Vantaggi e svantaggi

Spesso, scrivere uno script di shell è molto più veloce che scrivere il codice equivalente in altri linguaggi di programmazione. I molti vantaggi includono programma facile o selezione dei file, avvio rapido, e il debugging interattivo. Uno script di shell può essere usato per fornire una sequenza e il collegamento con il processo decisionale attorno ai programmi esistenti, e per gli script moderatamente grandi l'assenza di un passaggio di compilazione è un vantaggio. L'esecuzione interpretativa rende facile scrivere il codice di debug in uno script ed inoltre eseguire di nuovo rilevando e correggendo i bug. Gli utenti non esperti possono utilizzare script per personalizzare il comportamento dei programmi e script di shell forniscono alcune limitate possibilità di multiprocessing.

D'altra parte, lo scripting di shell è soggetto a errori costosi. Errori di battitura involontaria come rm -rf * /(invece del previsto rm -rf */ ) sono folklore nella comunità Unix, un unico spazio extra converte il comando da uno che cancella tutta la sotto-directory ad uno che cancella tutto e cerca anche di eliminare tutta la partizione di root. Problemi analoghi possono trasformare cp e mv in armi pericolose, e l'abuso del > può eliminare il contenuto di un file. Ciò è reso più problematico dal fatto che molti comandi Unix differiscono per nome da una sola lettera: cp, cn, cd.

Un altro svantaggio significativo è la velocità di esecuzione lenta e la necessità di avviare un nuovo processo per quasi tutti i comandi di shell eseguiti. Quando lo script è un lavoro può essere realizzato creando una pipeline in cui un efficiente filtro di comandi esegue la maggior parte del lavoro, attenuando il rallentamento; ma uno script complesso è in genere diversi ordini di grandezza più lento di un programma convenzionale compilato che compie un'operazione equivalente. Ci sono anche problemi di compatibilità tra piattaforme diverse. Larry Wall, creatore del Perl, come è noto ha scritto che "È più facile il porting di una shell rispetto a uno script di shell".

Allo stesso modo, script più complessi possono essere eseguiti in dei limiti del linguaggio di scripting di shell stessa; Questi limiti rendono difficile la scrittura di codice di qualità a causa delle estensioni di varie shell. Infatti se si pensasse di risolvere i problemi di shell con l'originale linguaggio di shell si potrebbero venire a creare inaspettati problemi peggiori.

Molti svantaggi di usare alcuni linguaggi di script sono causati da difetti di progettazione all'interno della sintassi del linguaggio o di attuazione, e non sono necessariamente imposti dall'utilizzo di una base della riga di comando di testo, ci sono un certo numero di shell che utilizzano altri linguaggi di programmazione della shell o anche veri e propri linguaggi di tipo Scsh (che utilizza Scheme).

Funzionalità

Tasti di scelta rapida

Nella loro forma più semplice, uno script di shell è in grado di fornire una variazione conveniente di un comando di sistema in cui le particolari impostazioni di ambiente, le opzioni di comando, o di post-processing vengono applicate automaticamente, ma in un modo che permette al nuovo script di agire ancora come un normalissimo comando Unix.

Un esempio potrebbe essere quello di creare una nuova versione di ls, il comando per elencare i file (dandogli un nome di comando più breve di l), i quali normalmente vengono salvati in una directory bin dell'utente come ad esempio:/ home / nomeutente / bin / l, e un insieme pre-fornito e predefinito di opzioni di comando.

   #!/bin/sh
   LC_COLLATE=C ls -FCas "$@"

Qui, la prima linea (Shebang) indica quale interprete deve essere usato per eseguire il resto dello script, la seconda riga fa una lista con le opzioni per gli indicatori di formato di file, colonne, tutti i file (nessuno omesso) e la dimensione in blocchi. LC_COLLATE=C imposta in modo predefinito l'ordine delle regole di confronto tra lettere maiuscole e minuscole, e "$@" che provoca eventuali parametri dati a l vengano passati come parametri di ls, in modo che tutte le normali opzioni e la sintassi nota a ls possa essere ancora utilizzata.

L'utente deve quindi essere in grado di usare semplicemente l per le liste più brevi comunemente utilizzate.

Batch jobs

Gli script di shell permettono numerosi comandi i quali devono essere inseriti manualmente in una interfaccia a riga di comando da eseguire automaticamente, e senza che l'utente debba attendere per attivare ogni fase della sequenza. Ad esempio, in una directory con tre file di codice sorgente C, invece dell'esecuzione manuale dei quattro comandi necessari per costruire il programma definitivo, si potrebbe creare invece una C shell script, denominata costruita e conservata nella directory assieme a questi ultimi, la quale li compila in modo automatico:

#!/bin/csh
echo compiling...
cc -c foo.c
cc -c bar.c
cc -c qux.c
cc -o myprog foo.o bar.o qux.o 
echo done.

Lo script dovrebbe consentire a un utente di salvare il file in corso di modifica, mettere in pausa l'editor, eseguirlo attraverso il comando . / build per creare il programma aggiornato, testarlo, e poi tornare all'editor. Dal 1980, comunque, gli script di questo tipo sono stati sostituiti con i programmi di utilità come make, che sono specializzati per programmi di "costruzione". Quando digitiamo un comando (che chiameremo job per distinguerlo dai processi) e premiamo il tasto "invio", questi viene eseguito ma, come abbiamo pilotato l'input e l'output, possiamo controllarne anche l'esecuzione. Alcuni comandi sono complessi e se avviati, impedirebbero l'uso della shell fino al loro completamento. È possibile quindi avviare il comando in background ed avere nuovamente la shell libera per altri utilizzi; si può richiamare il comando in foreground oppure sospenderlo o annullarlo. Per eseguire il comando in background è sufficiente inserire alla fine dello stesso il carattere “&”. Se volessimo stampare il file prova.txt in background basterebbe dare il comando lpr prova.txt &. Il sistema operativo assegna un numero univoco al job e lo avvia contrassegnandolo con un segno “+” (job attivo).

Nel caso avviassimo un nuovo comando, a quest'ultimo verrebbe assegnato il numero successivo e marcato con il segno “-” (in attesa di esecuzione). Per vedere quali e quanti jobs sono in esecuzione, basterà dare il comando jobs ottenendo il relativo output. È possibile quindi permettere al comando di tornare in foreground utilizzando il comando fg seguito dal carattere “%” e dal numero del job. Se per esempio si volesse portare in foreground il secondo comando in coda, si digiterà fg %2. Il comando non potrà tornare in background fino alla sua conclusione. È possibile comunque aggirare questa limitazione sospendendo il job con la combinazione di tasti “CTRL Z” e riavviandolo tramite fg o bg. Un comando terminato non avviserà l'utente della conclusione del proprio lavoro se non esplicitamente indicato tramite notify %1 (in questo caso avvisa della terminazione del primo comando). È possibile infine procedere alla terminazione forzata del comando nel caso, ad esempio, entri in un ciclo infinito. Linux mette a disposizione il comando kill seguito dal numero che identifica il job (es. %1).

Generalizzazione

Processi batch semplici non sono insoliti per le attività isolate, ma l'uso di cicli di shell, test, e delle variabili offre molta più flessibilità agli utenti. Una bash (shell Bourne-Again script) converte le immagini JPEG in PNG, fornendo i nomi di immagine sulla riga di comando - eventualmente attraverso caratteri jolly - invece di essere elencati all'interno dello script, dove è possibile creare questo file, in genere salvato come /home /nomeutente/bin/jpg2png

#!/bin/bash
for jpg in "$@" ; do                                # use $jpg in place of each filename given, in turn
    png="${jpg%.jpg}.png"                           # find the PNG version of the filename by replacing .jpg with .png
    echo converting "$jpg" ...                      # output status info to the user running the script
    if convert "$jpg" jpg.to.png ; then             # use the convert program (common in Linux) to create the PNG in a temp file
        mv jpg.to.png "$png"                        # if it worked, rename the temporary PNG image to the correct name
    else                                            # ...otherwise complain and exit from the script
        echo 'error: failed output saved in "jpg.to.png".' 1>&2
        exit 1
    fi                                              # the end of the "if" test construct
done                                                # the end of the "for" loop
echo all conversions successful                     # tell the user the good news

Il jpg2png comando può quindi essere eseguito su una intera directory piena di immagini JPEG con appena jpg2png *.jpg

Verisimilitudine

Una caratteristica fondamentale di script di shell è che l'invocazione dei loro interpreti è gestita come una caratteristica del sistema operativo di base. Così la shell d'utente piuttosto di essere solo in grado di eseguire script in linguaggio shell, o uno script avendo solamente la direttiva d'interprete gestita correttamente se è stato eseguito da una shell, (entrambi dei quali sono stati limitazioni nei primi anni di gestione della shell Bourne-Again script), la script di shell è inizializzata ed eseguita dal sistema operativo stesso. Uno script di shell moderno non può essere posto sullo stesso piano dei comandi di sistema, ma molti comandi di sistema sono in realtà degli script di shell (o più in generale, degli script, dato che alcuni di essi non sono interpretati da una shell, ma invece da linguaggi di scripting quali: Perl, Python, o altri linguaggi). Ciò vale anche per i codici di uscita ritorno come altre utilità di sistema per indicare il successo o il fallimento, permettendo così di identificarli come componenti di grandi programmi indipendentemente da come questi strumenti più grandi sono implementati.

Come i comandi standard del sistema, gli script di shell classicamente omettono qualsiasi tipo di estensione del file a meno che non siano destinati ad essere letti in una shell in esecuzione attraverso un meccanismo speciale dedita a questo scopo (ad esempio: sh's ".", or csh's source).

Programmazione

Molte shell moderne forniscono anche varie funzioni normalmente disponibili solo nell'uso di linguaggi di programmazione generale più sofisticati, come il controllo del flusso di costrutti, le variabili, i commenti, le matrici, subroutine, e così via. Con questo tipo di funzioni disponibili, è possibile scrivere applicazioni ragionevolmente sofisticate come script di shell. Tuttavia, sono ancora limitati dal fatto che la maggior parte dei linguaggi di shell hanno poco o nessun sostegno per la tipizzazione dei dati dei sistemi, le classi, filettatura, matematica complessa, e di altre funzionalità complete del linguaggio comune, e sono generalmente più lento rispetto al codice compilato o linguaggi interpretati scritti con la velocità come un obiettivo di performance.

Altri linguaggi di programmazione

Molti potenti linguaggi di scripting sono stati introdotti per compiti che sono troppo grandi o complessi per essere comodamente gestiti con gli script di shell ordinaria, ma per i quali i vantaggi di uno script sono auspicabili e il vero sovraccarico dello sviluppo, compilando il linguaggio di programmazione sarà svantaggioso. Le specifiche di ciò che separa i linguaggi di scripting dai linguaggi di programmazione ad alto livello è frequente fonte di dibattito. Ma in generale un linguaggio di scripting è quella che richiede un interprete

Potrebbe sembrare di essere di fronte a un'affermazione speculativa, in quanto spesso vi sono tante ragioni citate: "Tuttavia, il centro script di manutenzione del sistema, il quale in alternativa potrebbe essere scritto in un linguaggio, continua ad essere scritto come script della shell, in quanto non è sempre possibile contare sulla presenza del pertinenti motori linguaggio di scripting.

Con un linguaggio di scripting si può:

incollare tra loro codici preesistenti
processare files di testo molto grandi
manipolare files e directory
usufruire di operatori specializzati di alto livello
creare applicativi di non grandi dimensioni e con un breve ciclo di sviluppo
creare applicativi con una GUI integrata
avere portabilità su piattaforme Unix, Windows e Macintosh
avere un codice interpretato (assenza di compilazione/linking)

Esempi di linguaggi di scripting:

Bash
AppleScript
Batch (Linguaggio di scripting usato da MS-DOS)
ActionScript
JavaScript (Linguaggio di scripting, utilizzabile da C++)
Lua (Linguaggio di scripting, utilizzabile da C++)
Perl
Python (Linguaggio di scripting, utilizzabile da C++)
PHP (Linguaggio di scripting, utilizzabile da C++)
VBScript
Tcl (Linguaggio di scripting, utilizzabile da C++)

Ciclo di vita

Gli script di shell spesso servono come fase iniziale nello sviluppo di software, e sono spesso oggetto di conversione in seguito a una diversa implementazione sottostante, più comunemente convertita in Perl, Python, o C. La direttiva d'interprete permette alla dettagliata implementazione di essere completamente nascosta all'interno dello script, invece di essere esposta come un'estensione del file, e prevede reimplementazione senza soluzione di continuità in diverse lingue, senza alcun impatto sugli utenti finali.