Portada
mis comunidades
otras secciones
![Mejora tus scripts en BASH con sólo 15 minutos de tutorial [ENG]](https://cdn.mnmstatic.net/cache/35/a0/media_thumb_2x-link-3514596.jpeg?1623334506)
#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.
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:
Un consejo es que se use shellcheck para chequear y validar los scripts, la verdad que ayuda mucho.
https://www.shellcheck.net/
https://www.shellcheck.net/
#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: https://docstore.mik.ua/orelly/index.htm
Paso 5: The Perl CD Bookshelf, version 4.0
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: https://docstore.mik.ua/orelly/index.htm
Paso 5: The Perl CD Bookshelf, version 4.0
Comentarios
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 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.
#6 a donde va ahora? Llevo un par de años trabajando en Linux antiguos y me estoy perdiendo estos dramas
#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.
https://www.linux-magazine.com/Issues/2019/228/Debian-usr-Merge
#46 ahhh. Pensé que era /usr/bin que apuntaba a otro sitio.
#52 ¡otro combo de symlinks en cadena no, por favor! 😷
#61 estaba alucinando porque he hecho ejercicios hace poco en debian 10 y claro /usr/bin no era un symlink
#62 y si lo es es que alguien la ha liado parda.
#63 como cuando me cargué el sudoers / desinstalé sudo y al final ni sé cómo lo arreglé.
#65 yo soy antisudo. Lo arreglaste desinstalando.
#65 yo me lo cargué y se lo llevé a los que se encargaban de arreglar los pcs en la empresa y reinstalaron
#6 ¿ Dónde apunta ?
#0 Buen envío. Sencillo y al grano. Muy útil.
Gracias.
Un consejo es que se use shellcheck para chequear y validar los scripts, la verdad que ayuda mucho.
https://www.shellcheck.net/
#7 Venía a decir esto, ya está dicho, me voy...
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: https://docstore.mik.ua/orelly/index.htm
Paso 5: The Perl CD Bookshelf, version 4.0
#3 pues fijate tú que yo uso Python básicamente como sustituto de Perl precisamente (a nivel de sistemas, que conste)
#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).
#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...
#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.
#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.
#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 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 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 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 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 >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 me puedes indicar un repositorio donde se use?
#68 No recuerdas AMSN?
#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 >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 te estás desdiciendo.
#75 Son librerias para TCL no? Pues ya está.
TCL Snack tambien estará escrita en C. Y?
#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 Eso es una falacia.
Perl tiene bindings para SDL. Perl solo sirve para operar con textos?
#80 Perl tiene tipos numéricos, TCL es como bash, solo opera con cadenas.
#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.
https://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 porque Gemini es un protocolo de texto. Haz un cliente GRPC y me cuentas.
#83 Chorradas:
https://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 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 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.
#83 Algo similar a esto pero sin objetos:
https://github.com/shwnchpl/tc8.tcl
#72 Yo te recomiendo que eches un ojo a Ocaml por ver las cosas que se pueden hacer de forma cuasinativa.
#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.
#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.
#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 Si algo he aprendido es que eso es falso, se puede crear codigo ofuscado en cualquier lenguaje.
#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 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.
#96 Y con Go es mas facil tambien con cosas como gofmt, pero repito, se puede hacer churros con todo.
#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.
#95 Otros lenguajes tienen clausulas similares y no por ello se libran de crear horrores.
#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.
#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 https://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.
#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 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.
#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 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.
#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 No he probado con ningún otro la verdad.
#28 C fijo que puedes, los string son arrays de caracteres.
#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 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 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 Es que desde Perl 4.x ya ha llovido MUY mucho. Te hablo de tiempos de Windows 3.1...
#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
#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.
#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.
#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í: https://web.archive.org/web/20061114062046/http://blackshell.usebox.net/archivo/965.php
#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 también apt-get, y debian en general tiene una dependencia muy fuerte de perl.
#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.
#3 Yo nunca he usado awk en la vida... siempre tiro de perl -pe
#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 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.
#3 yo ya llevo tiempo usando notebook (lab) para casi todo.
#20 http://phroxy.z3bra.org/bitreich.org:70/0/con/2020/rec/energy-efficient-programming.md
#21 ;3 por que me haces esto
#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.
#3 awk siempre me ha maravillado para el tratamiento de cadenas.
Es una virguería.
#3 Paso 6: Darte cuenta que estabas errado en el paso 0 y sustituir Pero por Python.
#32 g/Python/d
#3
¿Perl?
¿Ese lenguaje que se ve igual después de ofuscarlo?
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?
"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.
#9 es Blogspot. ¿Con quien quieres que compartan los datos?
#45 Con nadie...
#47 Blogspot es de Google...
#53 Blogspot que va a la lista negra pues
#90 unos 18 años después...
#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 entiendo.
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.
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.
Si queréis usar bash bien de verdad, os recomiendo esta página:
https://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.
#100 Empecé como sysadmin en la Uni en el año 95, cuando nadie sabía lo que era internet en España.
El artículo es para principiantes, pero mi enlace en #71 no.
Algo sé.
Si desprecias bash no dice nada bueno de ti como dev, sysadm o lo que seas.
Usa oil shell
me viene al pelo #!/bin/bash
aprender a mejorar tus scripts en el engendro de bash
#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.
#99 novato eres tu que no lo ves...
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 perl -E 'print pack "B8" for@ARGV' 01011001 01101111 00100...