edición general
209 meneos
5295 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. #0 Buen envío. Sencillo y al grano. Muy útil.
    Gracias.
  2. 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.
  3. 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
  4. Usa oil shell
  5. 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.
  6. #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.
  7. Un consejo es que se use shellcheck para chequear y validar los scripts, la verdad que ayuda mucho.

    www.shellcheck.net/
  8. #3 pues fijate tú que yo uso Python básicamente como sustituto de Perl precisamente (a nivel de sistemas, que conste) ?(
  9. "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.
  10. #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).
  11. #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.
  12. #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...
  13. #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.
  14. #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.
  15. #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.
  16. #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.
  17. #3 Yo nunca he usado awk en la vida... siempre tiro de perl -pe
  18. #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.
  19. #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.
  20. #3 yo ya llevo tiempo usando notebook (lab) para casi todo.
  21. #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
  22. #6 a donde va ahora? Llevo un par de años trabajando en Linux antiguos y me estoy perdiendo estos dramas
  23. #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.
  24. #3 awk siempre me ha maravillado para el tratamiento de cadenas.
    Es una virguería.
  25. #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.
  26. #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.
  27. #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?.
  28. #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)
  29. :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:
  30. me viene al pelo #!/bin/bash
  31. #3 Paso 6: Darte cuenta que estabas errado en el paso 0 y sustituir Pero por Python.
  32. #32 g/Python/d
  33. #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.
  34. #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.
  35. #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 ;)
  36. 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.
  37. #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.
  38. #21 ;3 por que me haces esto
  39. #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
  40. #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.
  41. #28 No he probado con ningún otro la verdad.
  42. #6 ¿ Dónde apunta :-O ?
  43. #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:
  44. #9 es Blogspot. ¿Con quien quieres que compartan los datos?
  45. #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
  46. #45 Con nadie...
  47. #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.
  48. #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.
  49. #7 Venía a decir esto, ya está dicho, me voy...
  50. #27 también apt-get, y debian en general tiene una dependencia muy fuerte de perl.
  51. #46 ahhh. Pensé que era /usr/bin que apuntaba a otro sitio.
  52. #47 Blogspot es de Google...
  53. #28 C fijo que puedes, los string son arrays de caracteres.
  54. #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.
  55. #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.
  56. #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.
  57. #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.
  58. #56 Si algo he aprendido es que eso es falso, se puede crear codigo ofuscado en cualquier lenguaje.
  59. #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.
  60. #52 ¡otro combo de symlinks en cadena no, por favor! {0x1f637}
  61. #61 estaba alucinando porque he hecho ejercicios hace poco en debian 10 y claro /usr/bin no era un symlink :shit:
  62. #62 y si lo es es que alguien la ha liado parda. :-D
  63. #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.
  64. #63 como cuando me cargué el sudoers / desinstalé sudo :shit: y al final ni sé cómo lo arreglé.
  65. #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.
  66. #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?
  67. #67 me puedes indicar un repositorio donde se use?
  68. #65 yo soy antisudo. Lo arreglaste desinstalando. :-P
  69. #68 No recuerdas AMSN?
  70. 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.
  71. #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.
  72. #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.
  73. #72 Yo te recomiendo que eches un ojo a Ocaml por ver las cosas que se pueden hacer de forma cuasinativa.
  74. #73 te estás desdiciendo.
  75. 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
  76. #75 Son librerias para TCL no? Pues ya está.

    TCL Snack tambien estará escrita en C. Y?
  77. #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.
  78. #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
  79. #79 Eso es una falacia.

    Perl tiene bindings para SDL. Perl solo sirve para operar con textos?
  80. #80 Perl tiene tipos numéricos, TCL es como bash, solo opera con cadenas.
  81. #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.
  82. #82 porque Gemini es un protocolo de texto. Haz un cliente GRPC y me cuentas.
  83. #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.
  84. #83 Algo similar a esto pero sin objetos:

    github.com/shwnchpl/tc8.tcl
  85. #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.
  86. #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.
  87. #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 :-)
  88. #3

    ¿Perl?

    ¿Ese lenguaje que se ve igual después de ofuscarlo?
  89. #53 Blogspot que va a la lista negra pues :-P
  90. #90 unos 18 años después...
  91. #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.
  92. #92 entiendo.
  93. #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.
  94. #88 lo de 59 es una patraña. Claro que alguien malo es malo con cualquier lenguaje. Pero alguien normal le es más facil hacer código legible con ADA que con C por ejemplo.
  95. #95 Otros lenguajes tienen clausulas similares y no por ello se libran de crear horrores.
  96. #96 Y con Go es mas facil tambien con cosas como gofmt, pero repito, se puede hacer churros con todo.
  97. #94 Por tus palabras deduzco que eres un novato.

    Bash está muy bien.

    No sé tú pero yo tengo muchos tipos y tamaños de destornilladores, varios martillos,...
    Se trata de utilizar la herramienta adecuada para cada tarea.
«12
comentarios cerrados

menéame