¿Por qué la comprobación de si una carpeta existe usando -d en una cadena vacía devuelve verdadero?

Estaba escribiendo algunos guiones y escribí algo como

ARTIFACTS="/SOME/PATH"
[ -d $ARTIFCATS ] && rm -rf $ARTIFACTS/*

Lo que sucedió es que por estupidez ejecuté la segunda línea sin ejecutar la primera. Resultó que [-d ""] devuelve verdadero y la expresión se convirtió en

rm -rf /*

Afortunadamente era solo una máquina de prueba y no era un sudo, pero aunque perdí algunos datos

Mi pregunta es, ¿por qué [-d ""] devuelve verdadero? la documentación indica claramente que verifica si existe una ruta y si es una carpeta

Resolví el problema usando

[ -e $ARTIFACTS ]
que parece funcionar

Salud

1. Estas dos pruebas devuelven verdadero :

# [ -d ] && echo true || echo false
true
# [ -d $SOME_UNSET_VAR ] && echo true || echo false
true

de acuerdo con POSIX (como lo explica @Tim).

2. Pero esto devuelve falso ( no es cierto como se indica en la pregunta)

# [ -d "" ] && echo true || echo false
false

porque testse llama con dos argumentos (aunque el segundo es una cadena vacía).

3. Es por eso que es una buena práctica usar en [[ … ]]lugar de test( [ … ]), que proporcionan la mayoría (¿todos?) De los shells actuales. Esta construcción verifica si proporciona suficientes argumentos (de lo contrario, arroja un error y aborta)

# [[ -d ]] && echo true || echo false
bash: unexpected argument `]]' to conditional unary operator
bash: syntax error near `]]'

o simplemente se comporta como uno esperaría:

# [[ -d $SOME_UNSET_VAR ]] && echo true || echo false
false

4. Y, como señaló @Gilles, aún más importante es duplicar las sustituciones. Por lo tanto, se -d "$SOME_UNSET_VAR"expande -d ""y devuelve falso incluso con test(igual al caso 2). Por lo tanto, esto también es compatible con el shell Bourne sh:

# [ -d "$SOME_UNSET_VAR" ] && echo true || echo false
false

probado con bash 3.00.16 (1) y 4.1.5 (1)

Esta pregunta ya ha sido respondida en StackOverflow. Dice que de acuerdo con el estándar POSIX, testsiempre debe devolverse con éxito si se llama con exactamente un argumento no vacío (y sin otros argumentos).

Este también debería ser el caso con test -e(y de hecho está en mi sistema), así que tenga cuidado.

En su lugar use:

[ -d "$ARTIFACTS" ]

test luego se llamará con dos argumentos incluso si la variable está vacía y devuelve falso en este caso.

Resolví el problema usando [-e $ ARTIFACTS] que parece funcionar

Estás equivocado . Funciona porque $ARTIFACTSahora está configurado en algo.

Cuando no se establece una variable, entonces decir

[ -d $SOMEVAR ]

o

[ -e $SOMEVAR ]

sería tanto evaluar a trueporque implica diciendo

[ -d ]

y

[ -e ]

respectivamente. (Decir [ foobar ]siempre se evaluaría como verdadero).

Diciendo

set -u

resulta útil en tales situaciones. help sette diría:

  -u  Treat unset variables as an error when substituting.

Vea que configuró la variable ARTIFACTS y que estaba buscando ARTIFCATS. ¿Probablemente escribiendo mal?

De todos modos, -d así como -e producirían los mismos resultados en variables no establecidas.

Por lo tanto, use comillas dobles y le ayudará.

ARTIFACTS="/SOME/PATH"
[ -d "$ARTIFACTS" ] && rm -rf -- "$ARTIFACTS/"*

NOTA: Si su "/ SOME / PATH" tiene alguna carpeta con espacio, el script que mencionó se romperá con el error "operador binario esperado".

Ejemplo:

ARTIFACTS="/home backup/"

1) [ -d $ARTIFACTS ] && rm -rf $ARTIFACTS/*
bash: [: /home: binary operator expected

2) [ -d "$ARTIFACTS" ] && rm -rf "$ARTIFACTS"/*

Lo haré bien. No olvide poner también comillas en la rminvocación ( rm -rf $ARTIFACTSeliminaría alegremente y /homeluego se quejaría por backup/*no existir).

Además, incluir la -Lverificación se asegurará de que sea un directorio y no solo un enlace simbólico a un directorio.

Así que básicamente,

[ -d "$ARTIFACTS" && ! -L "$ARTIFACTS" ] && rm -rf -- "$ARTIFACTS"/*