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

[Scott Plante]

First, I'd like to thank you for introducing me to the \+ syntax on find. I
knew about "-exec ... {} \;" but usually used "find ... -print0|xargs -0
..." instead. It sounds like the -exec \+ accomplishes the same thing more
succinctly.

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.
So, if there are more files than will fit on a single "ls" then each ls
execution will be sorted, but they won't be sorted across executions. Then
the total output is sent to head or tail and you'll get the earliest or
latest date only among the files sent to that particular ls execution, not
necessarily the earliest or latest overall.

I don't have time to test right now. Am I wrong?

Scott

On Mon, Apr 14, 2025 at 2:01 AM Ron via Ale <ale at ale.org> wrote:

>
> I'm self-replying because, instead of getting all defensive, I'm gonna
> share an explanation on what is going on with `find` so anyone still
> reading this thread can benefit.
>
>
> I chose `find` because it traverses directories by default, and this can
> be controlled with the -maxdepth and -mindepth options.
>
>
> One can have find execute a command on the found items via the -exec
> option.
>
>
> It gets a bit tricky if one wants to pipe that output to somewhere else,
> as `find` wants to send everything after the -exec to the specified
> program... until it encounters a ";", which needs to be escaped as "\;".
>
> However, that will invoke the -exec program once for each found item.
>
> If one were to use "\+" instead, `find` will bundle up all the found
> results and pass them along at once.
>
>
> This is perfect for our `ls` command: it can take everything found
> anywhere on the SSD and sort it internally, which it's built for and
> there's no gotcha on file sizes, etc.
>
>
> There is a wee gotcha with `ls` though.
>
> If including directories in the `find` search, and then we run `ls` on
> them, their *contents* will be listed, along with "total: ###", blank
> lines, etc.
>
> So, -d or --directory will "list directories themselves, not their
> contents".
>
>
> Finally, we pipe through `tail` (not `head` since we'll get that "signal
> 13" error) and trim to the number of lines needed.
>
> Should be one line, but it depends on whether `ls -a` or `ls -A` (--all
> or --almost-all) are used, where the `find` is run in relation to the
> searched directories, and other things I can't think of.
>
>
> Hopefully someone benefits from this and I haven't made too many errors
> in writing it up.
>
>
>
> Here's some tests one can play with to see what's going on:
>
> find /tmp -exec ls -dltrA {} \+  | less
>
>
> Notice that /tmp itself is the newest entry which may or may not be
> desired.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20250415/19ad09eb/attachment.htm>