¿Por qué las comparaciones de scripts de shell a menudo usan x VAR VAR = xyes?

La otra razón que nadie más ha mencionado es en relación con el procesamiento de opciones. Si escribes:

if [ "$1" = "abc" ]; then ...

Y $1 tiene el valor '-n', la sintaxis del comando test es ambigua; no está claro lo que estaba probando. La ' x ' en la parte delantera evita que un guion principal cause problemas.

Tienes que estar buscando en shells realmente antiguos para encontrar uno donde el comando test no tenga soporte para -n o -z; la Versión 7 (1978) test los incluyó. Se no es del todo irrelevante - algunas cosas de UNIX de la Versión 6 escaparon a BSD, pero en estos días, sería extremadamente difícil encontrar algo tan antiguo en uso actual.

No usar comillas dobles alrededor de valores es peligroso, como un número de otras personas señalaron. De hecho, si existe la posibilidad de que los nombres de los archivos contengan espacios (macOS X y Windows fomentan eso hasta cierto punto, y Unix siempre lo ha soportado, aunque herramientas como xargs lo hacen más difícil), entonces debe incluir el archivo nombres entre comillas dobles cada vez que los usas también. A menos que esté a cargo del valor (por ejemplo, durante el manejo de opciones, y establezca la variable en 'no' al inicio y 'sí' cuando se incluye un indicador en la línea de comandos), entonces no es seguro usar formas de variables sin comillas hasta que las haya probado seguras -- y también puede hacerlo todo el tiempo para muchos propósitos. O documente que sus scripts fallarán horriblemente si los usuarios intentan procesar archivos con espacios en blanco en los nombres. (Y hay otros los personajes de los que preocuparse también could los backsticks también podrían ser bastante desagradables, por ejemplo.)

Hay dos razones que conozco para esta convención:

Http://tldp.org/LDP/abs/html/comparison-ops.html

En una prueba compuesta, incluso citar la variable string podría no ser suficiente. [- n "string string " - o"a a" = "b b"] puede causar un error con algunas versiones de Bash si string la cadena está vacía. La forma segura es añadir un personaje extra a posiblemente variables vacías, ["x string string"!= x-o "x a a" = "x b b"] (las" x " se cancelan).

Segundo, en otros shells además de Bash, especialmente los más antiguos, las condiciones de prueba como '- z ' para probar una variable vacía no existían, así que mientras esto:

if [ -z "$SOME_VAR" ]; then
  echo "this variable is not defined"
fi

Funcionará bien en BASH, si está apuntando a la portabilidad en varios entornos UNIX donde no puede estar seguro de que el shell predeterminado será Bash y si soporta la condición de prueba-z, es más seguro usar el formulario if [ "x SOME SOME_VAR" = "x"] ya que siempre tendrá el efecto deseado. Esencialmente se trata de una antigua shell scripting truco para encontrar una variable vacía, y todavía se utiliza hoy en día para la compatibilidad hacia atrás a pesar de que hay métodos más limpios disponibles.

Recomiendo en su lugar:

if test "yes" = "$SHELL_VAR"; then

Ya que elimina lo feo x, y todavía resuelve el problema mencionado por https://stackoverflow.com/a/174288/895245 que $SHELL_VAR puede comenzar con - y leerse como una opción.

Creo que es debido a

SHELLVAR=$(true)
if test $SHELLVAR  = "yes" ; then echo "yep" ; fi 

# bash: test: =: unary operator expected

Así Como

if test $UNDEFINEDED = "yes" ; then echo "yep" ; fi
# bash: test: =: unary operator expected

Y

SHELLVAR=" hello" 
if test $SHELLVAR = "hello" ; then echo "yep" ; fi
# yep 

Sin embargo, esto debería funcionar normalmente

SHELLVAR=" hello"
if test "$SHELLVAR" = "hello" ; then echo "yep" ; fi 
#<no output>

Pero cuando se queja en la salida en otro lugar, es difícil decir de qué se queja, supongo, así que

SHELLVAR=" hello"
if test "x$SHELLVAR" = "xhello" ; then echo "yep" ; fi 

Funciona igual de bien, pero sería más fácil de depurar.

Solía hacer eso en DOS cuando el SHELL_VAR podría ser indefinido.

Si no haces lo de "x SHELL SHELL_VAR", entonces si$SHELL_VAR no está definido, obtienes un error acerca de que "=" no es un operador monádico o algo así.