¿Por qué un espacio en una asignación variable da un error en Bash?

variables variable-assignment

Question

Esta pregunta ya tiene una respuesta aquí:

• Asignación de variables con espacio después del signo (=)? 3 respuestas

#!/bin/bash

declare -r NUM1=5
NUM2 =4                # Line 4

num3=$((NUM1 + NUM2))
num4=$((NUM1 - NUM2))
num5=$((NUM1 * NUM2))
num6=$((NUM1 / NUM2))  # Line 9

echo "$num3"
echo $((5**2))
echo $((5%4)) 

Estoy usando este script bash, y cuando estaba ejecutando el script, recibí el error

./bash_help 
./bash_help: line 4: NUM2: command not found
./bash_help: line 9: NUM1 / NUM2: division by 0 (error token is "NUM2")
5
25
1

Así que he cambiado el código a esto y el error desapareció.

#!/bin/bash

declare -r NUM1=5
NUM2=4

num3=$((NUM1 + NUM2))
num4=$((NUM1 - NUM2))
num5=$((NUM1 * NUM2))
num6=$((NUM1 / NUM2))

echo "$num3"
echo $((5**2))
echo $((5%4)) 

¿Por qué no podemos usar espacios cuando asignamos un valor a una variable? Es una convención usar espacios para una mejor legibilidad del código. ¿Alguien puede explicar esto?

Answer 1

En Bash, las funciones son argumentos pasados ​​como palabras separadas por espacios en blanco.

De la documentación

"Cada operador y operando debe ser un argumento separado".

La asignación de variables es diferente y utiliza esta sintaxis name=[value]

La razón por la que no puede poner espacios sin comillas alrededor del signo igual es porque bash interpretaría esto como un comando.

Answer 2

La razón es, simplemente, que el shell está diseñado para comportarse así. Puede que no tenga sentido para alguien con experiencia en otros lenguajes de programación (si llama a la sintaxis de shell un "lenguaje", que en cierto sentido lo es).

La secuencia de comandos de shell hace posible en muchos casos simplemente no citar cadenas (siempre y cuando una secuencia de caracteres destinada a ser una sola cadena no contenga ningún espacio o caracteres especiales). Gracias a esto, puedes escribir:

 my_command -n -X arg1 arg2

En lugar de (en algún tipo de pseudocódigo imaginario)

 "my_command" "-n" "-X" "arg1" "arg2"

En la mayoría de los idiomas, es al revés: se citan cadenas literales, lo que libera "espacio de sintaxis" para usar variables sin ningún carácter especial (como $ en el script de shell).

La sintaxis de Shell proporciona conveniencia en casos frecuentes, a costa de, bueno, menos conveniencia (y legibilidad) al hacer otras cosas. Es a la vez una maldición y una bendición. Lo bueno es saber que si tienes un shell interactivo, puedes estar 100% seguro de que tienes un intérprete que manejará algún tipo de programa (quizás poco elegante). Debido a su disponibilidad universal (a pesar de que existen varios sabores), el shell es un tipo de plataforma que es lo suficientemente útil como para que valga la pena aprenderlo.

Answer 3

No es una convención en bash (o, más generalmente, shells de la familia POSIX).

En cuanto a "por qué", eso se debe a que las diversas formas de hacerlo mal tienen significados válidos como comandos. Si hizo NUM2 = 4 una asignación, entonces no podría pasar = como un argumento literal sin citarlo. En consecuencia, cualquier cambio de este tipo sería incompatible con versiones anteriores , en lugar de colocarse en un espacio indefinido (donde las extensiones al estándar POSIX sh deben vivir para evitar constituir violaciones de ese estándar).

NUM2= 4 # runs "4" as a command, with the environment variable NUM2 set to an empty string
NUM2 =4 # runs "NUM2" as a command, with "=4" as its argument
NUM2 = 4 # runs "NUM2" as a command, with "=" as its first argument, and "4" as another