Hace 1 año | Por ccguy a sharats.me
Publicado hace 1 año por ccguy a sharats.me

Los scripts de shell nunca pasan de moda. Aquí tienes algunas buenas prácticas, empezando por "usa siempre bash".

Comentarios

sauron34_1

#7 jajaja mis dies.

senador

#6 ¡Ánde vamos, señorita, ánde vamos!

jonolulu

#6 Sí, por favor

aironman

#6 buenos tiempos…

w

#17 Ah claro, y los informáticos no tenemos derecho a puente. Como mucho un cuenco de arroz extra porque les sobra a los que se van de puente.

Todo correcto.

M

#19 Soy informático y no tengo puente. Y no tengo por el cuenco de arroz, como bien dices.
Eso sí, un cuenco de arroz muy, muy grande...

c

#17 al revés, votan los que no trabajan en menéame

B

#6 MONESVOL te oiga

A

#6 Estaría genial volver a tener un meneame con noticias sobre ciencia y tecnología.

¡Más grafeno y menos politiqueo!

Find

#6 Tú ve tirando para atras que acabas en Barrapunto

#6 las portadas rancias nunca mueren

D

#9 100% de acuerdo. ¿El script empieza a tener logica de dominio? Pasalo a Python.

u

#11 #9 yo no tengo mucho conocimiento de Python a ver si me podéis ayudar.
Sé qué Python tiene distintas versiones ahora creo que está la 3 ¿Un script creado con la versión uno o dos es siempre 100% compatible con la versión 3? ¿Python funciona con una máquina virtual tipo Java?

Muchas gracias!

D

#18 No. En Python la cagaron e hicieron una versión 3 incompatible con la versión 2.

Afortunadamente, más de una década después, puedes usar la versión 3 con la certeza de que está bien soportada por todas las bibliotecas.

Python es interpretado. Tienes que instalarte el intérprete de Python para poder ejecutarlo. Lo que vendría a ser esa capa intermedia que tú asocias a la máquina virtual de Java, aunque son tecnologías completamente distintas.

barni

#20 ¿"la cagaron"? ¿Qué/cómo habrías hecho tú para implementar todo lo que se hizo en Python3?

D

#32 seguro que yo lo habría hecho mucho peor.

Pero la realidad es que Python 2 y Python 3 han estado 14 años conviviendo porque la base de código existente en Python 2 no podía migrar fácilmente a Python 3. No solo por la cantidad de código a reescribir, sino porque las dependencias también tardaron en dar el paso a Python 3.

Lenguajes como Go, Java o C han evolucionado durante décadas y jamás liaron tamaños pifostios.

barni

#38 Java cambió mucho de v1.0 a v1.2, de 1.2 a 1.5 y de ahí en adelante, y en varias ocasiones se rompió la compatibilidad.

El paso de Python2 a Python3 fue el catalizador de la explosión en el uso de Python en la última década. Creo yo que en Python2 habría sido prácticamente imposible tal explosión, así que no creo que la hayan cagado tanto como dices. En todo caso se arreglaron cagadas e incoherencias del pasado.

Dicho sea de paso, ni en sus sueños más húmedos Guido van Rossum se imaginó en su momento que Python tendría la adopción masiva que terminó teniendo.

D

#41 cambió mucho, pero incluso en el salto de 1.2 a 1.5 no hubieron rupturas de compatibilidad. Como mucho, alguna característica de la API o de la JVM se marcaría como "deprecated" con años de antelación a su eliminación.

pawer13

#44 Tantos años de antelación que prácticamente no han borrado nada.

llorencs

#18 No, un script creado con Python 1 dudo que lo encuentres, ya que data de los años 90. Python 2 y Python 3 no son compatibles.

Por ejemplo, algo tan simple como el "print" (imprimir por pantalla) de Python 2 es incompatible con la sintaxis de "print" de Python 3.
Python 2:
print "Hola, qué haces?"

Python 3:
print("Hola, qué haces?")

En Python 2 el print era un "statement" como un if, mientras en Python 3 es una función.

Funciona como una máquina virtual, pero en Python 3 hicieron cambios importantes que rompía la compatibilidad con las versiones anteriores. Python 1 y Python 2 sí que eran retrocompatibles. Python 2 esta cerrado, ya. Solo Python 3 debería usarse hoy en día.

l

#11 Logica de dominio? Demonio?

#18 El 2 ya esta muy obsoleto y ya hay muchas complicaciones para seguir usandolo. Aunque si usas la librerias estandar puede que no tengas inconvenientes. Yo me resisti a cambiar al 3 y pero segun venian los inconvenientes, me fui convenciendos. Problemas con unicode, librerias que ya solo se hacian para P3 como Tablib, etc.
Para empezar el P2 te ahorra poner los parentesis en los print que se ponen mucho cuando empiezas y te ahorras poner muchos list, de cosas que en P3 han pasado a iteratorer/generadores ( que no se ejecutan hasta que le pides el dato)

El python en codigo se "compila" a un ,pyc, que seria como el bytecode de java compilado para ejecutarse sobre la maquina virtual.
No sé hasta que punto son diferentes.

RubiaDereBote

#11 No sé qué quieres decir con que el si el "script empieza a tener lógica de dominio" pero se intuye que si el script tiene lógica de dominio, el problema es mayor.

RubiaDereBote

#12 "Python es mas eficiente y facil" Bueno... eso de eficiente.....
"Bash es rapido, eficiente y facil de entender y manipular." Salvo si estás en entornos windows donde es más conveniente usar PowerShell

g

#22 Python es mucho más eficiente para manipular datos que bash, creo que no hay mucha discusión con eso la verdad.

Y el post habla de shellscripts en Linux, no se menciona a Windows en ningún momento.

Si estás en windows, Powershell si que permite manipular datos algo mejor que bash, porque es un lenguaje más moderno y ya tiene bastantes features "modernas" y puede, por poner un ejemplo tonto, parsear un JSON sin necesidad de herramientas externas.

Pero vamos, que si estás en Windows no tienes mucho que pensarte sobre qué lenguaje de scripting usar porque usas Powershell y te apaña el trabajo fácilmente.

RubiaDereBote

#27 "Python es mucho más eficiente para manipular datos que bash, creo que no hay mucha discusión con eso la verdad."
Yo discrepo, habría que ver qué datos concretamente, sin embargo estoy de acuerdo en no discutir sobre eso.

"Powershell si que permite manipular datos algo mejor que bash, porque es un lenguaje más moderno "
Que el lenguaje sea más moderno no es la justificación, pero bueno. De hecho en según qué casos ni siquiera es cierto que sea mejor que bash.

"parsear un JSON sin necesidad de herramientas externas."
Eso tampoco justifica nada. Yo prefiero usar una herramienta externa que ha sido programa en C y está impecablemente optimizada (incluso diseñada para la utilización de varios núcleos), que una herramienta que no sea externa y que a buen seguro no va a ser mejor que la que te digo.

avalancha971

Este es buenísimo:

If appropriate, change to the script’s directory close to the start of the script.

And it’s usually always appropriate.
Use cd "$(dirname "$0")", which works in most cases.


Cuántos problemas que nos hemos tirado horas en solucionar nos hemos comido por un script que alguien ejecutó estando en el directorio que no debía, sobre todo cuando en ese directorio no se tenían todos los permisos.

sauron34_1

#4 que se hace con cd "$(dirname "$0")" que sea diferente al simple cd dirname?

pax0r

#34 dirname es un comando de Linux

sauron34_1

#43 ah vale, veo que ese comando devuelve el directorio donde se encuentra el script, así que haciendo cd a ese comando vas al directorio del script. Perfecto!

D

#4 Más que cambiar de directorio en el script, prefiero guardar el directorio actual en una variable (con el dirname "$0") y usarla para convertir en absolutas las rutas de cualquier fichero auxiliar que acceda el script.

(Esto no aplica a las rutas relativas dadas por el usuario)

R

En UNIX muchas veces no tienes bash. Para hacer algo compatible con UNiX/Linux hay que tirar de sh. La mayoría de scripts sencillos son cambios sintácticos mínimos y tienes mayor compatibilidad.

h

#5 entiendo que el artículo va enfocado a sistemas unix y variantes.
Para windows, que yo sepa, bash tiene sus limitaciones. Guste o no, en este sistema está powershell.

llorencs

#15 habla de UNIX no de Windows. Entiendo que por ejemplo en BSD no encontrarás Bash. Si no me acuerdo de mi época de "FreeBSDero" la shell que usaba allí era "sh", que es la "shell" por defecto, no "bash".

R

#15 si, pero incluso en Un*x hay entornos sin bash (Bourne again shell), por ejemplo equipos AIX, HPUX... servidores en producción críticos que no puedes modificar casi nada y tienes que irte a otro shell. En mi experiencia el que mayor compatibilidad ofrece es sh (Bourne shell) pero también está más limitado.

Powershell también lo puedes tener en Linux pero yo no le veo aplicación práctica, en Unix ni me lo planteo. Si que he desarrollado algún script bash para Linux/Windows pero tampoco es algo que se suela hacer.

D

#24 Pues yo Powershell for linux/windows. Los scripts todos en powershell. Y funcionan en PC y LINUX.
Yo lo siento, pero no hay color.

h

#55 he hecho poco en powershell. Toda la vida con bash. Hace poco tenía que hacer consultas en Active Directory. Me planteé Python, pero por tema de dependencias y rapidez, opté por powershell. conozco poco de python y powershell.

D

>Bash.

No.


#55

>Powershell

Cáncer.

Segun necesidades.

sh+awk/sed -> Perl. Perl se folla a Powershell sin pensárselo dos veces.

d

#15 #24 #29 Powershell ni en pintura, gracias. Qué ganas Windows de intentar malcopiar e implantar sus variantes.

Bash para cositas sencillas. Perl (antiguamente) o Python (los últimos años para cualquier cosa más complicada)

Cuando no hay otra que manejar VMs en Windows: Ansible (exactamente lo mismo que usaría para manejar cualquier otra VM).

x

#15 Powershell lo tienes en plataformas Windows, Linux y MacOS.

Aitor

Interesante. Aunque lo veo más para un sub que para general.

frg

#64 Si, pero al final si quieres que funcione en todos toca usar sh, ya que es el que siempre está.

frg

#33 En el mundo hay más que lihux.

D

#40 Pero es peor que linux.

frg

#46 no

D

#54

n

#40 claro, está hurd, pero aun no anda fino... Es broma, pero ahora en serio: en cualquier sistema posix hay intérpretes mejores que sh, ya sea tcsh, zsh, etc.

pkreuzt

Just make the first line be #!/usr/bin/env bash

Esto suele dar problemas con los clásicos "compiladores" u ofuscadores que algunos usamos para los scripts. Conviene tenerlo en cuenta. En esos casos es mejor poner una ruta fija no dependiente de env.

poyeur

Yo suelo usar ksh, pero no sé exactamente las diferencias de sintaxis con bash 😅

llorencs

Python es bastante eficiente en eso. Y con cada versión el rendimiento mejora.

#_22 Para olicarca que me tiene ignorado...

D

Yo usaba KSH o perl, para cosa más complejas C, aunque es cierto que cuando empezó redhat a sustituir a solaris empezamos a usar bash. Ahora en Windows o powershell o python, alguna vez use bash para windows pero hace años y cosas muy sencillas.

La verdad es que lo más fácil es python. En java programé poco, solo unas cuantas navegaciones de selenium.

avalancha971

Yo me como bastantes scripts en tcsh, pero reconozco que sería buena práctica utilizar sólo bash.

frg

#3 La buena práctica es usar sh.

z

#13 /bin/sh suele ser un enlace simbólico a una shell, habitualmente dash (o también bash)

avalancha971

#13 Tienes razón, me despistó el punto Use the .sh (or .bash) extension for your file, y pensé que eran lo mismo.

D

Editado por spam

D

Editado por spam

F

Siempre he dicho que hay que aprender al menos 2 lenguas: inglés y bash.

D

Editado por spam