¿Cuándo están prohibidos los espacios alrededor del signo =?

9

Sé que en ~ / .bashrc uno no debe poner espacios alrededor de los =signos en la asignación:

$ tail -n2 ~/.bashrc 
alias a="echo 'You hit a!'"
alias b = "echo 'You hit b!'"

$ a
You hit a!

$ b
b: command not found

Estoy revisando el archivo de configuración de MySQL /etc/my.cnfy he encontrado esto:

tmpdir=/mnt/ramdisk
key_buffer_size = 1024M
innodb_buffer_pool_size = 512M
query_cache_size=16M

¿Cómo puedo verificar que los espacios alrededor de los =letreros no sean un problema?

Tenga en cuenta que esta pregunta no es específica del /etc/my.cnfarchivo, sino más bien de los archivos de configuración * NIX en general. Mi primera inclinación es RTFM, pero de hecho man mysqlno menciona el problema y si necesito ir a buscar en línea para cada caso, nunca llegaré a ningún lado. ¿Hay alguna convención o una forma fácil de verificar? Como se puede ver, varias personas han editado este archivo (diferentes convenciones para los =signos) y no puedo forzarlos a que no usen espacios, ni puedo volverme loco comprobando todo lo que puede haber sido configurado y puede o no ser correcto.

EDITAR: Mi intención es asegurar que los archivos configurados actualmente se realicen correctamente. Al configurar archivos yo mismo, sigo la convención de lo que sea que haya puesto el mantenedor de paquetes allí.

dotancohen
fuente
2
No existe tal cosa como "* NIX archivos de configuración en general". Si quiero permitir espacios en mi archivo de configuración, escribiré mi programa para permitirlos. Si quiero que mi archivo de configuración use dos puntos o tuberías en lugar de signos iguales, entonces escribiré mi programa para usarlos. Bash no requiere espacios. Mysql les permite.
hymie

Respuestas:

3

Contestaré eso de una manera más general , observando un poco toda la " experiencia de aprendizaje de Unix ".

En su ejemplo, usa dos herramientas y ve que el idioma es similar. Simplemente no está claro cuándo usar qué exactamente. Por supuesto, puede esperar que haya una estructura clara , por lo que nos pide que le expliquemos eso.
El caso con el espacio alrededor =es solo y un ejemplo: hay muchos casos similares, pero bastante aburridos.
No tiene que haber una lógica en ella, ¿verdad ?!

Las reglas sobre cómo escribir código para alguna herramienta , shell, base de datos, etc. solo dependen de lo que requiera esta herramienta en particular .

Eso significa que las herramientas son completamente independientes , técnicamente. La relación lógica que creo que esperas simplemente no existe .

La similitud obvia de los lenguajes que está viendo no forma parte de la implementación del programa . La similitud existe porque los desarrolladores habían acordado cómo hacerlo cuando lo escribieron para un programa en particular. Pero los humanos solo pueden estar de acuerdo parcialmente .

La relación que está viendo es una cultura cosa - es ni parte de la aplicación , ni en la definición de la lengua .



Entonces, ahora que hemos manejado la teoría, ¿qué hacer en la práctica?

Un gran paso es aceptar que la consistencia que esperaba no existe , lo que es mucho más fácil al comprender las razones , espero que la parte de la teoría ayude con esto.

Si tiene dos herramientas que no usan el mismo lenguaje de configuración (por ejemplo, ambos scripts de bash), conocer los detalles de la sintaxis de uno no ayuda mucho a comprender el otro;
Entonces, de hecho, tendrá que buscar detalles de forma independiente . Asegúrese de saber dónde encuentra la documentación de referencia para cada uno.

En el lado positivo, hay cierta coherencia donde no lo esperaba: en el contexto de una sola herramienta (o diferentes herramientas que usan el mismo lenguaje), puede estar bastante seguro de que la sintaxis es coherente.
En su mysqlejemplo, eso significa que puede suponer que todas las líneas tienen la misma regla. Entonces la regla es "el espacio antes y después no= es relevante ".

Existen grandes diferencias en lo difícil que es aprender o usar el lenguaje de configuración o scripting de una herramienta.
Puede ser algo así como " Listar valores foo en cmd-foo.conf, uno por línea".
Puede ser un lenguaje de script completo que también se usa en otros lugares. Entonces tiene una herramienta poderosa para escribir la configuración, y en algunos casos eso es bueno, en otros realmente lo necesitará.
Las herramientas complejas o las grandes familias de herramientas relacionadas a veces solo usan una sintaxis de archivo de configuración especial muy compleja (algunos ejemplos famosos son sendmaily vim).
Otros usan una secuencia de comandos generalidioma como base, y extienda ese idioma para satisfacer las necesidades especiales , algunas veces de manera compleja, según lo permita el idioma. Ese sería un caso muy específico de un lenguaje específico de dominio ( DSL ) .

Volker Siegel
fuente
Aceptada como esta es la respuesta que más aborda la respuesta desde el punto de vista de la pregunta. ¡Gracias!
dotancohen
20

Bash interpretará una línea que tiene texto seguido de a =como una asignación a una variable, pero interpretará una línea que tiene texto seguido de un espacio como un comando con un argumento.

var=assignment vs command =argument

Las secuencias de comandos Bash funcionan según el principio de que todo en la secuencia de comandos es como si lo hubiera escrito en la línea de comandos.

En los archivos de configuración que no son interpretados por bash(u otro shell), será determinado por el analizador que se utiliza para leer el archivo de configuración. Algunos analizadores ocuparán espacios, otros no. Depende de la aplicación en ese caso. Personalmente, voy con cualquier convención que haya utilizado el archivo de configuración predeterminado.

Lawrence
fuente
Gracias. Me preocupa cómo verificar los archivos existentes, ahora y en el futuro, que pueden haber sido configurados por otros tipos de desarrolladores. Cuando configuro archivos yo mismo, sigo la convención de lo que sea que haya puesto el mantenedor del paquete, como usted sugiere. He editado la pregunta para aclarar.
dotancohen
1
Supongo que si está verificando archivos existentes, verificaría la documentación del producto y lo usaría como ejemplo. Suponiendo que tiene documentación y no es una aplicación personalizada. Si se tratara de una aplicación personalizada, me quedaría con lo que ya estaba allí. "Si no está roto, no lo arregles"
Lawrence
Lamentablemente, algunos de ellos están en quiebra. ¡Por eso estoy preguntando!
dotancohen
En las conchas, nunca use espacios alrededor de un igual. En cualquier cosa que no sea un caparazón, use siempre espacios. Puede auditar archivos existentes utilizando grep: 'grep "[^] = [^]" / etc / *' para buscar archivos con un = que no tenga espacios.
qris
2
@dotancohen (1.) Para cualquier archivo de configuración, debe haber al menos una configuración que sería bastante fácil verificar si está roto. Ya sea que un archivo de configuración permita espacios o no, debe hacerlo de manera consistente en todo momento. (2.) Siempre puede descargar una aplicación y verificar las configuraciones predeterminadas con las que se envía. (3.) Siempre puedes omitir espacios por completo. a = bPuede que no siempre sea aceptable, pero a=bsiempre debería funcionar.
Alquimista de dos bits
4

.bashrc no es más que un archivo de configuración para bash, al igual que my.cnf, php.ini, httpd.conf o launchd plist. Cada uno tiene su propia sintaxis, que va desde la asignación sin espacio de bash a la sopa de etiquetas XML de launchd (también hay una versión binaria: -O)

No existen convenciones firmes, y ya ha descubierto la Directiva principal de Unix: lea el manual de Fine .

Pablo
fuente
1
.bashrcno es un archivo de configuración para bash. .bashrces un script de shell que bash se ejecuta cada vez que se inicia un proceso de bash. Se puede usar para configurar bash, pero también se puede usar para hacer todo tipo de otras cosas: es un script, no un archivo de configuración.
Josh
3

Algunos programas ofrecen una comprobación del archivo de configuración, por ejemplo:

postfix check

De lo contrario, podría obtener los archivos de configuración originales de los repositorios y compararlos con diff con los actuales.

usuario78568
fuente
En realidad, esto parece que realmente aborda el problema central. ¡Gracias!
dotancohen
2

Los espacios alrededor del =signo siempre son un problema cuando haces una tarea bash. Aquí no hay ninguna excepción, debe eliminar todos los espacios alrededor =si desea obtener una asignación simple válida (sin expansión, sin aritmética, sin asignación de matriz) en bash.

Para el archivo de configuración, debido a que cada software tiene su propio analizador para analizar su archivo de configuración, bashno tiene relación. Debe leer la documentación para saber qué sintaxis está permitida en el archivo de configuración.

Un ejemplo es que mysql, en su script de inicio /etc/init.d/mysqld, tiene un analizador para my.cnf:

# Try to find basedir in /etc/my.cnf
  conf=/etc/my.cnf
  print_defaults=
  if test -r $conf
  then
    subpat='^[^=]*basedir[^=]*=\(.*\)$'
    dirs=`sed -e "/$subpat/!d" -e 's//\1/' $conf`
    for d in $dirs
    do
      d=`echo $d | sed -e 's/[  ]//g'`
      if test -x "$d/bin/my_print_defaults"
      then
        print_defaults="$d/bin/my_print_defaults"
        break
      fi
      if test -x "$d/bin/mysql_print_defaults"
      then
        print_defaults="$d/bin/mysql_print_defaults"
        break
      fi
    done
  fi
Cuonglm
fuente
Hay una excepción en (( var = 12 ))o var=( value )o $((var = 12))o${var[foo = 12]}
Stéphane Chazelas
@ StéphaneChazelas: No mencioné esos casos en esta pregunta, agregue información. Gracias.
Cuonglm