On 11/02/2012 15:33, per...@pluto.rain.com wrote: > Matthew Seaman <freebsd-questi...@infracaninophile.co.uk> wrote: > >>>>> ls -1 | xargs rm >> >>>> but be aware that that wont work for filenames with spaces. >> >> True. Can't do that using ls to generate the list of filenames as >> there is no option to generate a null-separated list amongst ls's >> multitudinous collection. > > It can, however, be done indirectly :) > > $ ls -1 | tr '\012' '\000' | xargs -0 rm
Until you run into someone who creates filenames with newlines in them... Well, actually in that case, ls(1) would usually mangle the name: $ touch 'a > file name with > new lines in it' $ ls a* a?file name with?new lines in it Since it uses '?' to replace any "unprintable" character, that's not bullet proof either. Of course, ls(1) has an option for that: $ ls -B a* a\012file name with\012new lines in it Actually, it has two options for that: $ ls -b a* a\nfile name with\nnew lines in it and before Randal picks me up again on the differences between ls(1) outputting to the terminal rather than into anything else... $ ls a* > ls.out $ hd ls.out 00000000 61 0a 66 69 6c 65 20 6e 61 6d 65 20 77 69 74 68 |a.file name with| 00000010 0a 6e 65 77 20 6c 69 6e 65 73 20 69 6e 20 69 74 |.new lines in it| * 00000020 No mangling occurs if you pipe the output into another process. Even so, the conclusion must be that ls(1) is not the best choice for generating a list of file names *for programmatic input* if you have to deal with the full gamut of possible names. find(1) is much better in that case. ls(1) is great for displaying to people in pretty much all circumstances, and it should only be used programmatically if you can /guarantee/ you aren't going run into any of the tricky cases. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature