Vedo costantemente risposte che citano questo link affermando definitivamente "Non analizzare ls !” Questo mi infastidisce per un paio di motivi:
-
Sembra che le informazioni in quel link siano state accettate all'ingrosso con poche domande, anche se posso individuare almeno alcuni errori nella lettura casuale.
-
Sembra anche che i problemi indicati in quel collegamento non abbiano acceso il desiderio di trovare una soluzione.
Dal primo paragrafo:
…quando chiedi a [ls] per un elenco
di file, c'è un grosso problema:Unix consente quasi tutti i caratteri in
un nome di file, inclusi spazi bianchi, newline, virgole, simboli di pipe e
praticamente qualsiasi altra cosa tu voglia provare mai a utilizzare come delimitatore tranne
NUL. … ls separa i nomi dei file con nuove righe. Questo va bene
finché non hai un file con una nuova riga nel suo nome. E poiché non
sono a conoscenza di alcuna implementazione di ls che ti consente di terminare
nomi di file con caratteri NUL anziché newline, questo ci lascia
incapaci di ottenere un elenco di nomi di file in modo sicuro con ls .
Brutto, vero? Come mai possiamo gestire un set di dati elencato terminato con una nuova riga per i dati che potrebbero contenere nuove righe? Bene, se le persone che rispondono alle domande su questo sito Web non fanno questo genere di cose su base giornaliera, potrei pensare che siamo nei guai.
La verità è che la maggior parte dei ls le implementazioni in realtà forniscono un'API molto semplice per analizzare il loro output e lo abbiamo sempre fatto senza nemmeno rendercene conto. Non solo puoi terminare un nome file con null, puoi anche iniziarne uno con null o con qualsiasi altra stringa arbitraria che potresti desiderare. Inoltre, puoi assegnare queste stringhe arbitrarie per tipo di file . Si prega di considerare:
LS_COLORS='lc=