5 ms·
> find . -iname '.md' -exec unbuffer ls {} | less -R Ew. Sorry, but no. find . -iname '*.md' -print0 | xargs -0 unbuffer ls {} \; | less -R***
by boring_twenties 3y ago
> find . -iname '.md' -exec unbuffer ls {} | less -R
Ew. Sorry, but no.
find . -iname '*.md' -print0 | xargs -0 unbuffer ls {} \; | less -R***
- pxc 3y agoYep, what I had would definitely eat it under either of at least two conditions: too many files and whitespace in filenames. Your correction fixes both of those issues (the former through using xargs and the latter by splitting the arguments passed to it on the nul character instead of the default (newline, right?)).
- deleted 3y ago[deleted]
- i15e 3y agoYour original command should work fine. find does not pass arguments through an intermediate shell, so there are no quoting concerns with regard to spaces in filenames, etc. And with the form of -exec terminated by a ; it runs a single command for each matching filesystem entry, so there will be no issues with exceeding the maximum argument size. You can verify via strace: $ touch 'a b.md' 'c d.md' $ strace -fe execve find . -iname '*.md' -exec unbuffer ls {} \; At the end of the exec chains you should see the following: execve("/bin/ls", ["ls", "./c d.md"] ... execve("/bin/ls", ["ls", "./a b.md"] ... The filenames are being passed through spaces and all. However if this were a real scenario, a better solution might be: find . -iname '*.md' -exec unbuffer ls -1 {} + (Look up the -1 flag for ls, and the + variant of -exec for find for details)
- pxc 3y agoThis is a great reply! Makes me weirdly glad that I posted further mistakes about my earlier ones. :)
- boring_twenties 3y agoNo, your solution works correctly in both of those cases. My issue with it is that it spawns a separate `ls` subprocess for each file, whereas mine will do it the minimum number of times.
- pxc 3y agoAh! Thanks for the further correction!!