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
Gracias.
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
www.shellcheck.net/
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.
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.
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.
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.
Mawk es bastante más rápido que el awk tradicional y Perl por ejemplo.
El artículo ya no existe, pero se puede ver aquí: web.archive.org/web/20061114062046/http://blackshell.usebox.net/archiv
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.
Es una virguería.
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.
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)
En Python la mitad del codigo para la v2 no tira en la v3.
Es que no hay comparacion.
No depende sólo de los programadores, la flexibilidad de Perl lo convierte en un infierno, como Ruby.
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
"..........en minutos"
NUNCA NUNCA SON MINUTOS, sino horas, dias o semanas. Es un truco de marketing.
Aún estás a tiempo, no seas trasnochado.
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
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.
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
www.linux-magazine.com/Issues/2019/228/Debian-usr-Merge
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.
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.
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.
#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.
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.
Falso.
Qué años tienes?
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.
Ahora usarían Python o JS + electron para eso.
Pues como Numpy en Python, debajo es todo Fortran.
TCL Snack tambien estará escrita en C. Y?
Pero tendré en cuenta OCaml.
Si haces una librería en C de bajo nivel no quiere decir que TCL valga para eso
Perl tiene bindings para SDL. Perl solo sirve para operar con textos?
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.
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.
github.com/shwnchpl/tc8.tcl
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.
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.
Luego hay muchas cuestiones estéticas debatibles y que son cuestión de gustos.
Qué tiempos en la uni con ADA
¿Perl?
¿Ese lenguaje que se ve igual después de ofuscarlo?
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.