Constantemente veo respuestas que citan este enlace que dice definitivamente “No analizar ls !” Esto me molesta por un par de razones:
-
Parece que la información en ese enlace ha sido aceptada al por mayor con pocas dudas, aunque puedo detectar al menos algunos errores en la lectura casual.
-
También parece que los problemas mencionados en ese enlace no han despertado el deseo de encontrar una solución.
Desde el primer párrafo:
…cuando preguntas [ls] para una lista
de archivos, hay un gran problema:Unix permite casi cualquier carácter en
un nombre de archivo, incluidos espacios en blanco, saltos de línea, comas, símbolos de tubería y
prácticamente cualquier otra cosa que desee alguna vez intente usar como delimitador excepto
NUL. … ls separa los nombres de archivo con saltos de línea. Esto está bien
hasta que tenga un archivo con una nueva línea en su nombre. Y como no
conozco ninguna implementación de ls que le permite terminar
nombres de archivo con caracteres NUL en lugar de saltos de línea, esto nos deja
incapaces de obtener una lista de nombres de archivo de forma segura con ls .
Qué fastidio, ¿verdad? Cómo siempre ¿podemos manejar un conjunto de datos enumerados terminados en líneas nuevas para datos que puedan contener líneas nuevas? Bueno, si las personas que responden preguntas en este sitio web no hicieran este tipo de cosas a diario, podría pensar que estamos en problemas.
Sin embargo, la verdad es que la mayoría de los ls Las implementaciones en realidad proporcionan una API muy simple para analizar su salida y todos lo hemos estado haciendo todo el tiempo sin siquiera darnos cuenta. No solo puede terminar un nombre de archivo con nulo, sino que también puede comenzar uno con nulo o con cualquier otra cadena arbitraria que desee. Además, puede asignar estas cadenas arbitrarias por tipo de archivo . Por favor considere:
LS_COLORS='lc=