From a5801853e697e647b0dcf07c2456fe1104247c1a Mon Sep 17 00:00:00 2001 From: ivanhercaz Date: Wed, 18 Sep 2019 14:09:02 +0100 Subject: [PATCH 1/5] Begin the Spanish translation Introduction translated. --- translations/es.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 translations/es.rst diff --git a/translations/es.rst b/translations/es.rst new file mode 100644 index 0000000..c320573 --- /dev/null +++ b/translations/es.rst @@ -0,0 +1,17 @@ +Sustituyendo las secuencias de comandos en Bash con Python +========================================================== + +Si no cubro algo que te gustaría saber o encuentras otro problema, ¡repórtalo en github_! + +.. _github: + https://github.com/ninjaaron/replacing-bash-scripting-with-python + +.. contents:: + +Introduction +------------ +La línea de comandos de Unix es uno de mis inventos favoritos. Es genial, simple y llanamente. La idea idea es que el entorno del usuario sea un lenguaje de programación imperativo. Tiene un modelo muy simple para tratar con la entrada y salida (I/O), así como con la concurrencia, que en muchos otros lenguajes es notoriamente complicado. + +Para problemas en los que los datos pueden ser expresados como una transmisión de objetos similares separados por saltos de línea para ser procesados concurrentemente por medio de una serie de filtros y que maneja una gran cantidad de I/O, es difícil pensar en un lenguaje más idónea que no sea shell. Muchas de las partes del nucleo de un sistema Unix o Linux están diseñadas para expresar datos en estos formatos. + +¡Este tutorial NO es sobre cómo deshacerse de bash por completo! De hecho, uno de los principales objetivos de la sección `Interfaces de línea de comandos` es mostrar cómo escribir programas que se integren bien con las facultades de orquestación de procesos de la consola. From 1a34efd24c1ad7e84bce16a08249ada846ed4aed Mon Sep 17 00:00:00 2001 From: ivanhercaz Date: Wed, 18 Sep 2019 14:16:16 +0100 Subject: [PATCH 2/5] =?UTF-8?q?Change=20"consola"=20=C2=BB=20"Shell"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The text is talking about something specific, the Unix Shell, not any shell, so it shouldn't be translated. --- translations/es.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/translations/es.rst b/translations/es.rst index c320573..77a5e37 100644 --- a/translations/es.rst +++ b/translations/es.rst @@ -10,8 +10,8 @@ Si no cubro algo que te gustaría saber o encuentras otro problema, ¡repórtalo Introduction ------------ -La línea de comandos de Unix es uno de mis inventos favoritos. Es genial, simple y llanamente. La idea idea es que el entorno del usuario sea un lenguaje de programación imperativo. Tiene un modelo muy simple para tratar con la entrada y salida (I/O), así como con la concurrencia, que en muchos otros lenguajes es notoriamente complicado. +La Shell de Unix es uno de mis inventos favoritos. Es genial, simple y llanamente. La idea idea es que el entorno del usuario sea un lenguaje de programación imperativo. Tiene un modelo muy simple para tratar con la entrada y salida (I/O), así como con la concurrencia, que en muchos otros lenguajes es notoriamente complicado. Para problemas en los que los datos pueden ser expresados como una transmisión de objetos similares separados por saltos de línea para ser procesados concurrentemente por medio de una serie de filtros y que maneja una gran cantidad de I/O, es difícil pensar en un lenguaje más idónea que no sea shell. Muchas de las partes del nucleo de un sistema Unix o Linux están diseñadas para expresar datos en estos formatos. -¡Este tutorial NO es sobre cómo deshacerse de bash por completo! De hecho, uno de los principales objetivos de la sección `Interfaces de línea de comandos` es mostrar cómo escribir programas que se integren bien con las facultades de orquestación de procesos de la consola. +¡Este tutorial NO es sobre cómo deshacerse de bash por completo! De hecho, uno de los principales objetivos de la sección `Interfaces de línea de comandos` es mostrar cómo escribir programas que se integren bien con las facultades de orquestación de procesos de la Shell. From 215df26ed90c2d115febc47c12be28494dc86ec2 Mon Sep 17 00:00:00 2001 From: ivanhercaz Date: Wed, 18 Sep 2019 14:41:13 +0100 Subject: [PATCH 3/5] Translate first part of "If bash is..." section --- translations/es.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/translations/es.rst b/translations/es.rst index 77a5e37..218df40 100644 --- a/translations/es.rst +++ b/translations/es.rst @@ -15,3 +15,13 @@ La Shell de Unix es uno de mis inventos favoritos. Es genial, simple y llanament Para problemas en los que los datos pueden ser expresados como una transmisión de objetos similares separados por saltos de línea para ser procesados concurrentemente por medio de una serie de filtros y que maneja una gran cantidad de I/O, es difícil pensar en un lenguaje más idónea que no sea shell. Muchas de las partes del nucleo de un sistema Unix o Linux están diseñadas para expresar datos en estos formatos. ¡Este tutorial NO es sobre cómo deshacerse de bash por completo! De hecho, uno de los principales objetivos de la sección `Interfaces de línea de comandos` es mostrar cómo escribir programas que se integren bien con las facultades de orquestación de procesos de la Shell. + +Si la Shell es tan genial, ¿cuál es el problema? +++++++++++++++++++++++++++++++++++++++++++++++++ +El problema es que si quieres hacer básicamente cualquier otra cosa, por ej. escribir lógica, usar estructuras de control, manejar datos, etc., vas a tener complicaciones. Cuando Bash está coordinando programas externos, es fantástico. Cuando está haciendo cualquier trabajo por sí mismo, se desintegra en una pila de basura. + +Para mí el problema fundamental con Bash y muchos dialectos de Shell es que el texto son identificadores y los identificadore son texto -- y básicamete todo lo demás también es texto, que teóricamente significa que puede tener una interesante historia de metaprogramación, hasta que te das cuenta de que básicamente equivale a ejecutar muchos ``eval`` en cadenas, que es una característica que está presente en prácticamente cualquier lenguaje interpretado de hoy en día, y que frecuentemente se considera dañina. El problema con ``eval`` es que es una ruta bonita y directa para la ejecución de código arbitrario. Esto está genial si tu objetivo es ejecutar código arbitrario (como, por ejemplo, en un motor de plantillas HTML). Pero no es lo que generalmente quieres. + +Bash básicamente se basa en evaluar todo. Esto es muy práctico para el uso interactivo, ya que reduce la necesidad de mucha sintaxis explícita cuando lo que realmente quieres hacer es decirle que abra un archivo en un editor de texto. Esto es bastante malo en un contexto interpretativo porque convierte todo el lenguaje en una inyección *honeypot*. Sí, esto es posible y no es muy complicado escribir un Bash seguro una vez conoces los trucos, pero esto requiere una consideración extra que es fácil de olvidar o tener pereza al respecto. Escribir tres o cuatro línea de Bash seguro es sencillo; doscientas es un poco más desafiante. + + From 786f4cdc6b56e360b8ded1abe573bb3539cbaa07 Mon Sep 17 00:00:00 2001 From: ivanhercaz Date: Wed, 18 Sep 2019 15:02:46 +0100 Subject: [PATCH 4/5] Add explanation about the need of interpolation --- translations/es.rst | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/translations/es.rst b/translations/es.rst index 218df40..3738678 100644 --- a/translations/es.rst +++ b/translations/es.rst @@ -24,4 +24,27 @@ Para mí el problema fundamental con Bash y muchos dialectos de Shell es que el Bash básicamente se basa en evaluar todo. Esto es muy práctico para el uso interactivo, ya que reduce la necesidad de mucha sintaxis explícita cuando lo que realmente quieres hacer es decirle que abra un archivo en un editor de texto. Esto es bastante malo en un contexto interpretativo porque convierte todo el lenguaje en una inyección *honeypot*. Sí, esto es posible y no es muy complicado escribir un Bash seguro una vez conoces los trucos, pero esto requiere una consideración extra que es fácil de olvidar o tener pereza al respecto. Escribir tres o cuatro línea de Bash seguro es sencillo; doscientas es un poco más desafiante. +Bash tiene otros problemas. La sintaxis que no es nativa de la Bourne Shell se ve realmente fea. Por ejemplo, las líneas de comando (*shells*) más modernas tienen *arrays* (en español, vectores o arreglos). Vamos a revisar la sintaxis para iterar un array, pero vamos a tomar el camino largo. + +.. code:: bash + + $ foo='esto y aquello' # asignación de variable + $ echo $foo + esto y aquello + $ # Oh cielos. El texto dentro de la variable fue dividido en argumentos en espapacio en blanco, porque evalua todas las cosas. + $ + $ # Para evitar este comportamiento insano, hacemos lo siguiente: usamos una interpolación de cadena. :-( + $ echo "$foo" + esto y aquello + +¿Qué tiene esto que ver con iterar los arrays? Desafortunadamente la respuesta es «algo». + +Para iterar correctamente en las cadenas dentro de un array (lo único que puede contener un array), también usas la sintaxis de interpolación de variables. + +.. code:: bash + + for elemento in "${mi_array[@]}"; do + cosas que hacer con "$elemento" + done + From 79e2830c88e167a44c9e4063407f49bc758b44ba Mon Sep 17 00:00:00 2001 From: ivanhercaz Date: Wed, 25 Sep 2019 12:19:42 +0100 Subject: [PATCH 5/5] Rename the "translations" directory to "langs" According to the comment by @ninjaaron in #3 the folder with the guide in another languages has been renamed. --- {translations => langs}/es.rst | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename {translations => langs}/es.rst (100%) diff --git a/translations/es.rst b/langs/es.rst similarity index 100% rename from translations/es.rst rename to langs/es.rst