¿Por qué 'ls' está repentinamente envolviendo elementos con espacios entre comillas simples?


187

Acabo de notar que en una de mis máquinas (ejecutando Debian Sid) cada vez que escribo lscualquier 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$

(imagen)

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'

(imagen)

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 bashy 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 lsahora 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 lsuso de columnas si está en una terminal y de lo contrario imprime una por línea, mientras que engaña lsen 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
}

20
Otra razón más por la que no analizar el lscomando.
jimmij

12
Parece extraño, pero si solo está habilitado al imprimir en un terminal, tiene sentido. Puede ver claramente que tiene un archivo 'prueba 1.txt' en lugar de un archivo 'prueba' y otro '1.txt'. Intenta ls | catver 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
Bjorn Munch

66
Cuando vi esto por primera vez, me asusté, pensando que uno de mis guiones había salido mal y renombrado todos mis archivos '*'. Supongo que agregaré lsalias a todas mis máquinas para deshacerme de él ...
Expiación limitada

14
@LimitedAtonement, como señaló Lekensteyn , puede hacerlo con una variable de entorno en QUOTING_STYLE=literallugar de un alias. (Supongo que es una cuestión de gustos, pero prefiero la variable.)
LSpice

44
@BjornMunch hay dos soluciones al problema de saber si se trata de un archivo o dos: 1) busque cómo se dibujan las columnas y es bastante obvio. 2) enumere un artículo por línea. Ambas se ven mejor y más claras que las comillas simples.
Wyatt8740

Respuestas:


132

Prefacio : Si bien puede ser bastante satisfactorio votar una respuesta como esta y llamarlo un día, tenga la seguridad de que a los desarrolladores de GNU no les importan los votos de respuesta SO, y que si realmente desea alentarlos a cambiar , debe envíelos por correo electrónico como lo describe esta respuesta.


" ¿Por qué está pasando esto? "

Varios desarrolladores de coreutils decidieron que sabían mejor que décadas de estándares de facto.


" ¿Cómo lo detengo correctamente? "

http://www.gnu.org/software/coreutils/coreutils.html :

Informes de errores

Si cree que ha encontrado un error en Coreutils, envíe un informe de error lo más completo posible a <bug-coreutils@gnu.org> , y se ingresará automáticamente en el rastreador de errores de Coreutils. Antes de informar de errores, lea las preguntas frecuentes. Una guía muy útil y a menudo referenciada sobre cómo escribir informes de errores y hacer buenas preguntas es el documento Cómo hacer preguntas de manera inteligente. Puede navegar por publicaciones anteriores y buscar en el archivo bug-coreutils.

Distros que ya han revertido  este cambio:

Distros no afectados:

  • openSUSE (ya usado -N)

"¿ Alguna forma de arreglar esto sin una recompilación? "

Los defensores te tendrían ...

volver al formato anterior agregando -N a su alias ls

... en todas sus instalaciones, en todas partes, por el resto de la eternidad.


17
El cambio fue propuesto en la lista de correo y tres mantenedores de coreutils acordaron que sería un beneficio neto. Estamos completamente abiertos a argumentos constructivos sobre esto. Esto es de código abierto después de todo, no queremos dictar, solo para mejorar las cosas. No dude en responder en el hilo de coreutils en lists.gnu.org/archive/html/coreutils/2016-02/msg00000.html (Por cierto, hubo una sugerencia constructiva para mejorar una de las desventajas estéticas mencionadas allí, agregando un espacio para mejorar la alineación)
Pádraig Brady

31
@ PádraigBrady Respuesta actualizada. Sin embargo, al ver un montón de negación en su hilo coreutils. La conclusión es que está creando más trabajo para las personas, y lo está haciendo en nombre de un sistema operativo que es un clon de un sistema operativo de 1970. Si las personas quieren algo diferente, optarán por él.
Jan Kyu Peblik

43
@ PádraigBrady Este cambio me ha causado molestias y ha desperdiciado varias horas tratando de encontrar una causa y una solución. No quiero ser negativo, ¡solo estoy compartiendo el punto de vista de otras personas! La modificación del comportamiento central tiene enormes implicaciones ..
mafrosis

52
Como alguien que ha usado sistemas * nix durante 30 años, considero que los cambios gratuitos como este son bastante molestos. Rompen guiones antiguos, por un lado. También violan el Principio de Menos Asombro. "Opt-in" debería haber sido el valor predeterminado aquí, como se indicó anteriormente.
Brian Clapper el

28
@ PádraigBrady Esa todavía no es la forma de impulsar tales cambios. Hubiera sido mucho más constructivo tener ese comportamiento habilitado en lugar de activo por defecto. También insinúa falsamente que así es como se almacenan los nombres de archivo, en resumen, con lslo que ves ya no es cómo está almacenado. Esa característica debería ser opcional, no la predeterminada.

91

Puede elegir el estilo de cotización :

ls --quoting-style=literal

Lo mismo que:

ls -N

o:

QUOTING_STYLE=literal ls

Que sea un alias, o establecer export QUOTING_STYLE=literalen su .bashrclograr pre-8.25 comportamiento.


11
Parece un poco extraño. Tengo que hacer eso para obtener un comportamiento normal de unix. Además, quiero el viejo valor predeterminado. No creo que escapar fuera el valor predeterminado anterior: creo que imprimió exactamente lo que realmente estaba allí.
Wyatt8740

99
Para el comportamiento anterior a 8.25, export QUOTING_STYLE=literalúselo en su bashrc.
Lekensteyn el

2
o uso -N, parece. Solo estoy compilando mi propia versión ya que tengo un repositorio personal configurado.
Wyatt8740

2
@LSpice He editado la publicación para usarla en literallugar de escape(creo que @cuonglm solo quería mostrar cómo cambiar el estilo, no específicamente el escapeestilo).
Lekensteyn

55
Esta respuesta merece más votos a favor. Aborda directamente lo que preguntó el interrogador evitando una respuesta burocrática. De hecho, el enfoque variable de entorno parece bastante elegante. (Personalmente prefiero el nuevo comportamiento, ya que favorece una acción C&P más eficiente), sin embargo, ls es lo suficientemente inteligente como para comportarse de la manera anterior cuando se usa una redirección, por lo que no daña las secuencias de comandos que utilizan la salida de ls.
Marcelo

42

Algunos puntos sobre el cambio.

  • Se introdujo en coreutils v8.25, y la alineación mejoró en v8.26
  • Solo ocurre cuando se envía a terminales, por lo que no interrumpe los scripts
  • Desambigua la salida para los usuarios de archivos que contienen espacios en blanco
  • Desinfecta la salida, por lo que es seguro copiar y pegar
  • La salida ahora siempre es válida para copiar y pegar en el shell
  • Los usuarios pueden volver al formato anterior agregando -N a su alias ls

77
Mi último ejemplo no es ambiguo? Quizás no, pero ciertamente es confuso y lleva más tiempo descifrarlo. Creo que es un cambio terrible (sin ánimo de ofender). Gracias por el consejo de alias.
Wyatt8740

27
Nota: este cambio se introdujo en coreutils 8.25 ( commit , creado por el mismo Pádraig que esta publicación). Personalmente, creo que este comportamiento es subóptimo, rompe la alineación cada vez que se produce un espacio en un nombre de archivo.
Lekensteyn el

10
Mis disculpas: al parecer, está cotizando con seguridad las cotizaciones de shell al menos. Todavía no me gusta. las opciones están bien, pero alterar el comportamiento predeterminado muy bien especificado de una utilidad de núcleo de Unix de décadas de tal manera que disminuya su veracidad solo puede ser una mala idea.
mikeserv

12
@ PádraigBrady Entonces, ¿vas a seguir lsroto? Mire todos esos argumentos en contra de su cambio. Nadie lo quiere Quizás es hora de disculparse con el mundo y deshacerlo.
Chris Warrick

66
@ PádraigBrady Entonces, a pesar de las muchas personas que han explicado cómo está mal, roto, etc., ¿aún no revertirá esto para que el valor predeterminado no cambie? Contrariamente a lo que crees, este cambio no confunde desambigua. Sugerir, en el mejor de los casos, que las personas establezcan una variable de entorno o un alias es estúpido.
Mark
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.