Acabo de notar que en una de mis máquinas (ejecutando Debian Sid) cada vez que escribo ls
cualquier nombre de archivo con espacios tiene comillas simples que lo rodean.
Inmediatamente revisé mis alias, solo para encontrarlos intactos.
wyatt@debian630:~/testdir$ ls
'test 1.txt' test1.txt
wyatt@debian630:~/testdir$ alias
alias ls='ls --color=auto'
alias wget='wget --content-disposition'
wyatt@debian630:~/testdir$
Otra prueba, con archivos que contienen comillas simples en sus nombres (también respondiendo a una solicitud de jimmij):
wyatt@debian630:~/testdir$ ls
'test 1.txt' test1.txt 'thishasasinglequotehere'\''.txt'
wyatt@debian630:~/testdir$ touch "'test 1.txt'"
wyatt@debian630:~/testdir$ ls
''\''test 1.txt'\''' test1.txt
'test 1.txt' 'thishasasinglequotehere'\''.txt'
actualizar con la nueva salida coreutils-8.26 (que es mucho menos confusa, pero irritante de tener por defecto). Gracias a Pádraig Brady por esta impresión:
$ ls
"'test 1.txt'" test1.txt
'test 1.txt' "thishasasinglequotehere'.txt"
$ ls -N
'test 1.txt' test1.txt
test 1.txt thishasasinglequotehere'.txt
¿Por qué está pasando esto? ¿Cómo lo detengo correctamente?
para aclarar, yo mismo configuré ls para la salida de color automáticamente. Nunca puso citas alrededor de las cosas antes.
Estoy corriendo bash
y coreutils 8.25.
EDITAR: Parece que los desarrolladores de coreutils pensaron (enlace) que sería una buena idea convertirlo en un valor predeterminado global a pesar de romper el principio de menos asombro y más de 46 años de tradición UNIX.
¿Alguna forma de arreglar esto sin una recompilación?
ACTUALIZACIÓN: octubre de 2017: Debian Sid ha vuelto a habilitar la cita de escape de shell de forma predeterminada. Esto se está volviendo ridículo. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877582
Y en la parte inferior de la cadena de respuesta al informe de error anterior, "el cambio fue intencional y permanecerá". https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813164#226
Pensé que esto estaba resuelto. Aparentemente no.
ACTUALIZACIÓN: abril de 2019: acabo de encontrar un informe de error en PHP que fue causado por este cambio en ls
. Cuando confunde a los desarrolladores y genera informes de errores falsos, es hora de repensar sus cambios.
Actualización: Android toybox ls
ahora está haciendo algo similar a esto pero con barras invertidas en lugar de comillas. El uso de la opción -q hace que los espacios se procesen como 'caracteres de signo de interrogación' (no he verificado cuáles son, ya que obviamente no son espacios), por lo que la única solución que he encontrado hasta ahora sin enraizar el dispositivo en cuestión es agregar esto a una secuencia de comandos y fuente cuando se inicia un shell. Esta función hace ls
uso de columnas si está en una terminal y de lo contrario imprime una por línea, mientras que engaña ls
en los espacios de impresión textualmente porque se ejecuta a través de una tubería.
ls() {
# only way I can stop ls from escaping with backslashes
if [ -t 1 ]; then
/system/bin/ls -C "$@" |cat
else
/system/bin/ls "$@" |cat
fi
}
ls | cat
ver si desaparece. Si tuviera una máquina del tiempo, volvería a Bell Labs ~ 1970 y trataría de convencer a Ken Thompson de que permitir espacio en los nombres de archivos y directorios es una mala idea. :-P
'*'
. Supongo que agregaré ls
alias a todas mis máquinas para deshacerme de él ...
QUOTING_STYLE=literal
lugar de un alias. (Supongo que es una cuestión de gustos, pero prefiero la variable.)
ls
comando.