Qual è il vantaggio dello script di shell rispetto ai linguaggi di programmazione interpretati? [chiuso]

13

(Non sono sicuro che sia una domanda appropriata qui)

Gli script di shell, come quelli scritti in bash , possono fare molte cose. Possono chiamare programmi Unix, reindirizzare l'output, reindirizzare I / O da / a file, controllare il flusso, controllare se esiste un file, ecc.

Ma un linguaggio di programmazione moderno, ad esempio python e ruby , può anche fare queste cose. E, sono (penso) più leggibili e mantenibili.

bash gode di un'adozione diffusa. Ma molte distribuzioni hanno installato anche% interprete% co_de.

Quindi qual è il vantaggio della shell di uno script? Se potessi scrivere python , python o ruby , vale la pena di imparare perl ?

    
posta Lai Yu-Hsuan 23.03.2012 - 18:16
fonte

8 risposte

29

Le conchiglie hanno caratteristiche specializzate per lavorare con i file e ottenere dati da un programma a un altro (supponendo che i dati siano testo). Per queste attività, gli script di shell possono essere meno ingombranti di un linguaggio di scripting come Python.

Anche lo scripting di shell ha il vantaggio che i comandi che usi sono praticamente gli stessi comandi che useresti dalla riga di comando - quindi se puoi fare qualcosa nella shell, sei più che a metà strada nello script della stessa operazione .

Qui, ad esempio, c'è uno script bash che sposta tutti i file PNG dalla directory corrente in una directory specificata.

#!/usr/bin/sh
mv *.png $1

Ecco una versione di Python.

#!/usr/bin/python
import sys, shutil, glob
for filename in glob.iglob("./*.png"):
    shutil.move(filename, sys.argv[1])

Noterai:

  • Lo script bash è un terzo del Python se contate le linee (esclusa la linea shebang) - ancor meno per il numero di caratteri
  • Lo script Python richiede l'importazione di tre librerie, mentre tutto ciò che è necessario per questa attività è disponibile nativamente in bash
  • Lo script Python richiede un ciclo esplicito per spostare i file, mentre quello è parte della semantica del comando mv in bash
  • Lo script di bash può essere eseguito più rapidamente: probabilmente lo invocerai da bash e puoi utilizzare source per eseguirlo nella stessa istanza della shell
  • glob.iglob("./*.png") è un bel boccone solo per dire *.png

Se volessi scrivere un'operazione di pipe di base in Python, verrai sbalordito dalla verbosità. (Certo, alcune cose, come il piping attraverso grep , possono essere sostituite dal codice Python piuttosto che usare un programma esterno, quindi spesso non è necessario eseguire il pipe altrettanto.)

Come controesempio, una volta dovevo scrivere una routine che verificava per quanto tempo ciascuno dei nomi di file si trovava in una particolare directory. Se erano più lunghi di quelli supportati da un particolare sistema operativo, dovevano essere abbreviati. Ciò potrebbe causare nomi di file duplicati, che dovevo correggere, e dato che sarebbero stati collegati da una pagina Web, i nomi abbreviati dovevano essere stabili, cioè, dovrebbero essere generati in modo tale che lo stesso nome file lungo avrebbe sempre come risultato lo stesso nome di file abbreviato. L'ho fatto generando un hex md5 del nome file lungo e aggiungendo i primi quattro caratteri al nome abbreviato (i nomi potrebbero ancora scontrarsi, ma è stato molto impreciso, quindi ho controllato la condizione e salvato se dovesse accadere) . Doveva anche registrare l'operazione di ridenominazione, in modo da poter eseguire in seguito una ricerca e sostituzione in lotti sui file per correggere i collegamenti tra di essi (ho scritto un file di comandi sed e l'ho passato a sed per ogni file).

L'ho fatto in bash perché faceva parte del nostro sistema di build che era già stato scritto in bash. Era esattamente difficile da ottenere, come probabilmente stai pensando. Ci sarebbe voluto molto meno tempo per scrivere in Python e probabilmente sarebbe stato anche più chiaro.

In breve: diverse lingue sono progettate per diversi tipi di compiti; scegli la lingua a tua disposizione più adatta all'attività da svolgere.

    
risposta data 23.03.2012 - 18:38
fonte
18

Anche le risposte esistenti sono valide, ma c'è una ragione che nessuno ha ancora menzionato: perché ci sarà.

Ogni installazione data * nix viene eseguita con un gruppo di pacchetti opzionali che possono o meno essere caricati, e non tutti i sistemi avranno Python o Perl o Ruby. Ma se si prevede che il sistema abbia capacità interattive, avrà una shell. Ciò significa che gli script di shell funzioneranno sui sistemi dai server ai desktop del programmatore ai desktop di segreteria thin-client ai dispositivi incorporati, su qualsiasi sistema che supporti un file system scrivibile e una riga di comando bash.

Per qualcuno che lavora sempre in un ambiente server coerente, questo è qualcosa che può essere dato per scontato, e non è così importante. Per chi lavora in un ambiente più vario, questo non deve essere trascurato.

    
risposta data 23.03.2012 - 18:52
fonte
9

Una parte significativa della tua domanda ha una risposta qui:

Why are scripting languages (e.g. Perl, Python, Ruby) not suitable as shell languages?

Ecco un estratto da la mia risposta a questa domanda :

There are a couple of differences that I can think of; just thoughtstreaming here, in no particular order:

  1. Python & Co. are designed to be good at scripting. Bash & Co. are designed to be only good at scripting, with absolutely no compromise. IOW: Python is designed to be good both at scripting and non-scripting, Bash cares only about scripting.

  2. Bash & Co. are untyped, Python & Co. are strongly typed, which means that the number 123, the string 123 and the file 123 are quite different. They are, however, not statically typed, which means they need to have different literals for those, in order to keep them apart. Example:

    • Ruby: 123 (number), Bash: 123
    • Ruby: '123' (string), Bash: 123
    • Ruby: /123/ (regexp), Bash: 123
    • Ruby: File.open('123') (file), Bash: 123
    • Ruby: IO.open('123') (file descriptor), Bash: 123
    • Ruby: URI.parse('123') (URI), Bash: 123
    • Ruby: '123' (command), Bash: 123
  3. Python & Co. are designed to scale up to 10000, 100000, maybe even 1000000 line programs, Bash & Co. are designed to scale down to 10 character programs.

  4. In Bash & Co., files, directories, file descriptors, processes are all first-class objects, in Python, only Python objects are first-class, if you want to manipulate files, directories etc., you have to wrap them in a Python object first.

  5. Shell programming is basically dataflow programming. Nobody realizes that, not even the people who write shells, but it turns out that shells are quite good at that, and general-purpose languages not so much. In the general-purpose programming world, dataflow seems to be mostly viewed as a concurrency model, not so much as a programming paradigm.

I have the feeling that trying to address these points by bolting features or DSLs onto a general-purpose programming language doesn't work. At least, I have yet to see a convincing implementation of it. There is RuSH (Ruby shell), which tries to implement a shell in Ruby, there is rush, which is an internal DSL for shell programming in Ruby, there is Hotwire, which is a Python shell, but IMO none of those come even close to competing with Bash, Zsh, fish and friends.

    
risposta data 23.03.2012 - 22:49
fonte
1

Direi che uno script di shell ha il vantaggio in situazioni in cui si desidera semplicemente creare un'attività automatizzata super-semplice. Ad esempio, se si desidera scrivere uno script che esegue il backup di una directory da un server a un altro ogni giorno alle 5:00, sarebbe eccessivo utilizzare un linguaggio di programmazione heavy duty.

D'altra parte, se l'attività di programmazione ha più bisogno di strutture di controllo (se / allora / else), strutture iterative (looping), database e amp; file I / O, ecc., quindi è probabilmente più adatto per un linguaggio di programmazione più capace di uno script di shell.

Penso che una buona regola empirica sia:

automatingSimpleTask ? shellScript() : programmingLanguage();
    
risposta data 23.03.2012 - 18:25
fonte
1

Mentre puoi lanciare programmi da un programma python / ruby / qualunque, è diverso nella shell. Potrebbe essere necessario utilizzare un'API per lanciare qualcosa, ad esempio fork (). In uno script di shell, i programmi si comportano più come funzioni in un linguaggio di programmazione convenzionale e possono essere eseguiti, convogliati, ecc. Con il minimo sforzo. Il flusso di dati è molto chiaro anche con le pipe.

    
risposta data 23.03.2012 - 18:31
fonte
0

Se sei totalmente libero di scegliere il linguaggio di programmazione che utilizzi per determinate attività, potresti probabilmente evitare quasi completamente l'apprendimento di bash e svolgere ogni attività di programmazione di script con Perl, Python o Ruby. Questo a volte può portare a una soluzione più prolissa, specialmente nel caso in cui hai solo bisogno di uno script che richiami una sequenza di altri strumenti Unix, ma nei casi più complessi hai ragione, quei linguaggi di script moderni ti offrono più possibilità di scrivere codice gestibile meglio (ti danno anche più possibilità di scrivere codice offuscato, ma questa è la tua scelta).

D'altra parte, spesso non siamo liberi di scegliere la lingua che ci piace di più, perché dobbiamo lavorare con codice legacy o codice scritto da uno che sapeva bash ma non conosceva uno dei linguaggi di scripting che hai chiamato.

    
risposta data 23.03.2012 - 18:43
fonte
0

Lo scripting della shell è un linguaggio di programmazione interpretato. Ecco alcuni motivi per cui ho scelto di scrivere script in bash anziché in Perl o Python o in altri linguaggi di scripting:

Funziona ovunque : gli interpreti più complessi potrebbero non essere sempre disponibili, ad esempio durante l'avvio del sistema o su sistemi incorporati. Bash è disponibile anche in busybox.

Funziona sulla riga di comando : se sei esperto nello scripting di shell, puoi usare queste abilità per fare cose complesse negli script ad-hoc direttamente dalla riga di comando. Io uso questa abilità quotidianamente come sysadmin.

Più facile scrivere programmi che chiamano altri programmi: Se quello che stai cercando di fare è mettere insieme diversi programmi esistenti in modi interessanti, può essere più semplice farlo in uno script di shell che con un lingua di livello superiore.

Se il programma è composto da 30 righe o meno, di solito lo scrivo usando lo script di shell. Se ci sono manipolazioni complesse o complessi o analisi da affrontare, lo farò usando python o perl.

    
risposta data 24.03.2012 - 01:52
fonte
-1

Dovresti dare un'occhiata al coffeescript. Le loro parole:

Underneath all those awkward braces and semicolons, JavaScript has always had a gorgeous object model at its heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way.

La regola d'oro di CoffeeScript è: "È solo JavaScript".

Bene ... ecco la risposta super-principiante.

Come principiante di autoapprendimento negli ultimi 6 mesi, e assaporato un po 'di C, C ++, Javascript e più Bashscript negli ultimi giorni ... Posso dirti:

Shell scripts, like those written in bash, can do many things. They can call Unix programs, pipe their output, redirect I/O from/to files, control flow, check whether a file exists, etc.

e non è così semplice fantastico! ? cicli e variabili? wow!

python and ruby, can also do these things. And, they are (I think) more readable and maintainable.

Per favore, dimmi dove lo vedi? Ho scritto bashscript in gedit anche in geany e posso formattare, (tabs?) E ho letto il mio codice alla velocità della luce usando bashscript in confronto su altri linguaggi.

Questo linguaggio ha altri strumenti per mantenere l'ordine? So che orientato agli oggetti risparmia un sacco di codice, ma ... la gente dice che bashscript è anche OO! WOW 2! Questo è il mio punto qui. Andando a:

the advantage of shell a script

è all'interno di questa domanda: come fare ciò che questo bashdamnthing può fare in perl o phyton o ruby? È facile?

( bashdamnthing = xdotool )

    
risposta data 24.03.2012 - 01:47
fonte

Leggi altre domande sui tag