Conceptos básicos de la automatización y secuencias de comandos de Bash (Parte 2)


Shutterstock / Mopic

Bash es un lenguaje de codificación y shell ideal, que le permite crear scripts de automatización de alta gama. En esta segunda parte de la serie, veremos la densidad de codificación, los comentarios en línea y las comillas de variables correctas utilizando comillas simples o dobles.

Conceptos básicos de automatización y scripting Bash

Si aún no lo ha hecho, y recién está comenzando con Bash, lea nuestro artículo Bash Automation and Scripting Basics Part 1. Este es el segundo artículo de nuestra serie de tres partes sobre Bash Automation and Scripting Basics. En el artículo de hoy examinaremos, entre otros temas, la densidad del código de Bash y su conexión con las preferencias de los desarrolladores. También revisaremos los comentarios en línea en relación con esto.

Una vez que comenzamos a crear pequeños scripts, exploramos variables y trabajamos con cadenas de texto, rápidamente nos damos cuenta de que puede haber una diferencia conceptual entre comillas simples y dobles. La hay, y en el segundo tema a continuación nos sumergiremos en eso.

Densidad y concisión de la codificación Bash

El lenguaje de codificación Bash puede ser muy denso y conciso, pero también puede ser espacioso y detallado. Depende en gran medida de las preferencias del desarrollador.

Por ejemplo, el siguiente código Bash:

true || echo 'untrue'

Que se puede leer como No haga nada y hágalo con éxito (código de salida 0), y si eso falla (puede leer el modismo Bash || como OR) devuelve el texto "falso", también se puede escribir como:

if [ ! true ]; then
  echo 'untrue'
fi

Lo que hace que el código sea ligeramente diferente, pero básicamente hace lo mismo.

Esto a su vez puede leerse como Si es cierto, no lo es (indicado por ! idiom) true, luego devuelve el texto "false".

Dos formas de programar en Bash;  misma funcionalidad, código bastante diferente

Ambos mini-scripts producen la misma salida vacía, como cierto No lo es falso.

La multitud de comandos y herramientas disponibles (o instalables) desde y desde la línea de comandos aumenta aún más el posible desplazamiento entre scripts altamente legibles y código denso, conciso y difícil de entender.

Mientras que los ejemplos anteriores son breves y relativamente fáciles de entender, cuando crea una línea larga (un término que los desarrolladores de Bash suelen usar para referirse a un fragmento de código, compuesto de varios comandos, escritos en una sola línea) empleando muchos de estos comandos, en comparación con poner el mismo en un script más detallado, la diferencia se vuelve más clara. Considerando:

V="$(sleep 2 & fg; echo -n '1' | sed 's|[0-9]|a|')" && echo "${V}" | sed 's|[a-z]|2|g' || echo 'fail'

Un ejemplo complejo de un delineador

Este es un script típico de Bash de una línea que usa comandos sleep, fg, echo, es sed así como varios modismos Bash y expresiones regulares para dormir básicamente 2 segundos, producir texto y transformar este texto usando expresiones regulares. El script también verifica regularmente las condiciones / resultados de comandos anteriores usando modismos Bash || (si no tiene éxito, haga lo siguiente) es && (si tiene éxito, haga lo siguiente)

Lo he traducido, con la funcionalidad de coincidencia aproximada, a un script más completo, con algunas modificaciones. Por ejemplo, intercambiamos el nuestro fg (trae el sleep comando colocado en segundo plano nuevamente en primer plano y esperar a que termine como procesos normales sin segundo plano) a wait que esperará el PID de suspensión (iniciado por eval y capturado usando el idioma Bash $!) fin.

#!/bin/bash

CMD="sleep 2"
eval ${CMD} &
wait $!
EXIT_CODE=${?}

V="$(echo -e "${CMD}n1" | sed 's|[0-9]|a|')"

if [ ${EXIT_CODE} -eq 0 ]; then
  echo "${V}" | sed 's|[a-z]|2|g'
  EXIT_CODE=${?}
  if [ ${EXIT_CODE} -ne 0 ]; then
    echo 'fail'
  fi
fi

El mismo complejo en línea en un guión completo en su lugar

¡Una gran diferencia! Y esto es correcto uno desarrollador que lo escribe su camino. El código Bash escrito por otros tiende a ser un poco difícil de leer, y esa dificultad aumenta rápidamente con la densidad y la concisión. Sin embargo, un desarrollador de Bash experimentado comprenderá rápidamente incluso el código muy denso y conciso escrito por otros, con algunas excepciones, como las expresiones regulares.

Para obtener más información sobre cómo escribir expresiones regulares, consulte Cómo editar texto usando expresiones regulares con sed Stream Editor.

A partir de estos ejemplos, queda claro que su kilometraje variará con el tiempo. Sin embargo, en general, se recomienda la facilidad de uso del codificador de pares (escribir código altamente legible) siempre que comience a desarrollar scripts Bash.

Si necesita crear un código denso y conciso, puede proporcionar muchos comentarios en línea. Una línea precedida por un # se considera una línea de comentario / anotación y el símbolo # también se puede usar hacia el final de una línea después de cualquier comando ejecutable, para insertar un comentario de sufijo que explique el comando, una declaración condicional, etc. Por ejemplo:

# This code will sleep one second, twice
sleep 1  # First sleep
sleep 1  # Second sleep

¿Comillas simples o dobles?

En Bash, el texto entre comillas simples (') son tomados como texto literal por el intérprete de Bash, mientras que el texto entre comillas (") es interpretado (analizado) por el intérprete de Bash. Si bien la diferencia en cómo funcionan las cosas puede no quedar clara de inmediato a partir de esta definición, el siguiente ejemplo nos muestra lo que sucede cuando intercambiamos ' por " y viceversa:

echo ' $(echo "Hello world") '
echo " $(echo 'Hello world') "

Comillas simples versus comillas dobles en Bash en un ejemplo de Hello World

En el primer ejemplo, el texto $(echo "Hello world") se ve como texto literal, por lo que la salida es simplemente $(echo "Hello world") . Para el segundo ejemplo, sin embargo, la salida es Hello world .

El intérprete de Bash escaneó el texto citado para ver si encontraba algún modismo especial de Bash en el que actuar. Uno de esos modismos se encontró en $( ... ) que básicamente inicia una subcapa y ejecuta lo que esté en los archivos ( ... ) modismos. Piense en ello como un shell dentro de un shell, un subshell, que ejecuta todo lo que le pasa como un comando completamente nuevo. La salida de uno o más de estos comandos se pasa de nuevo al shell de nivel superior y se coloca en el punto exacto donde se inició el subshell.

Entonces, nuestra subcapa estaba lista echo 'Hello world' de los cuales la salida es Hello world. Una vez hecho esto, la subcapa está terminada y el texto Hello world se insertó en lugar del archivo $( ... ) invocación de subcapa (piense en ello como todo $( ... ) el código se reemplaza por cualquier salida generada por el subshell.

El resultado, para el shell superior, es el siguiente comando: echo " Hello world ", de los cuales la salida es Hello world como hemos visto.

Tenga en cuenta que hemos cambiado las comillas dobles dentro de la subcapa a comillas simples. ¡Esto no es necesario! Esperaría ver un error de análisis cuando un comando adopta la sintaxis de echo " ... " ... " ... ", ya que las segundas comillas dobles terminarían con la primera, seguidas de más pruebas y, por tanto, provocarían un error. Sin embargo, éste no es el caso.

Y esto no se debe a que Bash sea flexible con cadenas con múltiples comillas (acepta echo 'test'"More test"'test' felizmente, por ejemplo), pero dado que el subshell es un shell en sí mismo y, por lo tanto, se pueden usar comillas dobles, una vez más, dentro del subshell. Probémoslo con otro ejemplo:

echo "$(echo "$(echo "more double quotes")")"

Bash acepta fácilmente comillas dobles repetidas dentro de una subcapa

Esto funcionará bien y producirá la salida. more double quotes. Las dos subcapas anidadas (que se ejecutan dentro del shell principal desde el que se realiza la operación) aceptan comillas dobles a su vez y no se arrojan errores, incluso si se anidan varias comillas dobles en el comando de una línea. Esto muestra parte del poder de programación de Bash.

En resumen

Después de explorar la densidad de codificación, nos damos cuenta del valor de escribir código altamente legible. Si aún necesitamos crear un código denso y conciso, podemos agregar muchos comentarios en línea usando # para facilitar la legibilidad. Observamos las comillas simples y dobles y cómo su funcionalidad difiere sustancialmente. También analizamos brevemente los comentarios en línea en los scripts, así como la funcionalidad de la subcapa cuando se ejecuta desde una cadena entre comillas dobles. Finalmente, vimos cómo una subcapa puede usar otro conjunto de comillas dobles sin afectar de ninguna manera las comillas dobles utilizadas en un nivel superior. ¡Estén atentos a la parte 3!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Subir