edición general
209 meneos
5297 clics
Mejora tus scripts en BASH con sólo 15 minutos de tutorial [ENG]

Mejora tus scripts en BASH con sólo 15 minutos de tutorial [ENG]

Los consejos y trucos que se muestran a continuación para hacer mejores scripts en BASH aparecieron originalmente como uno de los episodios de “Testing on the Toilet” (TOTT) de Google. Esta es una versión revisada y mejorada.

| etiquetas: mejorar , scripts , bash , 15 minutos , tutorial , testing on the toilet , tott
«12
  1. Excelente resumen de buenas prácticas. Pero como norma general es preferible usar como shebang "#!/usr/bin/env bash" a "#!/bin/bash". Muchos BSDs y algunas distros de Linux no instalan bash en bin.
  2. #3 pues fijate tú que yo uso Python básicamente como sustituto de Perl precisamente (a nivel de sistemas, que conste) ?(
  3. #0 Buen envío. Sencillo y al grano. Muy útil.
    Gracias.
  4. #2 de hecho /bin como directorio va a ser discontinuado. Ya es un symlink en las distribuciones modernas, o muchas de ellas, por razones de compatibilidad como esta de los shebangs por ejemplo.
  5. Un consejo es que se use shellcheck para chequear y validar los scripts, la verdad que ayuda mucho.

    www.shellcheck.net/
  6. #3 +1 por la referencia a Perl que últimamente ha dejado de usarse un poco (creo en favor de python).

    Perdón por el off topic, pero hay que reivindicarlo. En realidad Perl/Raku nunca se ha ido y volverá a estar de moda como ha ocurrido con el vinilo o las cámaras de carrete. Si lo usan empresas como amazon, duckduckgo e imdb, será por algo.
  7. Paso 0: Python es horrible como herramienta superior a Bash.
    Paso 1: Evita Bash, usa checkbashisms.
    Paso 2: Usa AWK cuando lo requiera.
    Paso 3: Aprende Perl para algo que supere las 20 lineas.
    Paso 4: docstore.mik.ua/orelly/index.htm
    Paso 5: The Perl CD Bookshelf, version 4.0
  8. #10 quizá pero encuentro Python más versátil y más legible, sobretodo si tengo que modificar algún script hecho hace tiempo y del que ni me acordaba...
  9. #12 #13 me parece que no estáis familiarizados con Perl porque lo de la legibilidad no tiene sentido.

    Los siglums de Perl pueden hacer código infumable. En Python también puedes hacer código infumable a base de múltiples list comprehensions anidadas, malos nombres de variables y demás. Eso es cosa del programador, no del lenguaje.
  10. #6 ¿ Dónde apunta :-O ?
  11. #23 #43 ha pasado a ser un enlace simbólico a /usr/bin tanto en Debian como en RHEL y sus respectivas derivadas, incluyendo Ubuntu. Nada dramático. :-P

    www.linux-magazine.com/Issues/2019/228/Debian-usr-Merge
  12. #8 En principio yo diría que Perl es más directo a la hora de interactuar con el SO. Y más compatible (sin problemas de incompatibilidad entre versiones).
  13. #56 estoy con #59 y he tenido esa experiencia con Python. Un mal programador va a liarla en cualquier lenguaje. Es su “cabeza” el problema, el modelado en cualquier lenguaje será un infierno.

    Luego hay muchas cuestiones estéticas debatibles y que son cuestión de gustos.

    Qué tiempos en la uni con ADA :-)
  14. #6 a donde va ahora? Llevo un par de años trabajando en Linux antiguos y me estoy perdiendo estos dramas
  15. #24 Los strings en Python son inmutables, se hace para evitar bugs y que por accidente modifiques el objeto que puede estar apuntado desde otro sitio. Por lo que para conseguir lo que quieres deberías crear otro string. Es muy común en la mayoría de lenguajes de programación que pase esto. ¿En qué lenguaje haces esta asignación libremente?.
  16. :troll: Este es el hilo para comentar entre el abuelo cebolleta que programa todo en C y como mucho considera Perl como algo "modernillo" y los jovenes con Panda Python y datascience big dateros? :troll:
  17. #17 AWK tiene sus cosas interesantes y es universal de verdad, en todo Unix lo tienes. Pero es para cosas cortas en datos tabulares, no le pidas magia.
    Mawk es bastante más rápido que el awk tradicional y Perl por ejemplo.
  18. #24 Porque en Python, por decisión de diseño del lenguaje, los strings son inmutables. En Python nunca modificas un string aunque lo pueda parecer. Se crea otro string modificado.
  19. #29 La version 4 de Perl es vieja de cojones. Todo lo hecho para la v5 funciona del tiron, y son creo casi 30 años.

    En Python la mitad del codigo para la v2 no tira en la v3.

    Es que no hay comparacion.
  20. #3 Evita bash si estás en un entorno heterogéneo, en según qué otros sitios, poder usar no ya bash, si lo versiones modernas, con sus matrices asociativas, etc. te deja un código más claro.
  21. #14 conozco Perl, Ruby y Python y es mucho más legible Python.

    No depende sólo de los programadores, la flexibilidad de Perl lo convierte en un infierno, como Ruby.
  22. #18 No lo dudo, lo mío es vagancia más que otra cosa. Todavía no me he encontrado sistemas sin Perl. Sin Python, bastantes.
  23. #46 ahhh. Pensé que era /usr/bin que apuntaba a otro sitio.
  24. #61 estaba alucinando porque he hecho ejercicios hace poco en debian 10 y claro /usr/bin no era un symlink :shit:
  25. #62 y si lo es es que alguien la ha liado parda. :-D
  26. #63 como cuando me cargué el sudoers / desinstalé sudo :shit: y al final ni sé cómo lo arreglé.
  27. #91 En realidad no suelo frecuentar esos sitios y reconozco que, aunque a veces lo haga, no tengo tiempo o curiosidad por saber de dónde provienen todas y cada una de los sitios que visito porque me volvería majara.
  28. #92 entiendo.
  29. "de Google". Esa coletilla...

    Insisto, mucho cuidado, que se os adelantan y luego "¡ay!". Acabaréis adorando a quien os acabará dominando.

    Por cierto, en la cabecera de la web: "Este sitio utiliza cookies de Google para prestar sus servicios y para analizar su tráfico. Tu dirección IP y user-agent se comparten con Google, junto con las métricas de rendimiento y de seguridad, para garantizar la calidad del servicio, generar estadísticas de uso y detectar y solucionar abusos."

    Ya es que paso.
  30. #3 Paso 6: Darte cuenta que estabas errado en el paso 0 y sustituir Pero por Python.
  31. #13 Lo de la ilegibilidad de Perl viene de programadores de la GenZ que no han tocado Perl en su vida.

    Estáis acostumbrados a los Code Golf de Perl y no habeis visto código normalizado jamás.

    Ve a docstore.mik.ua/orelly/index.htm, lee la version 4.0 del CD Bookshelf, empieza por Programming Perl y dime donde está el código ilegalible.

    Es Perl, no APL/q/k.
  32. #22 > y en él ya se habla de que Perl está cada vez más en desuso.

    Perl se usa en OpenBSD para el gestor de paquetes y para scripts, y de hecho tiene soporte de Pledge y Unveil, cosa que Python no, ni en la version 2 ni en la 3.
  33. #40 Es que desde Perl 4.x ya ha llovido MUY mucho. Te hablo de tiempos de Windows 3.1...

    EDIT: Perl5 es del 1994 y CPAN es del 1995, asi que hablar de Perl4 es casi como hablar de gente que seguia usando un 386 en la era de Pentium.
  34. #56 Si algo he aprendido es que eso es falso, se puede crear codigo ofuscado en cualquier lenguaje.
  35. #58 Ojalá todo lo que esté en Java en la parte de servicios se migre a Go. Te ahorras miles de quebraderos de cabeza.

    #48 No conoces una mierda de TCL, se usa muy mucho en routers y dispositivos empotrados. Y Expect es una maravilla.
    C++ para mi es un aborto y nunca debió haber nacido.
    De hecho para mi Go es EL sucesor natural de C, tanto por filosofia (Unix/C -> Plan9/Nc/Go), como por
    sintaxis y su capacidad multiplataforma real. No será tan bueno en rendimiento como C++, pero seamos realistas:
    Para equipos "legacy" es mucho mejor C y hay librerias de sobra, y Go cubre mejor el nicho de servicios en red.
    Python con el espaciado en blanco es lo puto peor que hubieran podido crear JAMÁS. Es una basura en cuanto a sintaxis, haciendo que el codigo pueda descuadrarse trivialmente.
    Cambia Python por Ocalm y hablamos.
  36. #74 gracias, pero de aprender algo funcional tiraría por Haskell o algún Lisp que ya jugué con alguno y van más conmigo.

    Pero tendré en cuenta OCaml.
  37. #96 Y con Go es mas facil tambien con cosas como gofmt, pero repito, se puede hacer churros con todo.
  38. #3 yo ya llevo tiempo usando notebook (lab) para casi todo.
  39. #3 Yo nunca he usado awk en la vida... siempre tiro de perl -pe
  40. El artículo está muy bien. Pero ya me sonaba, he ido a comprobar la fecha y es del 2012. Aún así, me ha gustado revisitarlo y realmente son buenas prácticas.
  41. #3 awk siempre me ha maravillado para el tratamiento de cadenas.
    Es una virguería.
  42. No creo que odie mas esa frase en programacion de:
    "..........en minutos"


    NUNCA NUNCA SON MINUTOS, sino horas, dias o semanas. Es un truco de marketing.
  43. #38 en la vida real te encuentras cada cosa de morirte echa en perl. Por lo que creo que esto que pones no lo ha leido nadie.
  44. #14 depende del programador. Pero siempre será más legible el mismo código hecho en ADA que en C. Hay lenguajes que te facilitan que sea legible y trazable el código. ADA es un buen ejemplo.
  45. Si queréis usar bash bien de verdad, os recomiendo esta página:
    wiki.bash-hackers.org/
    Yo ya soy un viejo lobo y ya he usado mucho sh, awk, perl, python, y algunos más...
    Pero en esta página descubrí hace años muy buenos trucos y recomendaciones que me no conocía y muy bien organizados. Suelo recomendarla desde entoces a mis equipos.
  46. #9 es Blogspot. ¿Con quien quieres que compartan los datos?
  47. #47 Blogspot es de Google...
  48. #90 unos 18 años después...
  49. #103 en mi caso era una máquina virtual, podría perfectamente haberla restaurado a una snapshot anterior, pero no me dio la gana, quería aprender a solucionarlo yo.
  50. Usa oil shell
  51. #15 Bueno, eso de "últimamente"... Este envío es del año 2006 y en él ya se habla de que Perl está cada vez más en desuso.

    El artículo ya no existe, pero se puede ver aquí: web.archive.org/web/20061114062046/http://blackshell.usebox.net/archiv
  52. #45 Con nadie...
  53. #52 ¡otro combo de symlinks en cadena no, por favor! {0x1f637}
  54. #65 yo soy antisudo. Lo arreglaste desinstalando. :-P
  55. #53 Blogspot que va a la lista negra pues :-P
  56. me viene al pelo #!/bin/bash
  57. #7 Venía a decir esto, ya está dicho, me voy...
  58. #3

    ¿Perl?

    ¿Ese lenguaje que se ve igual después de ofuscarlo?
  59. #13 Hasta peña muy pro mete la gamba con C. No me quiero imaginar si meto yo las narices ahí, que soy un novato.

    Python tiene cosas que no acabo de entender por qué, por ejemplo no sé por qué no se puede asignar un valor tal que string[i] = valor, si el string ya está indexado. Supongo que tendrá alguna explicación, pero bueno, hablo desde mi perspectiva de novato.
  60. #10 Hace ya años de esto y lo voy a decir de memoria, pero de lo poco que he trabajado en Perl, un programa del que tuve que hacer mantenimiento (y rehacerlo, porque vaya código espaguetti), no sé/no recuerdo porqué funcionaba con una versión muy concreta de Perl. Creo recordar que la causa era un módulo que no funcionaba bien en versiones posteriores (pero no cambios de versión grande. Ponte por ejemplo, y me estoy inventando, de la versión 4.8.1 y no funcionaba con la 4.8.3, no hablemos de una versión 5.x)

    Eso sí, en mi experiencia, manejando listas/colas de ficheros va follao

    La sintaxis y legibilidad no me resultó ningún drama (y eso que mi primera experiencia con el lenguaje fue con un programa, que creo que el autor lo hizo ilegible a proposito para garantizarse el trabajo,....no tengo pruebas, pero no tengo dudas)

    Luego no he tenido muchas más experiencias con ese lenguaje. Sí que había algunas veces que el comportamiento era un poco raro (e investigando, creo que el propio Larry Wall lo reconocía), como inconsistencias a la hora de sacar elementos de una pila o lista. Si , en ocasiones, hacías (de nuevo recitando de memoria) pop(0) en vez de sacarte el elemento 0, te sacaba el 1 (alguna cosilla así, cuando me ocurrió me volví un poco loco intentando averiguar que pasaba....al final lo hacías de otra forma o con otra instrucción y punto)
  61. #32 g/Python/d
  62. #12 #13 #14
    Yo soy muy de defender a todos los lenguajes puesto que cada uno es una herramienta y será más adecuada para una situación u otra.

    Estoy, en parte, de acuerdo con @KIKON cuando dice que si el rendimiento no importa mucho...y aquí viene mi desacuerdo: no diría Python sino el lenguaje que te resulte más cómodo. Vamos, que cuando no hay requisitos que te "obliguen" hacerlo con un lenguaje, coge el que más te guste ;)
  63. #16 yo viví la época en la que casi todos los programadores de Perl nos pasamos a Python.

    Aún estás a tiempo, no seas trasnochado.
  64. #34 Pues ya te digo que he tirado de memoria y que las cifras de las versiones me las estoy inventando, pero estoy convencido que el script estaba escrito en Perl 4.x.

    Afortunadamente no duré mucho más esa empresa (o la verdad es que sí, me tenía que haber ido justo después, pero por otras cosas), que lo mejor y con lo que más disfruté fue con ese proyecto (que encima fue: "ahora que el verano está tranquilo, ve echándole un ojo a ver si lo dejas bonito/lo mejoras"). Creo que fue lo único en lo que trabajé relacionado con mi formación y CV
  65. #28 No he probado con ningún otro la verdad.
  66. #41 Sí, sí. Te creo completamente.

    Era una empresa de mierda y sé perfectamente que al que sustuí (y me hice cargo de su código) debía ser un tío bastante "peculiar" por todo lo que me contaron otros compañeros.

    Me hicieron toquetear el script porque, sinceramente, creo que nadie en la empresa sabía/se atrevía a hacerlo. Y eso que era parte fundamental de la solución técnica que vendían :palm:
  67. #36 hay lenguajes que no deberían existir, como PHP, que es una ñapa hecha lenguje... O Ruby que es para los hipsters a los que Python les parece muy mundano... O Javascript para el servidor, para vagos que no quieren aprender un lenguaje de verdad... O TCL que cree que todo es texto...

    A ver, hay una docena de lenguajes de propósito general que están bien, tienen sus ventajas, y otros de nicho, pero muchos harían mejor en desaparecer.

    Se salvan de la hoguera: C, C++, Java, Kotlin, Swift, Scheme, Clojure, Haskell, Python, Lua, Golang y Rust.
  68. #22 Es obvio que Perl se usa menos ahora que hace 20 años pero yo no diría que está en desuso ni de coña. Según TIOBE se está incluso incrementando su uso.
  69. #27 también apt-get, y debian en general tiene una dependencia muy fuerte de perl.
  70. #39 Porque el futuro va a ser solar/eléctrico y no va a haber potencia para todos.

    De ahí que necesitemos sistemas que consuman una mierda con componentes extremadamente baratos.

    Auguro placas risc-v chinas ultrabaratas a un coste "comprensible" y las GPU/CPU tipo Ryzen/i3/RTX subiendo por las nubes.

    Y por supuesto un aumento de ventas de libros de matematicas. No todo va a tener equipos con CUDA en sus casas, van a tener que usar el cerebro comprendiendo los valores, ecuaciones y algoritmos como en el ejemplo.
  71. #60 el go con el recolector de basura no es bueno como sustituto de C/C++ cuando la latencia es crítica, mejor Rust.

    Lo de Python es opinable.

    TCL es una basura, se usará en routers para cosas de alto nivel, configuración y web embebida. Porque solo vale para texto.
  72. #60 C++ es una pasada. A mí no me gusta programar en él pero sus facilidades con un rendimiento cercano a C lo hacen una maravilla.
  73. #64 >TCL es una basura, se usará en routers para cosas de alto nivel, configuración y web embebida. Porque solo vale para texto.

    Falso.

    Qué años tienes?
  74. #67 me puedes indicar un repositorio donde se use?
  75. #68 No recuerdas AMSN?
  76. #70 pero ahí TCL/TK pinta las ventanas y mueve el texo pero la parte de red y protocolos la hacen en C.

    Ahora usarían Python o JS + electron para eso.
  77. #72 >pero ahí TCL/TK pinta las ventanas y mueve el texo pero la parte de red y protocolos la hacen en C.

    Pues como Numpy en Python, debajo es todo Fortran.
  78. #72 Yo te recomiendo que eches un ojo a Ocaml por ver las cosas que se pueden hacer de forma cuasinativa.
  79. #73 te estás desdiciendo.
  80. #75 Son librerias para TCL no? Pues ya está.

    TCL Snack tambien estará escrita en C. Y?
  81. #77 pero es lo que yo decía, que TCL vale para mover texto y poco más. Que si se usaba en routers sería para configuraciones y webs...

    Si haces una librería en C de bajo nivel no quiere decir que TCL valga para eso
  82. #79 Eso es una falacia.

    Perl tiene bindings para SDL. Perl solo sirve para operar con textos?
  83. #80 Perl tiene tipos numéricos, TCL es como bash, solo opera con cadenas.
  84. #81 No me refiero a eso, lo sé perfectamente, hace poco edité un script con tcl/tk que era un cliente Gemini.

    Tcllib tambien tiene una librería matemática comparable a Math:: en Perl.
    tools.ietf.org/doc/tcllib/html/math.html
    Perdón, no comprable, bastante superior.

    Lo que quiero decir es que con Perl sacaron cosas como el Pixpang, escrito con Perl llamando a SDL.
  85. #82 porque Gemini es un protocolo de texto. Haz un cliente GRPC y me cuentas.
  86. #83 Chorradas:

    wiki.tcl-lang.org/page/Working+with+binary+data

    Estuve incluso a punto de acabarme un emuador de CHIP8.

    Es decir, parsear binarios y simular opcodes en un procesador cutrer.
  87. #83 Algo similar a esto pero sin objetos:

    github.com/shwnchpl/tc8.tcl
  88. #84 muy interesante.

    Pero no deja de ser una ñapa como dice el mismo artículo.

    Es un hack, usar los 256 caracteres de Unicode para manipular datos binarios.

    Hay gente que programa juegos en Excel, coloreando celdas.

    Si te divierte por mi perfecto, pero no es la mejor opción.
  89. #86 No es lo mismo.

    En este caso puedes usar el formato Hex que es similar en uso en C.

    Sobre hacks... la coma flotante también es un hack enorme en realidad, es pura representación, aunque desde
    el coprocesador sea 15 veces más rápido que el calculo con enteros y escalar para luego representar el punto en el formato.
  90. #95 Otros lenguajes tienen clausulas similares y no por ello se libran de crear horrores.
  91. #65 yo me lo cargué y se lo llevé a los que se encargaban de arreglar los pcs en la empresa y reinstalaron xD
  92. #21 ;3 por que me haces esto
  93. #48 Como me falta experiencia en muchos de esos lenguajes, sería atrevido por mi parte mandarles a la hoguera o no.

    Sí que te puedo decir que me ha tocado defender a Java (como lo que es, lenguaje orientado a objetos multiplataforma) de algún compañero pipiolo (y no tan pipiolo) que lo único que sabían decir de Java es que es una mierda. C también me ha tocado defenderlo ante más de algún compañero para los cuales C es mierda por "estar anticuado", "hay que estar controlando la memoria", "hay que compilarlo",....en serio, he oido de todo y algunas absurdeces muy serias.

    Todos los lenguajes con los que me he familiarizado un poco tenían su sentido, aunque fuese en el momento en el que fueron creados. Por mi parte no me atrevo a encender la hoguera.
  94. Yo solo quería decir que:01011001 01101111 00100000 01110011 01101111 01101100 01101111 00100000 01110000 01110010 01101111 01100111 01110010 01100001 01101101 01101111 00100000 01100011 01101111 01101110 00100000 01100011 01100101 01110010 01101111 01110011 00100000 01111001 00100000 01110101 01101110 01101111 01110011 00001010 00001010 01010101 01110011 01100001 01110010 00100000 01110101 01101110 00100000 01101100 01100101 01101110 01100111 01110101 01100001 01101010 01100101 00100000 01100100 01100101 00100000 01110000 01110010 01101111 01100111 01110010 01100001 01101101 01100001 01100011 01101001 01101111 01101110 00100000 01100101 01110011 00100000 01100100 01100101 00100000 01101101 01100001 01110100 01100001 01101111 01110011 00101100 00100000 01101000 01100001 01111001 00100000 01110001 01110101 01100101 00100000 01110100 01100101 01101110 01100101 01110010 00100000 01110101 01101110 00100000 01101110 01100101 01111000 01101111 00100000 01100011 01101111 01101110 00100000 01110100 01110101 00100000 01101111 01110010 01100100 01100101 01101110 01100001 01100100 01101111 01110010
  95. #10 a nivel de sistemas... C. Pero entiendo que es un coñazo, yo cuando tenia los proCs para base de datos y los programas que atacaban a apis de mis herramientas en C reconozco que tenia que hilar muy fino y comentarlo todo muy bien. Luego Perl, que además para algunas cosas es más sencillo que C, eso si legibilidad si no comentas... igual que C. Cero. Si el rendimiento no importa mucho... Python siempre. Insultantemente facil y puedes hacer de forma más sencilla un código más legible que con la mierda de Perl o C.
  96. #28 C fijo que puedes, los string son arrays de caracteres.
  97. #59 de falso nada. Por ejemplo yo aprendí que era util comentar las variables globales que podian cambiar su valor en una función gracias a que ADA te obligaba a declararlas como aliased si no recuerdo mal. Hay lenguajes que te ayudan a estructurar mejor el código. No digamos tontas.
«12
comentarios cerrados

menéame