Quando usare Bash e quando usare Perl/Python/Ruby?

TL;DR - usa solo bash per l'installazione di una lingua migliore (se non è già disponibile), altrimenti stai sprecando tempo umano prezioso e irrecuperabile. Se non puoi farlo a mano sulla riga di comando senza errori, non scrivere con bash/shell.

È il 2015, quindi prenderei in considerazione quanto segue:

1. sovraccarico di memoria

   • L'overhead della memoria di runtime di Ruby/Python rispetto a bash è minuscolo (a causa delle librerie condivise), mentre uno probabilmente non può comunque mantenere uno script bash non banale (cioè uno con> 100 righe) - quindi l'utilizzo della memoria non è un fattore

2. ora di avvio

   • L'avvio di Ruby/Python potrebbe essere leggermente più lento, ma è probabile che non eseguirai molti processi Ruby/Python completi in un ciclo stretto 100 volte al secondo (se hai questo tipo di esigenze, bash /shell è comunque troppo sovraccarico e probabilmente dovrai passare a C/C++)

3. prestazioni

   • quasi tutti i tipici crunch di dati saranno più veloci in Ruby/Python - o almeno comparabili (o, comunque, hai bisogno di C/C++/Haskel/OCaml/qualsiasi cosa)
   • la vera prestazione/collo di bottiglia nell'esecuzione (o anche nella produttività) non sarà quasi mai essere "una mancanza nell'uso di bash/shell" (anche Ubuntu che cambia dash per l'avvio mostra come bash sia in realtà il problema - e un busybox è probabilmente l'unico caso d'uso, perché c'è nient'altro che "bash" e "vi" per scrivere ed eseguire codice, e spesso non c'è modo di aggiungere/scaricare o archiviare nient'altro)
   • l'esecuzione di altri processi per svolgere il lavoro (come sed/awk/grep) è in realtà molto più lenta rispetto alla chiamata di un metodo su un oggetto live in memoria

4. produttività

   • è troppo facile commettere errori in Bash/shell rispetto all'utilizzo di metodi, parametri, variabili ed eccezioni "reali" in Ruby/Python
   • Agile è mainstream, mentre Bash non lo supporta (manca di capacità di unit test, librerie, OO, modularità, linting, introspezione, registrazione, metaprogrammazione; quasi impossibile eseguire il refactoring senza rompere qualcosa)
   • troppe incompatibilità con altre shell, le variabili di ambiente minori possono interrompere completamente uno script (e alcuni importanti strumenti di sviluppo come Puppet ignorano le linee shebang e trasmettono o riscrivono importanti variabili di shell), mentre Ruby/Python hanno ben definite percorsi di migrazione relativamente fluidi anche per i principali cambiamenti di versione
   • l'apprendimento di una nuova lingua richiede una frazione del tempo impiegato alternativamente per il debug degli script di shell a causa di problemi specifici della shell (in particolare nomi di variabili, nessun valore booleano, nessuna eccezione, ecc.)
   • anche gli script di avvio sono una mina (soprattutto perché possono fallire durante il sistema startup), e dati i recenti difetti di sicurezza con bash, potrebbe essere meglio usare il semplice C (con buone librerie) - sì, C ha bisogno di compilazione, configurazione, ecc., ma anche un semplice script di shell potrebbe aver bisogno di un repository, quindi versioning , quindi l'imballaggio comunque.
   • tutto ciò che è disponibile con sed/awk/grep è probabilmente già integrato in Ruby/Python, senza che sia una dipendenza o "differenze" tra le versioni di questi strumenti su piattaforme diverse (quindi cosa succede se funziona su il tuo configurazione)
5. sicurezza del lavoro
   • che senso ha assicurarsi un lavoro che non ti piace? (a meno che non ti piaccia passare tutte quelle ore difficili da correggere ma banali da creare bug di script di shell)

Trovo che non ci sia motivo di usare Bash/Shell se hai installato Ruby/Python.

E probabilmente l'installazione di Ruby/Python non ha nemmeno bisogno di uno script bash in primo luogo (con l'eccezione di busybox, alcuni strumenti di sistema dipendono comunque dalla presenza di Python/Perl).

E ogni volta che scrivi uno script di shell, ti "eserciti" a fare esattamente questo, invece di imparare qualcosa di più potente/produttivo.

Perché le persone usano Bash al giorno d'oggi? Perché è un'abitudine terribile e difficile da eliminare. Una sceneggiatura è raramente "finita per sempre" dopo i primi minuti, non importa quanto fortemente le persone tendano a pensarla in quel modo. Insieme all'errore "è l'ultimo bug in questo script".

Conclusione:usa bash/shell solo quando sei assolutamente costretto a (come ~/.bashrc , busybox), perché non è quasi mai "lo strumento giusto per il lavoro" al giorno d'oggi.

Dato un problema che entrambi possono gestire, ti consigliamo di utilizzare quello con cui ti senti più a tuo agio. In definitiva, ci sono molti piccoli dettagli e solo l'esperienza può insegnarti a vederli.

Bash è un linguaggio di scripting generico proprio come Python, Ruby, Perl, ma ognuno ha punti di forza diversi rispetto agli altri. Perl eccelle nell'analisi del testo, Python afferma di essere il più elegante del gruppo, gli script Bash sono eccellenti nel "convogliare cose in giro", se capisci cosa intendo, e Ruby ... beh, Ruby è un po 'speciale in molti di modi.

Tuttavia, le differenze tra loro contano davvero solo una volta che hai una buona esperienza di scripting alle spalle. Ti suggerisco di scegliere una lingua e spingerla al limite prima di passare alla successiva. Puoi fare molto in uno script di shell, più di quanto la maggior parte delle persone ammetterebbe. Qualsiasi lingua è tanto difficile quanto vuoi farla. Dopo che ci hai scritto un paio di cose, ogni lingua è "facile" per te.

Avere familiarità con la shell ripaga rapidamente se vivi in ​​​​Linux, quindi forse vuoi iniziare con quello. Se trovi un compito che è impossibile o poco pratico da risolvere in uno script di shell, usa qualcos'altro.

Inoltre, tieni presente che l'apprendimento degli script di shell è molto semplice. Il vero potere sta in altri programmi, come awk, sed, tr e altri.

Uso bash quando il mio obiettivo principale è la gestione dei file. Ciò potrebbe includere lo spostamento, la copia e la ridenominazione di file, nonché l'utilizzo di file come input per altri programmi o l'archiviazione dell'output di altri programmi in file. Raramente scrivo codice bash che esamina effettivamente il contenuto di un file o genera l'output da scrivere su un file; Lo lascio agli altri programmi (che posso scrivere in Perl o python) che lancio tramite bash.

Uso Perl e Python quando il mio obiettivo principale è leggere i dati dai file, elaborarli in qualche modo e scrivere l'output sui file. Se mi ritrovo ad usare (in Perl) il system comando, back tick o (in python) il subprocess module troppo ampiamente, considero la possibilità di scrivere lo script in bash. D'altra parte, a volte inizio ad aggiungere così tante funzionalità a uno script bash che alla fine ha più senso riscriverlo in Perl/python piuttosto che occuparsi del supporto limitato (al confronto) di bash per ambito variabile, funzioni, strutture dati, ecc. .