[ale] find + ls commands: commentary [was: Bash script]

Ron admin at bclug.ca
Tue Apr 15 19:28:07 EDT 2025


Scott Plante via Ale wrote on 2025-04-15 11:08:

> First, I'd like to thank you for introducing me to the \+ syntax on 
> find.

Happy to share the knowledge!


> I knew about "-exec ... {} \;" but usually used "find ... -print0| 
> xargs -0 ..." instead. It sounds like the -exec \+ accomplishes the same 
> thing more succinctly.

I think so.

Today I learnt that `xargs` was part of the `findutils` package, along 
with `find`.  I never use `xargs` and was unaware.


> I'm afraid both methods could have the same flaw in this situation 
> though. The thing with xargs is that it determines how many arguments 
> can fit on a command line and, if there are more than will fit on one 
> line, executes the command multiple times. I assume the -exec syntax 
> operates the same way [...]
> 
> I don't have time to test right now. Am I wrong?

Looks like it; I don't think `ls` and `xargs` share that quirk.

Ohhh, it's a `find` quirk - buffer fills up?


AND, I WAS WRONG: testing on 2,777,182 files breaks something!

So... "never mind" on this whole sub-thread.



The man page is a bit cryptic on this, one must know what behaviour of 
`xargs` they're talking about (kinda crappy documentation, no mention of 
buffer size, etc.):

 > the total number of invocations of the command will be much less than
 > the number  of  matched  files.
 >
 > The  command  line is built in much the same way that xargs builds its
 > command lines.

I'm expecting one invocation of "the command", which is much less than 
the number of matched files.

Anything here I need to look out for? Care to elaborate? No?




And this is why I'm sympathetic when someone comes along and says, "this 
old stuff was great, but now it's showing its age and needs something 
better".



Requires further investigation.

The -fls (ls-to-file) option of `find` produces some weird output 
columns that aren't immediately apparent and cannot be controlled with 
any options (inode nums, sizes in blocks (who cares?)),...


The simple -ls option implies -dils, which might work? Nope, can't sort 
the default brain-dead date format of "Apr 15 15:27" and can't pass 
options to -ls this way.


Back to square one.

Maybe find with ls, piped to file, sorted to file, head & tail that 
final file?




More information about the Ale mailing list