Script: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica |
m tag obsoleti |
||
Riga 21:
Spesso, scrivere uno script di shell è molto più veloce che scrivere il [[codice sorgente|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 <
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 dati|pipeline]] in cui un efficiente [[Filtro (Unix)|filtro]] di comandi esegue la maggior parte del lavoro, attenuando il rallentamento; ma uno script complesso è in genere diversi ordini di grandezza più lenta 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''".
Riga 35:
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 (Unix)|ls]], il comando per elencare i file (dandogli un nome di comando più breve di <
<source lang="bash">
Riga 42:
</source>
Qui, [[Shabang|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. <
L'utente deve quindi essere in grado di usare semplicemente <
===Batch jobs===
Riga 60:
</source>
Lo script dovrebbe consentire a un utente di salvare il file in corso di modifica, mettere in pausa l'editor, eseguirlo attraverso il comando <
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).
Riga 66:
===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 [[Portable Network Graphics|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 <
<source lang="bash">
Riga 84:
</source>
Il jpg2png comando può quindi essere eseguito su una intera directory piena di immagini JPEG con appena <
===Verisimilitudine===
Riga 90:
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: <
===Programmazione===
| |||