bash - regulares - sed sustituir caracteres especiales




¿Por qué a veces se necesitan espacios en blanco alrededor de los metacaracteres? (4)

Hace unos meses tatué una bomba de tenedor en mi brazo, y salté los espacios en blanco, porque creo que se ve mejor sin ellos. Pero para mi consternación, a veces (no siempre) cuando lo ejecuto en un shell, no se inicia una bomba de bifurcación, pero solo da un error de sintaxis.

bash: syntax error near unexpected token `{:'

Ayer sucedió cuando intenté ejecutarlo en el shell de Bash un amigo, y luego agregué el espacio en blanco y de repente funcionó,: :(){ :|:& };: lugar de :(){:|:&};:

¿Importa el espacio en blanco? ¿He tatuado un error de sintaxis en mi brazo?

Parece que siempre funciona en zsh , pero no en Bash.

Una pregunta relacionada no explica nada sobre los espacios en blanco, que realmente es mi pregunta; ¿Por qué se necesita el espacio en blanco para que Bash pueda analizarlo correctamente?


Y luego agregué el espacio en blanco y de repente funcionó ...

Es debido a cómo el shell analiza. Necesita un espacio después de que comience la definición de la función, es decir, después de { .

foo() { echo hey& }
foo() { echo hey&}
foo(){ echo hey&}

son validos. Por otra parte,

foo() {echo hey&}

no es

Realmente necesitas un tatuaje como este:

De la source :

  /* We ignore an open brace surrounded by whitespace, and also
     an open brace followed immediately by a close brace preceded
     by whitespace.  */

La omisión de un espacio después de { hace que {echo se interprete como un único token.

Una forma equivalente de

:(){ :|:& };:

sería

:(){
:|:& };:

Tenga en cuenta que no hay espacio después de { en la versión alternativa, pero un salto de línea hace que el shell reconozca { como un token.


Aunque no es fácilmente visible en la fuente del tatoo, en realidad hay una marca de orden de byte (BOM) entre el corsé y el colon (es posible que haya estado lo suficientemente intoxicado cuando recibió el tatoo como para no notarlo, pero realmente está ahí) . Esto deja tres posibilidades obvias:

  1. No ha podido escribir la lista de materiales cuando transcribió el código. El resultado es una aplicación obvia de GIGO. El shell simplemente no reconoce una lista de materiales que no está presente en su transcripción fallida.
  2. Tu concha es muy vieja No reconoce los caracteres Unicode, por lo que la lista de materiales (y probablemente todos los demás caracteres de Unicode) se está ignorando por completo, aunque una lista de materiales en cualquier lugar, pero el principio de un archivo se debe tratar como un espacio de ancho cero y sin interrupciones .
  3. Tu concha es demasiado nueva. El uso de una lista de materiales como ZWNBS está en desuso, y los autores han implementado una versión futura de Unicode en la que ya no se permite este uso.

Las llaves son más como palabras clave impares que símbolos especiales, y necesitan espacios. Esto es diferente a los paréntesis, por ejemplo. Comparar:

(ls)

que funciona, y

{ls}

que busca un comando llamado {ls} . Para trabajar, tiene que ser:

{ ls; }

El punto y coma impide que la llave de cierre se tome como parámetro a ls .

Todo lo que tiene que hacer es decirle a la gente que está usando una fuente proporcional con un carácter de espacio bastante estrecho.


Solo tatuar un

#!/bin/zsh

shebang por encima de ella y estarás bien.







syntax-error