¿Por qué no debería “apostar el futuro de la empresa” en scripts de shell?[cerrado]

Question

yo estaba mirando http://tldp.org/LDP/abs/html/why-shell.html y fue golpeado por:

Cuándo no utilizar scripts de shell

...

• Aplicaciones de misión crítica por las que se apuesta el futuro de la empresa

¿Por qué no?

Answer 1

Usar scripts de shell está bien cuando se aprovechan sus puntos fuertes.Mi empresa tiene algunos conmutadores de software de clase 5 y el código de procesamiento de llamadas y la interfaz de aprovisionamiento están escritos en Java.Todo lo demás está escrito en KSH: volcados de bases de datos para copias de seguridad, poda, rotación de archivos de registro y todos los informes automatizados.Yo diría que todas esas funciones de soporte, aunque no están directamente relacionadas con la ruta de llamada, son de misión crítica.Especialmente la interacción DB.Si algo saliera mal con el código de interacción con la base de datos y se desecharan las tablas de enrutamiento de llamadas, podría dejarnos sin negocio.

Pero nunca nada sale mal, porque los scripts de shell son el lenguaje perfecto para cosas como esta.Son pequeños, se entienden bien, manipular archivos es su fuerte y son estables.No es que KSH09 vaya a ser una reescritura completa porque alguien piensa que debería compilarse en código de bytes, por lo que es una interfaz estable.Francamente, la interfaz de aprovisionamiento escrita en Java falla con bastante frecuencia y los scripts de shell nunca se han estropeado, que yo recuerde.

Answer 2

Creo que el artículo señala una lista realmente buena de las razones por las que no se deben usar scripts de shell: con la única viñeta de misión crítica, usted señala que es más una conclusión basada en todas las demás viñetas.

Dicho esto, creo que la razón por la que no desea crear una aplicación de misión crítica en un script de shell es porque incluso si ninguno de los otros puntos se aplica hoy, cualquier aplicación que se vaya a mantener durante un período de tiempo evolucionar hasta el punto de ser mordido por al menos uno de esos peligros potenciales en algún momento... y no hay nada que realmente puedas hacer al respecto sin que sea una repetición completa. con una solución... deseando haber usado algo más industrial desde el principio.

Answer 3

Obviamente, esto es como un hombre de paja para derribar.Realmente estoy interesado en saber por qué la gente cree que los scripts de shell deben evitarse en "aplicaciones de misión crítica", pero no se me ocurre una razón convincente.

Por ejemplo, he visto (y escrito) algunos scripts ksh que interactúan con una base de datos Oracle usando SQL*Plus.Lamentablemente, el sistema no pudo escalar adecuadamente porque las consultas no usaban variables de vinculación.Golpea uno contra scripts de shell, ¿verdad?Equivocado.El problema no estaba en los scripts de shell sino en SQL*Plus.de hecho, el problema de rendimiento desapareció cuando reemplacé SQL*Plus con un script Perl que se conectaba a la base de datos y usaba variables de vinculación.

Puedo imaginar fácilmente que poner scripts de shell en el software de vuelo de una nave espacial sería una mala idea.Pero Java o C++ pueden ser opciones igualmente malas.La mejor opción sería cualquier lenguaje (¿ensamblado?) que se utilice habitualmente para ese fin.

El hecho es que, si utiliza cualquier versión de Unix, está utilizando scripts de shell en situaciones de misión crítica, asumiendo que cree que arrancar es de misión crítica.Cuando un script necesita hacer algo en lo que Shell no es particularmente bueno, coloca esa parte en un subprograma.No desechas el guión por completo.

Answer 4

Los scripts no son ni más ni menos que programas de ordenador.Algunos dirían que los guiones son menos sofisticados.Estas mismas personas generalmente admitirán que se puede escribir código sofisticado en lenguajes de scripting, pero que estos scripts ya no son scripts, sino programas completos, por definición.

Lo que sea.

La respuesta correcta, en mi opinión, es "depende".Lo cual, por cierto, es la misma respuesta a la pregunta inversa de si debe confiar en ejecutables compilados para aplicaciones de misión crítica.

Un buen código es bueno y un mal código es malo, ya sea que esté escrito como un script Bash, un archivo CMD de Windows, en Python, Ruby, Perl, Basic, Forth, Ada, Pascal, Common Lisp, Cobol o C compilado.

Cual es no decir que la elección del idioma no importa. A veces hay muy buenas razones para elegir un idioma en particular o para compilar vs.interpretación (rendimiento, escalabilidad, capacidad, seguridad, etc.).Pero, en igualdad de condiciones, confiaría en un script de shell escrito por un gran programador en lugar de un programa C++ equivalente escrito por un tonto cualquier día de la semana.

Answer 5

Probablemente sean los scripts de shell los que ayudan a que una empresa en el futuro.Sólo desde el punto de vista de la programación sé que perdería mucho tiempo haciendo tareas repetitivas que he delegado a scripts de shell.Por ejemplo, conozco la mayoría de los comandos de subversión para la línea de comando, pero si puedo agrupar todos esos comandos en un script que puedo ejecutar a voluntad, ahorro tiempo y energía mental.

Como algunas otras personas han dicho, el idioma es un factor.Para mis pasos breves que no quiero recordar y programas de pegamento, confío completamente en mis scripts de shell y confío en ellos.Eso no significa que voy a crear un sitio web que ejecute bash en el backend, pero seguramente usaré bash/ksh/python/lo que sea para ayudarme a generar el proyecto esqueleto y administrar mi empaquetado e implementación.

Answer 6

Cuando leo esta cita me concentro en "aplicaciones" en lugar de la parte de "misión crítica".

Lo leí como si dijera que bash no es para escribir aplicaciones, sino para, bueno, secuencias de comandos.Así que seguro, es posible que tu aplicación tenga algunos scripts de mantenimiento, pero no escribas critical-business-logic.sh porque probablemente otro idioma sea mejor para cosas como esa.

Answer 7

Apostaría a que el autor está demostrando que se siente incómodo con ciertos aspectos de las secuencias de comandos de shell wrt de calidad.Quién prueba los scripts BASH, por ejemplo.

Además, los scripts están bastante acoplados con el sistema operativo subyacente, lo que podría ser algo negativo.

Answer 8

No importa, todos necesitamos una herramienta flexible para interactuar con el sistema operativo.Es una interacción legible por humanos con el sistema operativo que utilizamos, es como usar un destornillador con los tornillos.La línea de comandos siempre será una herramienta que necesitamos ya sea administrador, programador o red.Mire la ventana, incluso ampliaron su PowerShell.

Answer 9

Los scripts no son apropiados para implementar ciertas funciones de misión crítica, ya que deben tener permisos +r y +x para funcionar.Los ejecutables sólo necesitan tener +x.

El hecho de que un script tenga +r significa que los usuarios podrían hacer una copia del script, editarlo/subvertirlo y ejecutar su versión editada de Cuckoo's-Egg.