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

Finora stiamo facendo tutti i nostri script con Bash, ma sto iniziando a sentirmi un po 'sciocco. Mentre possiamo ovviamente fare tutto ciò che vogliamo con Bash (è piuttosto potente), sto iniziando a chiedermi se non dovremmo usare un linguaggio di scripting appropriato (nel nostro caso molto probabilmente Ruby).

Come decidi quando usare Perl / Python / Ruby over Bash per uno script? Non penso che uno script di init con Ruby abbia senso, ma che ne dici di uno script leggermente più lungo che aggiunge account di posta elettronica?

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

Bash è un linguaggio di scripting per uso generico, proprio come Python, Ruby, Perl, ma ognuno ha punti di forza diversi rispetto agli altri. Perl eccelleva nell'analisi del testo, Python afferma di essere il più elegante del gruppo, gli script di Bash sono eccellenti in "roba da piping in giro", se sai cosa intendo, e Ruby ... beh, Ruby è un po 'speciale in un sacco di modi.

Tuttavia, le differenze tra loro contano davvero solo quando hai una buona quantità di esperienza di scripting sotto la cintura. Ti suggerisco di scegliere una lingua e spingerla fino ai suoi limiti prima di passare alla successiva. Puoi fare molto in uno script di shell, più di quanto la maggior parte delle persone ammetterebbe. Ogni lingua è difficile quanto vuoi. Dopo aver scritto un paio di cose in esso, ogni lingua è "facile" per te.

Avere familiarità con la shell paga 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 dello script di shell è molto semplice. Il vero potere di esso risiede in altri programmi, come awk, sed, tr, et al.

TL; DR - usa bash solo per installare un linguaggio migliore (se non è già disponibile), altrimenti stai sprecando un tempo umano prezioso e irrecuperabile. Se non riesci a farlo manualmente sulla riga di comando senza errori, non eseguire script con bash / shell.

È il 2015, quindi considererei quanto segue:

1. memoria in testa

   • L'overhead della memoria di runtime di Ruby / Python rispetto a bash è minuscolo (a causa delle librerie condivise), mentre probabilmente non è possibile mantenere uno script bash non banale (cioè uno con & gt; 100 linee) - quindi l'utilizzo della memoria non è un fattore

2. tempo di avvio

   • L'avvio di Ruby / Python potrebbe essere un po 'più lento, ma è probabile che non si eseguiranno molti processi completi di Ruby / Python in un ciclo limitato 100 volte al secondo (se si hanno quei tipi di necessità, bash / shell è troppo sovraccarico comunque e probabilmente sarà necessario passare a C / C ++)

3. prestazione

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

4. produttività

   • è troppo facile fare errori in Bash / shell rispetto all'uso di metodi, parametri, variabili ed eccezioni "reali" in Ruby / Python
   • Agile è mainstream, mentre Bash non ha alcun supporto (mancanza di funzionalità di test delle unità, librerie, OO, modularità, linting, introspezione, registrazione, metaprograming, quasi impossibile refactoring senza rompere qualcosa)
   • Troppe incompatibilità con altre shell, le variabili di ambiente minori possono completamente rompere uno script (e alcuni strumenti di dev-ops importanti come Puppet ignorano le linee di shebang e passano o riscrivono importanti variabili di shell), mentre Ruby / Python hanno una migrazione relativamente liscia ben definita percorsi anche per modifiche di versione importanti
   • l'apprendimento di una nuova lingua richiede una frazione del tempo, alternativamente, speso per il debug degli script di shell a causa di problemi specifici della shell (in particolare: nomi di variabili, nessun booleano, nessuna eccezione, ecc.)
   • anche gli script di avvio sono una mina ( particolarmente perché possono fallire durante sistema all'avvio), e dato i recenti difetti di sicurezza con bash, potrebbe essere meglio usare semplicemente 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 il controllo delle versioni , quindi imballando comunque.
   • tutto ciò che è disponibile con sed / awk / grep è probabilmente già incorporato in Ruby / Python - senza che si tratti di una dipendenza, o di "differenze" tra le versioni di tali strumenti su piattaforme (quindi cosa succede se funziona su il tuo impostare)
5. sicurezza sul lavoro
   • qual è il punto di garantire un lavoro che non ti piace? (a meno che non ti piaccia spendere tutte quelle ore difficili da debug ma bug da script shell-to-make)

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

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

E ogni volta che scrivi uno script di shell, stai "facendo pratica" facendo 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 rompere. Una sceneggiatura raramente è "finita per sempre" dopo i primi minuti - non importa quanto fortemente le persone tendano a pensare in questo modo. Insieme con l'errore "è l'ultimo bug in questo script".

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

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 nei file. Scrivo raramente codice bash che esamina effettivamente il contenuto di un file o genera l'output da scrivere in un file; Lascio questo agli altri programmi (che posso scrivere in Perl o python) che lancio tramite bash.

Io uso Perl e python quando il mio obiettivo principale è la lettura dei dati da file, l'elaborazione di tali dati in qualche modo e la scrittura di output su file. Se mi trovo a usare (in Perl) il system comando, spunta indietro o (in python) il subprocess modulo troppo estensivamente, considero la scrittura dello script in bash. D'altra parte, a volte inizio ad aggiungere tanta funzionalità a uno script bash che alla fine ha più senso riscriverlo in Perl / python piuttosto che gestire il limitato supporto (per confronto) di bash per scope, funzioni, strutture dati, ecc. Variabili .

Mi piacciono i criteri stabiliti in questo post del blog .

• Se non ci sono argomenti da passare, è probabilmente uno script di shell.
• Se non c'è molto per la logica di controllo (oltre a un singolo ciclo o se / else) è probabilmente uno script di shell.
• Se l'attività è l'automazione delle istruzioni della riga di comando, è quasi sicuramente uno script di shell.

Ho trovato utile questa analisi di Perl versus Bash ...

http://blogs.perl.org/users/buddy_burden/2012/04/perl-vs-shell-scripts.html

Per comodità, sto copiando un riassunto di quello dell'autore 1) quando bash è risultati migliori e 2) quando perl è una conclusione migliore ...

Quando Bash è migliore ...

• Job Failure
• Comandi in uscita
• Elaborazione delle righe di output del lavoro
• Qui documenti
• File equivalenze
• Confronto di timestamp di file
• Espansione Tilde

Quando Perl è migliore ...

Perl ancora batte la merda di bash per la maggior parte delle applicazioni. Le ragioni per le quali potrei preferire Perl includono (ma non sono limitate a):

• Sarà più veloce. Soprattutto perché in realtà non devo avviare nuovi processi per molte delle cose che voglio fare (basename e dirname sono gli esempi più ovvi, ma generalmente anche cut, grep, sort e wc possono essere eliminati).
• La gestione delle stringhe in bash è al massimo rudimentale, e l'intera cosa di $ IFS è super-goffa.
• Le condizioni negli script di shell possono essere fastidiose.
• Citando negli script di shell può essere un incubo.
• la dichiarazione del caso di bash lascia molto a desiderare oltre i casi semplici (NPI).
• Arrays in bash succhiare. Gli hash in bash (supponendo che il tuo bash sia abbastanza nuovo da averli) succhiano ancora più forte.
• Una volta che l'elaborazione dei file o l'output del comando va oltre il semplice caso che ho elencato sopra, Perl inizia a fumare davvero bash.
• CPAN.

Quindi non è che bash prenderà il posto di Perl in qualunque momento presto. Ma trovo ancora, dopo tutti questi anni, che molte volte uno script di shell semplice a volte può essere più semplice di un semplice script Perl. Come ho detto, accolgo con favore tutti i tentativi di convincermi del contrario. Ma, ancora una volta, non c'è niente di sbagliato nell'avere alcuni strumenti diversi nella tua casella degli strumenti.

Nella mia esperienza bash versus python è un compromesso tra tempo di sviluppo e flessibilità. Solitamente una soluzione rudimentale a un problema può essere stabilita in uno script bash più rapidamente di quanto non possa essere in uno script python.

Python tenderà a farti riflettere più sulla struttura della tua soluzione che sull'equivalente script bash. Python ha più potere espressivo di uno script bash e quindi tende a scalare e modificare meglio nel tempo. Resta anche più leggibile in generale.

Bash è più vicino al file system e può essere ottimo per le prime bozze di soluzioni a problemi che NON sono ben definiti. Per questo motivo, uno script bash potrebbe essere una buona prima scelta per prototipare qualcosa con la piena intenzione di portarlo su python una volta che il problema è stato compreso meglio.

Bash è una shell Unix che include un linguaggio di scripting. È piuttosto un processore di comandi. tu controlli il modo in cui esegui i comandi, in realtà li esegui.

Perl / Ruby / Python sono lingue di uso generale.

Quando vuoi uno script di shell, usi Bash

Se vuoi un'attività più complessa o non correlata alla shell. Usa Python ecc.

Non paragonerei mai queste lingue in realtà. Python ecc. Sono portatili. Puoi eseguirli ovunque. Bash è solo per Unix.

Python ecc. Ha tonnellate di librerie riutilizzabili che risolvono milioni di compiti.

È quasi la stessa cosa se lo chiedi. "Quando usare Paint e quando usare Photoshop"

Per elaborare le e-mail vorrei usare di nuovo Ruby, perché ha un sacco di librerie riutilizzabili.

Ma il modo migliore sarebbe combinare bash e rubino. Quello sarebbe giusto Come se si creasse uno script di elaborazione della posta elettronica in ruby ​​e lo script bash invocherebbe quello script ruby ​​ed eseguirà altre comunicazioni ds.

Quindi ogni volta che hai bisogno di un processore di comandi, usi bash. Esegui comandi unix e li controlli.

Gli script di shell come bash, ksh, zsh, sh e fish sono notoriamente sorprendenti, rispetto ai linguaggi di alto livello di uso generale come Ruby, Python o Perl. Mentre uno script di shell può iniziare la sua vita come un file più breve rispetto allo script equivalente per scopi generali, le sorprese portano a un sacco di codice di wrapping difensivo, come set -euo pipefail abilitare le modalità rigorose.

Ad esempio, la maggior parte dei linguaggi di shell continua a eseguire linee in uno script di shell, anche quando uno dei comandi fallisce. Al contrario, un linguaggio generico non riesce immediatamente al primo errore, e spesso a livello di carico, risultando in un comportamento più sicuro e più prevedibile negli script di complessità anche leggera.

Dal "Libro di lama"

• Randal L. Schwartz, Tom Phoenix, e brian d foy, Imparare il Perl (Sebastopol, CA: O'Reilly, 2011), ch. 1.2 "Perl cosa significa Perl?" , §§ "Perché Larry [il creatore di Perl] non ha usato solo un'altra lingua?", P. 5:

Perl cerca di colmare il divario tra la programmazione di basso livello (come in C o C ++ o assembly) e la programmazione di alto livello (come la programmazione "shell" [ad es. bash ]). La programmazione di basso livello è solitamente difficile da scrivere e brutta, ma veloce e illimitata; è difficile battere la velocità di un programma di basso livello ben scritto su una determinata macchina. E non c'è molto che non puoi fare lì. La programmazione di alto livello, all'estremo opposto, tende ad essere lenta, dura, brutta e limitata; ci sono molte cose che non puoi fare affatto con la shell o la programmazione batch se non c'è alcun comando sul tuo sistema che fornisce la funzionalità necessaria. Perl è facile, quasi illimitato, per lo più veloce e un po 'brutto.

Articolo molto prevenuto.

Non credo che bash sia così difficile da debugare. Python è spesso troppo rigido, mentre bash ti permette di essere molto creativo. Se sei un buon pensatore fuori dal comune, ti piacerà bash.

Eseguo script di bash su milioni di letture di sequenziamento del DNA in migliaia di file, e mi serve perfettamente. E contrariamente a quanto dicono tutti, le stesse versioni degli script in C ++ non vengono eseguite molto più velocemente (in pochi minuti separarle).

Penso che bash, come perl, non sia il più facile da usare / facile da leggere. Ciò spaventa le persone perché la maggior parte delle persone non sono grandi pensatori astratti. Ma i programmatori più brillanti e creativi tendono ad amarlo e ad usarlo frequentemente. Se conosci te stesso e sai di avere un cervello, non essere spaventato da bash. Se sei un pensatore di base, forse attenersi a qualcosa come Python. A ognuno il suo.