Script: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
LiveRC : Annullate le modifiche di Daniele Bignardi (discussione), riportata alla versione precedente di Elwood |
Nessun oggetto della modifica |
||
Riga 23:
D'altra parte, lo scripting di shell è soggetto a errori costosi. Errori di battitura involontaria come <tt>[[rm (Unix)|rm]] -rf * /</tt>(invece del previsto <tt>rm -rf * /</tt> ) 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 (informatica)|partizione]] di [[Root (informatica)|root]]. Problemi analoghi possono trasformare <tt>[[cp (Unix)|cp]]</tt> e <tt>[[mv (Unix)|mv]]</tt> in armi pericolose, e l'abuso del <tt>></tt> può eliminare il contenuto di un file. Ciò è reso più problematico dal fatto che molti comandi Unix differiscono per nome da una sola lettera: <tt>cp</tt>, <tt>cn</tt>, <tt>[[cd (Unix)|cd]]</tt>.
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''".
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.
Line 61 ⟶ 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 <tt>. / build</tt> 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 [[Esecuzione in background|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===
| |||