Script: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica
m refuso
Riga 23:
D'altra parte, lo scripting di shell è soggetto a errori costosi. Errori di battitura involontaria come <code>[[rm (Unix)|rm]] -rf * /</code>(invece del previsto <code>rm -rf * /</code> ) 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 <code>[[cp (Unix)|cp]]</code> e <code>[[mv (Unix)|mv]]</code> in armi pericolose, e l'abuso del <code>></code> può eliminare il contenuto di un file. Ciò è reso più problematico dal fatto che molti comandi Unix differiscono per nome da una sola lettera: <code>cp</code>, <code>cn</code>, <code>[[cd (Unix)|cd]]</code>.
 
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ù lentalento 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.