estaba mirando http://tldp.org/LDP/abs/html/why-shell.html y llamó la atención:¿Por qué no debería "apostar el futuro de la compañía" en scripts de shell?
Cuando no usar secuencias de comandos shell
... aplicaciones
- de misión crítica en la que usted está apostando el futuro de la empresa
¿Por qué no?
El uso de scripts de shell está bien cuando usa 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 DB para copias de seguridad, poda, rotación de archivos de registro y todos los informes automáticos. Yo diría que todas esas funciones de soporte, aunque no están directamente relacionadas con el recorrido de la llamada, son críticas para la misión. Especialmente la interacción DB. Si algo salió mal con el código de interacción de DB y volcó las tablas de enrutamiento de llamadas, podría dejar de funcionar.
Pero nada sale mal, porque los guiones de shell son el lenguaje perfecto para cosas como esta. Son pequeños, son bien entendidos, manipular archivos es su fortaleza, y son estables. No es que KSH09 vaya a ser una reescritura completa porque alguien cree que debería compilarse a código de bytes, por lo que es una interfaz estable. Francamente, la interfaz de aprovisionamiento escrita en Java no funciona con demasiada frecuencia y los guiones del intérprete de comandos nunca se han estropeado y puedo recordarlo.
Apostaría que el autor está mostrando que no se sienten cómodos con ciertos aspectos del guión de shell de qualtiy wrt. ¿Quién prueba los scripts de BASH, por ejemplo?
También las secuencias de comandos están bastante asociadas con el sistema operativo subyacente, lo que podría ser algo negativo.
Creo que el artículo señala una muy buena lista de las razones por las cuales no usar scripts de shell, con la única viñeta de misión crítica que usted señala como una conclusión basada en todas las otras viñetas.
Dicho esto, creo que la razón por la que no quiere construir una aplicación de misión crítica en un script de shell es porque incluso si ninguno de los otros puntos de la bala se aplica hoy, cualquier aplicación que va a ser mantenido durante un período de tiempo evoluciona hasta el punto de ser mordido por al menos uno de los peligros potenciales en algún momento ..... y no hay nada que realmente pueda hacer al respecto sin que sea una tarea completa para encontrar una solución ... desearía haber usado algo más fuerte desde el principio.
Las secuencias de comandos no son más ni menos que los programas de computadora. Algunos argumentarían que los guiones son menos sofisticados. Estas mismas personas suelen admitir que puede escribir código sofisticado en los 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". Que, por cierto, es la misma respuesta a la pregunta inversa de si debe confiar en los ejecutables compilados para aplicaciones de misión crítica.
El código bueno es bueno y el código incorrecto es malo, ya sea escrito como un script Bash, un archivo CMD de Windows, en Python, Ruby, Perl, Basic, Adelante, Ada, Pascal, Common Lisp, Cobol o compilado C.
que es no para decir que la elección del idioma no importa. Existen muy buenas razones, a veces, para elegir un idioma en particular o para compilar contra la interpretación (rendimiento, escalabilidad, capacidad, seguridad, etc.). Pero, en igualdad de condiciones, confío en un guión de shell escrito por un gran programador sobre un programa equivalente de C++ escrito por un doofus cualquier día de la semana.
Obviamente, esto es un poco pesado para mí para derribar. Realmente estoy interesado en por qué las personas creen que las secuencias de comandos de shell deben evitarse en "aplicaciones de misión crítica", pero no puedo pensar en una razón de peso.
Por ejemplo, he visto (y escrito) algunos scripts ksh que interactúan con una base de datos Oracle utilizando SQL * Plus. Lamentablemente, el sistema no pudo escalar correctamente porque las consultas no usaron variables de vinculación. Ataque uno contra los guiones de shell, ¿verdad? Incorrecto. El problema no era con los scripts de shell sino con SQL * Plus. de hecho, el problema de rendimiento desapareció cuando reemplacé SQL * Plus con un script Perl que se conectó a la base de datos y usé variables de enlace.
Me puedo imaginar fácilmente poniendo guiones de shell en el software de vuelo de la nave espacial sería una mala idea. Pero Java o C++ pueden ser opciones igualmente pobres. La mejor opción sería cualquiera que sea el lenguaje (¿ensamblaje?) Que generalmente se usa para ese propósito.
El hecho es que si utiliza cualquier sabor de Unix, está utilizando scripts de shell en situaciones de misión crítica, suponiendo que piense que arrancar es una misión crítica. Cuando un script necesita hacer algo que Shell no es particularmente bueno, usted coloca esa porción en un subprograma. No tira el script al por mayor.
Es probable que las secuencias de comandos de shell que ayudan a tomar una empresa en el futuro. Sé desde el punto de vista de la programación que malgastaría mucho tiempo realizando tareas repetitivas que he delegado en 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 solo script, puedo disparar a voluntad, ahorro tiempo y energía mental.
Al igual que algunas otras personas han dicho que el lenguaje es un factor. Para mis cortos pasos de "no quiero recordar" y programas de pegamento, confío completamente en mis scripts de shell y confío en ellos. Eso no quiere decir que voy a construir un sitio web que ejecute Bash en el backend, pero seguramente usaré bash/ksh/python/lo que sea para ayudarme a generar el proyecto de esqueleto y administrar mi empaquetado y despliegue.
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 solo necesitan tener + x.
El hecho de que una secuencia de comandos tenga + r significa que los usuarios podrían hacer una copia de la secuencia de comandos, editarla, subvertirla y ejecutar su versión editada de Cuckoo's-Egg.
¿Qué ocurre si pueden ejecutar un script de shell copiado? Si el usuario puede crear un archivo y ejecutarlo, entonces no importa si el usuario copió el archivo o lo escribió desde cero: el archivo ejecutado tiene las mismas capacidades de cualquier manera. –
Cuando leo esta cita, me centro en la parte "solicitudes" en lugar de la parte "misión crítica".
Lo leí diciendo que bash no es para aplicaciones de escritura es para, bueno, scripting. Así que, seguro, su aplicación puede tener algunas secuencias de comandos de limpieza pero no escriba critical-business-logic.sh porque probablemente otro idioma sea mejor para esas cosas.
No importa que todos necesitemos una herramienta fexible para interactuar con os. Es una interacción humanamente legible con os que usamos, 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. Mira la ventana que incluso expandieron en su Powershell.
La mayoría de los lenguajes están relacionados con el sistema operativo en la mayoría de los aspectos. – Xailor