Il linguaggio di scripting più universale per Linux è?


24

Stiamo scrivendo script per sistemi Linux, c'è stato qualche dibattito su quale sarebbe il linguaggio di scripting presente più universalmente Linux da usare. Bash, SH, Posix? Che cosa?


3
Immagino sh.
Blender,

Hai un elenco di distro target? O distro obbligatori / desiderabili su cui deve funzionare?

4
"sh"? Quale "sh"? La conchiglia Thomson? la conchiglia di Bourne? bash, ksh, pdksh, ash, zsh come si trova /bin/shsul sistema X o Y ? La specifica sh POSIX, La specifica sh SUSv3, SUSv4, la specifica sh LSB? "sh" da solo non significa nulla.
Stéphane Chazelas,

1
se questo è per build di software e script di installazione, potresti voler controllare Autotools, che tenta di risolvere i problemi di compilazione tra sistemi.
Lie Ryan,

1
@sch L'intersezione comune più portatile, "ovviamente". Nel caso in cui le persone che non hanno familiarità con le shell Unix vengano fuorviate dal tuo commento, le specifiche POSIX sono implementate da quasi tutte le shell contemporanee che osano andare con il nome she le non conformità shche non sono antiche e rare al giorno d'oggi (ad esempio Bourne). Si può scuotere un elenco sempre crescente di estensioni e varianti, ma se l'obiettivo è "universale" o portabilità, si dovrebbe andare nella direzione opposta. La risposta di Gilles copre i dettagli in modo più approfondito.
jw013,

Risposte:


38

Esistono due ambienti di programmazione disponibili su ogni sistema operativo simile a unix, Turing-complete e in grado di chiamare altri programmi: awk e sh , la famiglia di shell Bourne / POSIX. AWK è orientato all'elaborazione del testo (integra utility più specializzate), mentre sh è orientato all'essere un linguaggio di colla per mettere insieme i programmi. Sh è il linguaggio di scripting universale su Linux e in tutto il mondo unix.

Lo standard POSIX definisce le funzioni obbligatorie di sh stesso e delle utility associate. La maggior parte dei sistemi simil-unix è conforme a POSIX 1003.1-2004 (alias Single Unix v3, alias Open Group Base Specification numero 6); l'ultima versione di quello standard è POSIX 1003.1-2008 (aka Single Unix v4, aka Open Group Base Specification Issue 7).

Ogni sistema Linux e unix o Unix ha una shell in stile Bourne sul percorso /bin/sh, e qualsiasi sistema non antico ha una shell conforme a POSIX (salvo il bug occasionale). Ogni moderno sistema unix-like (incluso Linux) supporta shebangs , quindi esegue automaticamente gli script /bin/shse la prima riga è #!/bin/sh. Esistono sistemi POSIX in cui shsi trova in un altro posto (in genere livelli di emulazione su sistemi operativi che non penseresti essere davvero simili a Unix).

I sistemi Linux incorporati potrebbero avere un sistema BusyBox ridotto che non implementa tutte le funzionalità POSIX. BusyBox ha un gran numero di opzioni in fase di compilazione per adattarsi a sistemi di dimensioni ridotte, quindi è difficile sapere in anticipo cosa aspettarsi, è necessario personalizzare gli script per un dispositivo specifico. BusyBox è l'implementazione più comune a ingombro ridotto di utility sh e assortite; un altro che potresti incontrare è l'ambiente shell estremamente ridotto in Android (le versioni successive sono meno anemiche).

I sistemi Linux non embedded hanno quasi sempre trattini o bash come /bin/sh. Dash è una shell piccola e veloce che implementa poco più delle funzionalità POSIX. Bash è una shell più grande con più funzionalità.

I sistemi Linux non embedded hanno quasi sempre Bash installato come /bin/bash. Quindi, per la portabilità su sistemi Linux non incorporati, puoi supporre che bash sia disponibile. Tra le utili funzionalità aggiuntive di bash vi sono gli array, la capacità di gestire comodamente i file dot, la pipestatusvariabile per ottenere lo stato di ritorno di tutti i comandi in una pipeline, operatori di confronto aggiuntivi per i tempi dei file e (nelle versioni recenti) la corrispondenza delle espressioni regolari .

Una delle caratteristiche della programmazione della shell è che non stai semplicemente usando il shprogramma, stai anche usando un numero di utility . La maggior parte delle utilità di manipolazione dei file e di elaborazione del testo su Linux sono i coreutils GNU (sui sistemi embedded, di solito provengono da BusyBox).

Se hai bisogno di portabilità oltre Linux, la soluzione migliore è attenersi a POSIX. Altre varianti di unix potrebbero non avere bash installato (bash fa parte dell'installazione standard su OSX, ma un pacchetto opzionale su * BSD e la maggior parte dei sistemi commerciali). Quasi tutte le varianti unix diverse da Linux e OSX (ad es. * BSD e sistemi commerciali) hanno una versione della shell Korn , almeno pdksh . Molte delle comode estensioni di bash provengono da ksh, quindi può essere utile scrivere script che possono essere eseguiti con entrambi, ma rilevare dove si trova bash o ksh su un sistema sconosciuto può essere un po 'una seccatura.

La shell non può fare tutto. Se hai bisogno di un linguaggio più sofisticato, le due scelte più comuni sono Perl e Python (qualsiasi altra cosa è molto indietro rispetto a un linguaggio di scripting unix). Perl è il linguaggio di scripting tradizionale e pochi sistemi Linux non incorporati lo mancano, ma Python sta guadagnando terreno (potenziato in parte essendo il linguaggio di scripting consigliato per Ubuntu). Nel mondo non Linux, Perl fa parte dell'installazione di base su OSX e OpenBSD; è facoltativo ma molto comunemente installato su FreeBSD e facoltativo ma spesso installato su NetBSD.


1
"potenziato in parte da ..." Questo ed essendo quasi obbligatorio nei sistemi Fedora e RHEL.
Ignacio Vazquez-Abrams,

Principalmente d'accordo con tutto questo. Solo alcuni enfasi diverse: * alcune distro sono basate su BusyBox ma non necessariamente integrate (ne uso una, Alpine). (Certo, la risposta non dire "quasi sempre".) * BSD sono una vasta classe di Unix-like sistemi in cui non si può assumere bash per impostazione predefinita. * dash può fare quasi tutto ciò che può fare Bash, a volte richiede solo più cure. * Se hai bisogno di un linguaggio più sofisticato, sì, Perl e Python sono le scelte più comuni, ma awk è ancora più onnipresente ed è adeguato per molti scopi. Inoltre è comunemente sottovalutato. Ma è più leggero di Perl e Python.
dubiousjim,

2
Un avvertimento giusto, però: FreeBSD ha eliminato Perl dalla sua installazione predefinita qualche tempo fa. A parte questo, non conosco altre distro che non hanno Perl nella loro installazione di base.
TC1,

@ TC1 Perl è sempre stato facoltativo su NetBSD. È nel sistema di base su OpenBSD.
Gilles 'SO- smetti di essere malvagio' il

@dubiousjim Solo Linux (non incorporato o una buona approssimazione in pratica) e OSX hanno bash nella loro installazione predefinita; * BSD ha pdksh o mksh e i sistemi commerciali hanno ATT ksh.
Gilles 'SO- smetti di essere malvagio' il

11

Nell'ordine di disponibilità:

  1. sh, ma attenersi alle strutture specificate da POSIX.
  2. bash, ma non dimenticare di specificarlo esplicitamente nello shebang, altrimenti potresti ottenere un trattino.
  3. Pitone. Quasi tutti lo usano.
  4. Perl. Ma puoi scriverlo.

Dopodiché, a nessuno importa davvero perché non c'è molto che non puoi fare solo con quelli.


10
Metterei PERL prima di Python, è installato di default nella maggior parte dei sistemi Linux.
terdon

4
Perl è il n. 3. E puoi scriverlo, bonus! :)
Warren Young,

2
Sono d'accordo con @ignacio perl è # 4 e python è # 3. Il motivo è ovvio. Penso che Python sia l'evoluzione del perl.
Bagavadhar,

5
@ashwin: no, python non è un'evoluzione o perlomeno di perl. perl è una lingua di amministratore di sistema per amministratori di sistema. python è un linguaggio di programmatori per programmatori. Questa differenza è cruciale. Entrambi hanno i loro usi e mentre ci possono essere molte sovrapposizioni nei casi d'uso, per alcuni compiti il ​​perl è la scelta migliore e per altri il pitone è chiaramente superiore.
Cas

1
Ruby e PHP sono stati ispirati da Perl. Python è il risultato di un esperimento di fisica in cui hanno creato anti-Perls in un supercollider. (Non ho nulla contro Python. Aspetti positivi e negativi, aspetti positivi e negativi.)
Warren Young,

4

Di solito, direi sh.... ma dato che hai specificato Linux, dirò bash: è garantito che si trova su tutti i sistemi Linux in circolazione (beh, escludendo quelli oscuri pedanticamente piccoli che feticizzano il minimalismo :).

Se non devi preoccuparti della portabilità non linux (e se non hai bisogno di correre su piccole distro o in dispositivi Linux incorporati come i router di plastica), puoi anche usare i miglioramenti significativi che offre oltre la pianura sh. Altrimenti usa sh.

Dopo bash(e sh), il prossimo linguaggio di scripting più "universale" per Linux sarebbe un dialetto di awk- di solito mawko gawk. Se continui con il semplice awk ed eviti i gawkismi, il tuo script dovrebbe funzionare bene su quasi tutti i sistemi Linux (potrebbe mancare su piccole distro o dispositivi incorporati). La maggior parte dei sistemi Linux avrà entrambi mawke gawkdisponibili, ma su alcune distro (debian, per esempio) mawkè installato di default e devi installarlo gawkse lo desideri.

Il prossimo sarebbe perl. AFAIK, il linguaggio perl di base è installato di default su tutte le comuni distribuzioni Linux, quindi è una buona scelta. Ancora più fortunatamente, c'è poca incompatibilità di versione con le versioni di perl5 (anche se perl 5.12 o potrebbe essere stato 5.14 finalmente è riuscito a rimuovere alcune funzionalità oscure che erano state deprecate per circa 15 anni ... ampio avvertimento di non usarle) a meno che il tuo stile di programmazione non sia veramente strano e ti piaccia ignorare gli avvisi "non farlo" per oltre un decennio, i tuoi script perl funzioneranno praticamente ovunque. Il linguaggio è robusto e potente e può fare tutto quello che awke sedin grado di fare e di più. Con un piccolo sforzo può fare quelloshè tradizionalmente buono anche per (ad esempio eseguendo comandi esterni e usando / piping l'output). Anche le librerie perl standard sono piuttosto complete e coprono molto più delle semplici basi.

L'unico problema con Perl è che esiste anche un'enorme libreria di moduli CPAN per fare qualsiasi cosa tu possa pensare (e molto altro che potrebbe non succedere mai a te) - e non tutti saranno disponibili su ogni sistema con Perl . Di solito sono di altissima qualità, quindi è facile prendere l'abitudine di usarli, ma se li usi, devi assicurarti che siano installati. Molti moduli CPAN sono preconfezionati per Linux e il resto è facilmente installabile con lo strumento cpan (o dh-make-perlsu debian / ubuntu / etc per trasformare un modulo CPAN in un pacchetto .deb)

Mi piacerebbe poterlo dire in pythonseguito, ma non posso davvero. C'è molto da apprezzare su Python ma non è incluso di default su molti sistemi Linux e, francamente, la sua compatibilità di versione (sia per Python stesso che per le sue librerie presumibilmente "standard") è un caos completo. Alcune distro fanno uno sforzo eccellente per risolvere il disordine, altre no. Nessuno dei due è aiutato dal fatto che python è fondamentalmente un linguaggio scritto per programmatori dai programmatori (al contrario dei amministratori di sistema) e non sembrano pensare che il sistema su cui verrà installato il loro codice sia assolutamente importante ... il loro codice è davvero super speciale, quindi non devono preoccuparsi di cose noiose come l'integrazione nei sistemi esistenti.

(Non ho un'idea sbagliata dal mio sarcasmo qui - mi piace molto il pitone come lingua, odio il fatto che la gestione della versione e delle dipendenze sia una PITA. È come tornare indietro di oltre 20 anni all'era della caccia manuale all'oscuro bit di codice e patch per ottenere qualcosa compilato e in esecuzione sul tuo * nix proprietario)


So che questo è un vecchio post, ma il modo migliore per aggirare questo è quello di specificare quale versione nella baracca (ad esempio /usr/bin/python2, /usr/bin/python3).
Isiah Meadows,

1

Suggerirei di seguire ksh93 o anche il sapore POSIX e puoi sempre usare bash / zsh per eseguire.

E la distribuzione basata su Debian usa mawk non gawk come awk predefinito. Quindi sì, evita le aggiunte gawk poiché mawk è molto più veloce.


0

Non bash. Scrivi in ​​un punto vicino a POSIX come trattino o cenere. Sarà il più universale. Non credo che ci sia qualcos'altro che sia anche un concorrente stretto. (E questa mi sembra una domanda concreta, non un "parere" come si lamenta uno dei commentatori.)

Se hai bisogno di qualcosa di un po 'più potente di sh (ad esempio, se vuoi veri array associativi), usa awk. (Evitando le estensioni gawk. Esistono molte versioni di awk, ma c'è un core ampiamente condiviso.) Dovrebbe essere disponibile quasi allo stesso modo di sh.


1
awk-on-Linux è universalmente gawk; Non riesco a pensare a nessuna distro che abbia un'altra variante di default.
Ignacio Vazquez-Abrams,

5
Quali varianti di Linux non supportano bash?
Jonathan Leffler,

1
Certamente bashpuò essere installato ed eseguito su (quasi) qualsiasi box Linux, ma molti utenti debian installeranno solo dashe preferiranno non installarlo bash.
William Pursell,

6
@WilliamPursell Il pacchetto bash è etichettato Essential su Debian (ad esempio, devi disinstallare i cerchi per disinstallarlo, con ampi avvertimenti che questo farà il tubo del tuo sistema). Bash è praticamente universale su sistemi Linux non integrati.
Gilles 'SO- smetti di essere malvagio' il

1
@JonathanLeffler: quelli integrati al contrario possono avere solo Busybox.
Lumaca meccanica,

0

Direi che la disponibilità si classificherebbe da qualche parte in questo ordine:

  1. sh
  2. awk
  3. Perl (devo ancora vedere un * nix senza di esso, inclusi i BSD)

Anche se Python suona come un buon linguaggio, non ho usato alcun sistema operativo che lo accompagnava in un'installazione di base, anche se apparentemente Ubuntu lo fa, forse?


0

Credo che gli esperti qui abbiano già fornito ottimi suggerimenti che dovrebbero aiutarti a decidere. L'usabilità e la disponibilità delle diverse shell sono state ben descritte negli altri post.

In una nota diversa, se fossi in te, prenderei in considerazione anche l'obiettivo che voglio raggiungere con gli script. Ogni strumento ha i suoi meriti e demeriti. Quindi, anche se utilizzo ampiamente Python, non lo userò in ogni caso.

Posso pensare ad alcuni scenari e menzionare alcuni strumenti utili per loro.

File FTP avanti e indietro; elaborarli; inviare notifiche e-mail; e così via

In questo caso sarebbe meglio attenersi alla shell (ad es. Bash) e utilizzare le varie utility (ad es. ftp, cronE mail). Questo è un tipico caso d'uso in molte grandi aziende.

Elaborazione rapida del testo

Ancora una volta, il guscio. I programmi di utilità come grep, awk, sed, pastee gli altri sono molto utile in questo caso.

Costruire

Nel dominio C / C ++, lo strumento universale per questo è make. Il mondo Java preferisce Apache ANT.

Distribuzione e controllo remoto

O la shell o Python. Ad esempio, scpe rsync, rispettivamente, sarebbe abbastanza utile per copiare i file o sincronizzare i file.

Python, d'altra parte, ha un modulo molto utile chiamato fabric. Ciò sarebbe utile per operazioni più complesse, ad esempio per copiare file, interrompere alcuni processi, creare il server e similmente. Inoltre, Python fornisce anche un modulo, pipche può risolvere le dipendenze specificate scaricando e installando i relativi pacchetti.

(Si noti che i suggerimenti di cui sopra non si concentrano sul guscio dispone di molto, ma piuttosto sulle diverse utility disponibili.)


-1

Perl non è nella base di FreeBSD, NetBSD o DragonflyBSD, mi dispiace. OpenBSD ha Perl nell'installazione di base. OS X è oggigiorno un UNIX certificato e può essere pensato come una sorta di variante BSD ad un certo livello e ha Perl, Python e Ruby in base.

Molti UNIXen proprietari non hanno Perl nella loro base, ad esempio Solaris, AFAIK né HP-UX o IBM AIX ...


La tua dichiarazione su Perl mancante in Solaris non è corretta. Perl è un componente fondamentale obbligatorio di Solaris almeno dal 2005 (Solaris 10).
jlliagre,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.