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