lunes, 8 de febrero de 2021

scripts en Bash... para torpes (II)

Tras el Preámbulo (a modo de Introducción) de 'scripts en Bash... para torpes (I) ahora me toca meter otro rollito teórico sobre conceptos genéricos, principalmente sobre ‘scripts’. Algunos son muy simples, pero había que ponerlos, por aquello de seguir estructurando ideas.
Así que...
2- Conceptos básicos


¿Qué es la shell?
La shell es, sencillamente, el ‘intérprete de comandos’, la interfaz que permite enviar comandos (instrucciones) al sistema operativo, ya sea en forma de una orden individual, o ya sea el forma de un archivo (llamado script) que contiene una serie de instrucciones a realizar, para que sean ejecutadas automáticamente por dicho sistema operativo. Y la shell se materializa en el terminal, o consola.
¿Y qué es un script?
Pues lo dicho, un script no es más que una serie de comandos que (escritos en un archivo de texto plano, y con un identificador que permita conocer para qué intérprete de comandos está creado) se le proporcionan a un sistema para que esa shell los interprete y los ejecute.
¿Qué es el ‘shebang’?
No nos asustemos, será difícil volver a encontrarnos con esta palabreja, pero se llama así al encabezamiento
#!/bin/bash
que llevan los script (en este caso, los scripts en Bash, cuya extensión suele ser *.sh), para que las líneas de ese archivo de texto sean interpretadas (y ejecutadas) según el intérprete de comandos indicado, como órdenes del script (o como simple comentario, o texto).

También suele usarse
#!/usr/bin/env bash
que, al parecer, asegura ‘una mejor portabilidad’

Por ejemplo, los scripts en python (cuya extensión el *.py) tienen el shebang
#!/usr/bin/python (o bien #!/usr/bin/env python)
Por cierto, y como inciso, deberemos saber que, a lo largo del desarrollo del script, el simbolo almohadilla (#) delante de una línea de texto indica al intérprete que la debe considerar como ‘comentario’ y no como ‘orden’. (Es una forma sencilla de añadir notas aclaratorias e indicar al sistema que ‘esto no lo uses’, en realidad es una norma general, aplicable a todos los textos que se tengan que procesar. Por poner un ejemplo sencillo, lo verás en el archivo de los repositorios activos, o sea el /etc/apt/sources.list

¿Qué es una cadena?
La cadena (en inglés, string) es un concepto complejo pero, por aclarar, porque a veces aparece esa palabreja, podríamos entenderlo como un conjunto de caracteres, o palabras (una secuencia de números, un texto, unos comandos…) que deben considerarse como de una misma ‘unidad de acción’. Por eso hay que ponerlas, como mínimo, entre comillas. Muchas veces (porque es mucho más cómodo, y productivo) la cadena puede sustituirse por una variable, una función o, en el caso que sea una relación de cosas, o un rango de números, etc, por un ‘array’ (que es una lista, o matriz) que los contiene,. Es lo que se llama ‘declarar’ (la variable, la función, el array…). Pero dejémoslo aquí.
¿Cómo se crea y guarda un script?
El script se crea con cualquier editor de textos (los expertos usan emac, o vim, pero no merece la pena, vale el más sencillo que tengas instalado en tu distro (gedit, o similar).
Y este pequeño archivo de texto es cómodo guardarlo, con un nombre apropiado, en la ruta ‘por defecto’ del terminal (o consola). O sea, donde se te abre, vamos, que normalmente es en el directorio raiz de tu /home.
Puedes distinguirlos con la extensión *.sh aunque, personalmente, yo los suelo guardar como ‘script_nombre_identificativo’, y normalmente sin extensión. Así me aparecen todos juntos.
Por poner un primer ejemplo...
#!/bin/bash
sudo aptitude update && sudo aptitude safe-upgrade
gedit /var/log/aptitude +8000:1

es un script que yo llamo ‘script_actualizar’ (y que, por cierto, me resulta muy útil)

Los permisos de ejecución del script
Antes de ejecutar cualquier script es necesario (bueno... solo conveniente) darle permisos de ejecución. Este permiso se da con el comando:
chmod +x <nombre del archivo>
donde sustituiremos ‘x’ por los permisos (de lectura, escritura y ejecución) correspondientes.
Por esta vía (teórica), verlo aquí,
Aunque si vamos por la vía práctica es mucho más cómodo hacerlo, gráficamente, seleccionado el script, con botón derecho ratón-Propiedades-Permisos (y habilitar el ‘Permiso de ejecución como programa')

¿Como se ejecuta un script?
Para ejecutar un script, si ya le has asignado permiso de ejecución, basta abrir una consola en la ruta donde está el script y escribir
./nombre_script
(a veces se ve...~/nombre_script)
en cuyo caso el sistema identifica automáticamente, a partir del shebang, el intérprete de comandos que necesita y lo pasa ‘como argumento del propio shell, o intérprete invocado’.
De todas formas, tampoco es del todo necesario tener que otorgar permisos de ejecución sobre el script, porque si los ejecutamos con la orden (por consola).
sh nombre_script
arrancan perfectamente. Es lo que, personalmente, suelo usar, y también va muy bien con ‘bash nombre_script’, ya que lo que hacemos es decirle que se ejecute el intérprete indicado por el usuario, e introducimos como 'argumento' el archivo que se desea ejecutar, creándose, en realidad, una nueva instancia de Bash en una nueva shell
.
(En todo caso, tampoco cuesta nada darle los permisos de usuario, con lo de 'habilitar permiso de ejecución como programa')


Y acabo con unos consejos básicos
En Programación se usan muchas expresiones (‘cadenas’) entrecomilladas, y hay comillas simples, dobles comillas, comillas invertidas, así como también hay paréntesis ( ), corchetes [ ], claves { } (que algunos llaman paréntesis curvos)…
Una regla de oro: mucha atención con todos estos signos.
E, igualmente, muchísimo cuidado con los espacios en blanco, que el dejar un espacio, o no dejarlo, cambia todo. En realidad (un poco de teoría) el espacio en blanco es, por defecto, el IFS (Input Field Separator), que es una variable global del sistema. Ocurre, muchas veces, que equivocaciones o fallos tontos con estas cosas hacen que un script, o programa, no funcione, o de error.
Ciertamente, cada signo tiene ‘su por qué’, de hecho, por ejemplo, abrir un paréntesis (normal) es crear una subcapa (o sea, una ‘burbuja’), y lo que ‘pasa dentro’ es un sola unidad de acción (que pierde vigencia a partir del paréntesis de cierre), mientras que si se abre una clave {el paréntesis curvo que hablaba entes} se trabaja en entorno de shell y puede contener varias unidades de acción, separadas por un punto y coma (o por nueva línea). Pero no quiero meterme en honduras…

Y atención con las comillas: cada una tiene su función:
Las ‘comillas simples’ son eso, simples: se limitan a indicar que se considere del mismo conjunto exactamente lo que contienen.
Y las “comillas dobles” también lo indican, pero además interpretándolo. Un ejemplo lo aclara todo: la orden… echo ‘Este programa se llama $0’, con comillas simples, haría que aparezca en la consola, literalmente, esta frase. Pero si el argumento se introduce con doble entrecomillado: echo “Este programa se llama $0” Bash interpreta que $0 es una variable (luego lo veremos), y pondrá lo que significa, en realidad, esa variable (que es ‘el nombre del programa’).
Y las comillas invertidas, que se forman con ‘tecla a la derecha de P y barra espaciadora’: ` así ` (por cierto, como mejor se ven las cosas es usando un tipo de letra ‘monospace’, como la DejaVu Sans Mono)... son las más potentes: se utilizan con órdenes, y se sustituyen por la salida del programa que está entre las comillas invertidas.


Y, finalmente, una percepción personal: atención a las comillas dobles.
Parece ser que las hay de dos tipos: las "rectas", y las “tipográficas”, o inglesas (que son las que salen, por defecto, en libreoffice). Al parecer, el intérprete de comandos acepta las rectas (son las que salen si las tecleas directamente por consola, o en los editores sencillos, como gedit) pero no las tipográficas.
Así que si escribes
un texto entrecomillado usando el libreoffice (como suelo hacer yo, para este Blog) y luego lo copias y pegas al terminal, dentro de una orden… a mi me da, en general, error.
No veo la forma de tenerlas también por defecto, en Libreoffice y eso que, al parecer las que ofrece Libreoffice corresponden al código Unicode u+22 y las rectas al u+2033. (Recuerda que un código Unicode aparece si escribes
u y su número mientras mantienes pulsadas las teclas Mayusc y Ctrl).
Claro, un programador profesional, que trabaja directamente sobre el editor Vim, o sobre el emacs, (o en el mismo gedit, claro) etc, no tiene este problema...

Ir al Sumario (del tema)

 

No hay comentarios:

Publicar un comentario