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

#!/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, obtuve 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 cambié 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?

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

En cuanto al “por qué”, eso se debe a que las diversas formas de hacerlo mal tienen significados válidos como comandos. Si hiciera 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 ubicarse en un espacio indefinido (donde las extensiones de la norma POSIX sh necesitan vivir para evitar constituir violaciones de esa norma).

 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 

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

De la documentación

“Cada operador y operando debe ser un argumento separado”.

La asignación de variables es diferente y usa este name=[value] syntax 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.

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

Las secuencias de comandos de Shell permiten, en muchos casos, simplemente no presupuestar cadenas (siempre que una secuencia de caracteres destinada a ser una sola cadena no contenga espaciado ni caracteres especiales). Gracias a esto, puedes escribir:

  my_command -n -X arg1 arg2 

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

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

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

La syntax de Shell proporciona comodidad en casos frecuentes, a costa de, bueno, menos comodidad (y legibilidad) cuando se hacen otras cosas. Es a la vez una maldición y una bendición. Lo bueno es saber que si tienes un intérprete interactivo, puedes estar 100% seguro de que tienes un intérprete que se encargará de algún tipo de progtwig (quizás poco elegante). Debido a su disponibilidad universal (a pesar de que existen varios sabores), el caparazón es un tipo de plataforma que es lo suficientemente útil como para valer la pena aprender.