¿Cuándo usar Bash y cuándo usar Perl/Python/Ruby?

TL;DR:use bash solo para instalar un idioma mejor (si aún no está disponible), de lo contrario, está desperdiciando un tiempo humano precioso e irrecuperable. Si no puede hacerlo en la línea de comando a mano sin errores, no escriba con bash/shell.

Estamos en 2015, así que consideraría lo siguiente:

1. sobrecarga de memoria

   • La sobrecarga de memoria en tiempo de ejecución de Ruby/Python en comparación con bash es pequeña (debido a las bibliotecas compartidas), mientras que uno probablemente no pueda mantener un script de bash no trivial de todos modos (es decir, uno con> 100 líneas), por lo que el uso de memoria no es un factor

2. tiempo de inicio

   • El inicio de Ruby/Python puede ser un poco más lento, pero es probable que no ejecute muchos procesos completos de Ruby/Python en un ciclo cerrado 100 veces por segundo (si tiene ese tipo de necesidades, bash /shell es demasiado sobrecargado de todos modos y probablemente deba pasar a C/C++)

3. rendimiento

   • casi todo el procesamiento de datos típico será más rápido en Ruby/Python, o al menos comparable (o, de todos modos, necesita C/C++/Haskel/OCaml/lo que sea)
   • el rendimiento/cuello de botella real en la ejecución (o incluso la productividad) casi nunca ser "falta de uso de bash/shell" (incluso Ubuntu cambiando el tablero para el inicio muestra cómo bash es realmente el problema, y ​​un cuadro ocupado es probablemente el único caso de uso, porque hay nada más que 'bash' y 'vi' para escribir y ejecutar código, y a menudo no hay forma de agregar/descargar o almacenar nada más)
   • ejecutar otros procesos para hacer el trabajo (como sed/awk/grep) es en realidad mucho más lento que llamar a un método en un objeto vivo en la memoria

4. productividad

   • Es demasiado fácil cometer errores en Bash/Shell en comparación con el uso de métodos, parámetros, variables y excepciones "reales" en Ruby/Python
   • Agile es convencional, mientras que Bash no tiene soporte para ello (carece de capacidades de prueba unitaria, bibliotecas, OO, modularidad, linting, introspección, registro, metaprogramación; casi imposible de refactorizar sin romper algo)
   • demasiadas incompatibilidades con otros shells, las variables de entorno menores pueden romper por completo un script (y algunas herramientas de operaciones de desarrollo importantes como Puppet ignoran las líneas shebang y transmiten o reescriben variables de shell importantes), mientras que Ruby/Python tienen bien definido rutas de migración relativamente fluidas incluso para cambios de versión importantes
   • aprender un nuevo idioma requiere una fracción del tiempo que se dedica a depurar scripts de shell debido a problemas específicos del shell (en particular, nombres de variables, sin valores booleanos, sin excepciones, etc.)
   • incluso los scripts de inicio son una mina terrestre (especialmente porque pueden fallar durante sistema startup), y dadas las fallas de seguridad recientes con bash, es posible que sea mejor usar C simple (con buenas bibliotecas); sí, C necesita compilación, configuración, etc., pero incluso un script de shell simple puede necesitar un repositorio, luego versionado , luego empaquetar de todos modos.
   • Lo que sea que esté disponible con sed/awk/grep probablemente ya esté integrado en Ruby/Python, sin que sea una dependencia o "diferencias" entre las versiones de esas herramientas en todas las plataformas (y qué pasa si funciona en su configuración)
5. seguridad laboral
   • ¿Cuál es el punto de conseguir un trabajo que no te gusta? (a menos que le guste pasar todas esas horas con errores de script de shell difíciles de depurar pero triviales de hacer)

Creo que no hay razón para usar Bash/Shell si tiene instalado Ruby/Python.

Y probablemente para instalar Ruby/Python ni siquiera se necesita un script bash en primer lugar (con la excepción de busybox, algunas herramientas del sistema dependen de que Python/Perl esté presente de todos modos).

Y cada vez que escribe un script de shell, está "practicando" haciendo exactamente eso, en lugar de aprender algo más poderoso/productivo.

¿Por qué la gente usa Bash hoy en día? Porque es un hábito terrible y difícil de romper. Un guión rara vez está "terminado para siempre" después de los primeros minutos, sin importar cuán fuertemente la gente tienda a pensar de esa manera. Junto con la falacia "es el último error en este script".

Conclusión:use bash/shell solo cuando esté absolutamente forzado a (como ~/.bashrc , busybox), porque casi nunca "la herramienta adecuada para el trabajo" hoy en día.

Dado un problema que ambos pueden manejar, querrá usar el que le resulte más cómodo. En última instancia, hay muchos pequeños detalles y solo la experiencia puede enseñarte a verlos.

Bash es un lenguaje de secuencias de comandos de propósito general al igual que Python, Ruby, Perl, pero cada uno tiene diferentes fortalezas sobre el resto. Perl sobresale en el análisis de texto, Python afirma ser el más elegante del grupo, los scripts de Bash son excelentes para "transmitir cosas", si sabes a lo que me refiero, y Ruby... bueno, Ruby es un poco especial en mucho de caminos.

Sin embargo, las diferencias entre ellos solo importan una vez que tiene una buena cantidad de experiencia en secuencias de comandos en su haber. Le sugiero que elija un idioma y lo lleve al límite antes de pasar al siguiente. Puede hacer mucho en un script de shell, más de lo que la mayoría de la gente admitiría. Cualquier idioma es tan difícil como quieras hacerlo. Después de haber escrito un par de cosas en él, todos los idiomas son "fáciles" para ti.

Estar familiarizado con el shell vale la pena rápidamente si vive en Linux, así que tal vez quiera comenzar con eso. Si encuentra una tarea que es imposible o poco práctica de resolver en un script de shell, use otra cosa.

Además, tenga en cuenta que aprender scripts de shell es muy simple. Su verdadero poder radica en otros programas, como awk, sed, tr, et al.

Uso bash cuando mi enfoque principal está en el manejo de archivos. Esto podría incluir mover, copiar y renombrar archivos, así como usar archivos como entrada para otros programas o almacenar la salida de otros programas en archivos. Raramente escribo código bash que realmente examine el contenido de un archivo o genere la salida para escribir en un archivo; Eso se lo dejo a los otros programas (que puedo escribir en Perl o Python) que lanzo a través de bash.

Uso Perl y python cuando mi enfoque principal es leer datos de archivos, procesar esos datos de alguna manera y escribir resultados en archivos. Si me encuentro usando (en Perl) el system comando, back ticks o (en python) el subprocess module demasiado extensamente, considero escribir el script en bash. Por otro lado, a veces empiezo a agregar tanta funcionalidad a un script de bash que eventualmente tiene más sentido reescribirlo en Perl/python en lugar de lidiar con el soporte limitado (en comparación) de bash para alcance variable, funciones, estructuras de datos, etc. .