Perché non dovrei “scommettere sul futuro dell'azienda” sugli script di shell?[Chiuso]

Question

stavo guardando http://tldp.org/LDP/abs/html/why-shell.html e rimase colpito da:

Quando non utilizzare gli script di shell

...

• Applicazioni mission-critical su cui si scommette sul futuro dell'azienda

Perché no?

Answer 1

Usare gli script di shell va bene quando usi i loro punti di forza.La mia azienda dispone di alcuni soft switch di classe 5 e il codice di elaborazione delle chiamate e l'interfaccia di provisioning sono scritti in Java.Tutto il resto è scritto in KSH: dump DB per backup, potatura, rotazione dei file di registro e tutti i report automatizzati.Direi che tutte queste funzioni di supporto, sebbene non direttamente correlate al percorso della chiamata, sono cruciali per la missione.Soprattutto l'interazione DB.Se qualcosa andasse storto con il codice di interazione del DB e eliminasse le tabelle di instradamento delle chiamate, potrebbe metterci fuori gioco.

Ma niente va mai storto, perché gli script di shell sono il linguaggio perfetto per cose come queste.Sono piccoli, si capiscono bene, manipolare i file è la loro forza e sono stabili.Non è che KSH09 sarà una riscrittura completa perché qualcuno pensa che dovrebbe essere compilato in codice byte, quindi è un'interfaccia stabile.Francamente, l'interfaccia di provisioning scritta in Java va in modo instabile abbastanza spesso e gli script di shell non hanno mai fatto confusione, per quanto mi ricordi.

Answer 2

Penso che l'articolo indichi un elenco davvero valido dei motivi per cui non utilizzare gli script di shell: con il singolo punto critico per la missione che indichi è più una conclusione basata su tutti gli altri punti.

Detto questo, penso che il motivo per cui non vuoi creare un'applicazione mission-critical su uno script di shell è perché anche se non si applica nessuno degli altri punti elenco Oggi, qualsiasi applicazione che verrà mantenuta per un periodo di tempo lo farà evolvere al punto di essere morso da almeno una di quelle potenziali trappole ad un certo punto... e non c'è nulla che tu possa davvero fare al riguardo senza che si verifichi una revisione completa con una correzione....vorrei che tu usassi qualcosa di più potente industriale fin dall'inizio.

Answer 3

Ovviamente, questo è un po' un uomo di paglia per me da abbattere.Sono davvero interessato al motivo per cui le persone credono che gli script di shell dovrebbero essere evitati nelle "applicazioni mission-critical", ma non riesco a pensare a una ragione convincente.

Ad esempio, ho visto (e scritto) alcuni script ksh che interagiscono con un database Oracle utilizzando SQL*Plus.Purtroppo, il sistema non è stato in grado di ridimensionarsi correttamente perché le query non utilizzavano variabili di associazione.Colpiscine uno contro gli script di shell, giusto?Sbagliato.Il problema non riguardava gli script di shell ma SQL*Plus.infatti, il problema delle prestazioni è scomparso quando ho sostituito SQL*Plus con uno script Perl che si collegava al database e utilizzava variabili di associazione.

Posso facilmente immaginare che inserire script di shell nel software di volo del veicolo spaziale sarebbe una cattiva idea.Ma Java o C++ potrebbero essere scelte altrettanto sbagliate.La scelta migliore sarebbe qualunque linguaggio (assembly?) venga solitamente utilizzato per tale scopo.

Il fatto è che, se usi qualsiasi tipo di Unix, stai usando script di shell in situazioni mission-critical presupponendo che tu pensi che l'avvio sia mission-critical.Quando uno script deve fare qualcosa in cui la shell non è particolarmente brava, inserisci quella parte in un sottoprogramma.Non si butta via la sceneggiatura in blocco.

Answer 4

Gli script non sono né più né meno che programmi per computer.Alcuni sostengono che gli script siano meno sofisticati.Queste stesse persone di solito ammetteranno che è possibile scrivere codice sofisticato nei linguaggi di scripting, ma che questi script in realtà non sono più script, ma programmi a tutti gli effetti, per definizione.

Qualunque cosa.

La risposta corretta, secondo me, è "dipende".Che, tra l'altro, è la stessa risposta alla domanda opposta: se dovresti riporre la tua fiducia negli eseguibili compilati per applicazioni mission-critical.

Un buon codice è buono e un cattivo codice è cattivo, sia che sia scritto come script Bash, file CMD di Windows, in Python, Ruby, Perl, Basic, Forth, Ada, Pascal, Common Lisp, Cobol o C compilato.

Che è non per dire che la scelta della lingua non ha importanza. Ci sono ottime ragioni, a volte, per scegliere un linguaggio particolare o per compilare vs.interpretazione (prestazioni, scalabilità, capacità, sicurezza, ecc.).Ma, a parità di condizioni, mi fiderei di uno script di shell scritto da un grande programmatore su un programma C++ equivalente scritto da un idiota in qualsiasi giorno della settimana.

Answer 5

Probabilmente sono gli script di shell che aiutano a prendere un'azienda in il futuro.So solo dal punto di vista della programmazione che perderei molto tempo svolgendo attività ripetitive che ho delegato agli script di shell.Ad esempio, conosco la maggior parte dei comandi di sovversione per la riga di comando, ma se riesco a raggruppare tutti questi comandi in uno script posso attivarli a piacimento, risparmiando tempo ed energia mentale.

Come poche altre persone hanno detto che la lingua è un fattore.Per i miei brevi passaggi e programmi di colla che non voglio ricordare, mi fido completamente dei miei script di shell e faccio affidamento su di essi.Ciò non significa che costruirò un sito Web che esegue bash sul backend, ma utilizzerò sicuramente bash/ksh/python/qualunque cosa per aiutarmi a generare lo scheletro del progetto e gestire il pacchetto e la distribuzione.

Answer 6

Quando leggo questa citazione mi concentro sul "applicazioni" piuttosto che la parte "mission critical".

L'ho letto come se dicesse che bash non è per scrivere applicazioni, ma per, beh, scripting.Quindi certo, la tua applicazione potrebbe avere alcuni script di pulizia ma non scrivere critical-business-logic.sh perché un'altra lingua probabilmente è migliore per cose del genere.

Answer 7

Scommetto che l'autore sta dimostrando di sentirsi a disagio con alcuni aspetti dello scripting di shell di qualità.Ad esempio, chi testa gli script BASH.

Inoltre gli script sono piuttosto strettamente collegati al sistema operativo sottostante, il che potrebbe essere qualcosa di negativo.

Answer 8

Non importa, tutti abbiamo bisogno di uno strumento flessibile per interagire con il sistema operativo.È un'interazione leggibile dall'uomo con il sistema operativo che utilizziamo, è come usare un cacciavite con le viti.La riga di comando sarà sempre uno strumento di cui abbiamo bisogno come amministratore, programmatore o rete.Guarda la finestra, hanno persino espanso il loro PowerShell.

Answer 9

Gli script non sono appropriati per implementare alcune funzioni mission-critical, poiché devono avere sia i permessi +r che +x per funzionare.Gli eseguibili devono avere solo +x.

Il fatto che uno script abbia +r significa che gli utenti potrebbero essere in grado di creare una copia dello script, modificarlo/sovvertirlo ed eseguire la versione modificata di Cuckoo's-Egg.