The “find” command <https://manpages.debian.org/1/find.en.html> offers
a great variety of ways to filter out files. And if none of them is
quite good enough, you can use the “-exec” option to execute an
arbitrary command.

Unfortunately, it must be an arbitrary *single* command.

For example, I wanted to identify .blend files created by Blender
versions after 3.4. I have a command called “blendfile_version”
<https://gitlab.com/ldo/blender-useful/> which will output some basic
version information about a .blend file in JSON format. From this,
it’s easy enough to extract the version string with

blendfile_version «blendfile» | jq -r .version

and then filter out older versions with

test $(blendfile_version «blendfile» | jq -r .version) -gt 304

But this command cannot be used as is with -exec! That is, if I try

find . -name \*.blend -exec test $(blendfile_version {} | jq -r .version) -gt 304 \; -print

that won’t work, because -exec will not feed the command to a shell to
handle the command substitution, pipelining etc.

However, you can explicitly invoke a shell and give it a one-shot
command with “sh -c”. While the command string must be a single word,
it is possible to have multiple argument words following this command.
So if the command happens to be “eval”, that gives you your ability to
feed the separate words of the -exec command to the shell, thus:

find . -name \*.blend -exec sh -c 'eval "${@}"' \
sh test \$\( blendfile_version {} \| jq -r .version \) -gt 304 \; -print

This works, but it assumes that the find command will only substitute
the “{}” sequence with the file name if it occurs as a separate word.
In fact, GNU find will perform this substitution even if the sequence
occurs as part of a word. This allows the -exec command to be
simplified somewhat, by getting rid of the “eval” stage:

find . -name \*.blend -exec \
sh -c '[ $(blendfile_version {} | jq -r .version ) \> 304 ]' \; \
-print

And there we have it. Some commands have a “quiet” option, where you
give them a criterion to match, and they return an exit status
indicating success/failure to match (e.g. “grep -q”). Having this may
make use with find just a little bit easier, but as you can see, it’s
not strictly necessary.

On 2024-04-27, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> find . -name \*.blend -exec \
> sh -c '[ $(blendfile_version {} | jq -r .version ) \> 304 ]' \; \
> -print

This is problematic because the filename is simply interpolated
into the command string, which is then interpreted by sh. If the
filename contains whitespace or shell meta-characters, the results
will be unexpected. Surrounding the {} with quotes doesn't fix
this completely, because the filename could contain a quote character.

A few days ago, Helmut Waitzmann pointed out a better solution over
on the German group:

find . -name \*.blend -exec sh -c \
'[ $(blendfile_version "$1" | jq -r .version ) \> 304 ]' sh {} \; \
-print

You pass the filename as a positional parameter and reference it
as such in the command string.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

Another option: find ... -print0 | xargs -0 -n 1 ...

At Sat, 27 Apr 2024 13:40:52 -0000 (UTC) Christian Weisgerber <naddy@mips.inka.de> wrote:

>
> On 2024-04-27, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
> > find . -name \*.blend -exec \
> > sh -c '[ $(blendfile_version {} | jq -r .version ) \> 304 ]' \; \
> > -print
>
> This is problematic because the filename is simply interpolated
> into the command string, which is then interpreted by sh. If the
> filename contains whitespace or shell meta-characters, the results
> will be unexpected. Surrounding the {} with quotes doesn't fix
> this completely, because the filename could contain a quote character.
>
> A few days ago, Helmut Waitzmann pointed out a better solution over
> on the German group:
>
> find . -name \*.blend -exec sh -c \
> '[ $(blendfile_version "$1" | jq -r .version ) \> 304 ]' sh {} \; \
> -print
>
> You pass the filename as a positional parameter and reference it
> as such in the command string.
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

On 2024-04-27, Robert Heller <heller@deepsoft.com> wrote:
> At Sat, 27 Apr 2024 13:40:52 -0000 (UTC) Christian Weisgerber <naddy@mips.inka.de> wrote:
>> A few days ago, Helmut Waitzmann pointed out a better solution over
>> on the German group:
>>
>> find . -name \*.blend -exec sh -c \
>> '[ $(blendfile_version "$1" | jq -r .version ) \> 304 ]' sh {} \; \
>> -print
>>
>> You pass the filename as a positional parameter and reference it
>> as such in the command string.
>
> Another option: find ... -print0 | xargs -0 -n 1 ...

And what is the ... after xargs? The goal of the command is
to print only those files F that individually satisfy the predicate
"[ $(blendfile_version F | jq -r .version) -gt 304 ]".

xargs will turn groups of files into command arguments, so
now you have to iterate over them; something like:

.. | xargs sh 'for x in "$@"; do\
[ $(blendfile_version "$x" | \
jq -r .version ) -gt 304 ] && printf "%s\n" "$x"
done'

It doesn't seem like an improvement. It does at least as much work
(still has to dispatch blendfile_version as many times as there
are files). It's more verbose, and uses GNU extensions.

If extensions are allowed, we can just drop find entirely and use
use double star globbing in Bash or any other shell that has it:

for x in **/*.blend; do
[ $(blendfile_version "$x" | jq -r .version ) -gt 304 ] && printf "%s\n" "$x"
done

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

At Sat, 27 Apr 2024 18:13:25 -0000 (UTC) Kaz Kylheku <643-408-1753@kylheku.com> wrote:

>
> On 2024-04-27, Robert Heller <heller@deepsoft.com> wrote:
> > At Sat, 27 Apr 2024 13:40:52 -0000 (UTC) Christian Weisgerber <naddy@mips.inka.de> wrote:
> >> A few days ago, Helmut Waitzmann pointed out a better solution over
> >> on the German group:
> >>
> >> find . -name \*.blend -exec sh -c \
> >> '[ $(blendfile_version "$1" | jq -r .version ) \> 304 ]' sh {} \; \
> >> -print
> >>
> >> You pass the filename as a positional parameter and reference it
> >> as such in the command string.
> >
> > Another option: find ... -print0 | xargs -0 -n 1 ...
>
> And what is the ... after xargs? The goal of the command is
> to print only those files F that individually satisfy the predicate
> "[ $(blendfile_version F | jq -r .version) -gt 304 ]".
>
> xargs will turn groups of files into command arguments, so
> now you have to iterate over them; something like:
>
> .. | xargs sh 'for x in "$@"; do\
> [ $(blendfile_version "$x" | \
> jq -r .version ) -gt 304 ] && printf "%s\n" "$x"
> done'
>
> It doesn't seem like an improvement. It does at least as much work
> (still has to dispatch blendfile_version as many times as there
> are files). It's more verbose, and uses GNU extensions.

The '-n 1' tells xargs to run the command given to xargs with only one file at
a time. There is no need for the "for x in "$@"; do...".

find . -name '*.blend' -print0 | xargs -0 -n 1 'sh [ $(blendfile_version "$1" | \
jq -r .version ) -gt 304 ] && printf "%s\n" "$1"'

The combination of find's -print0 and xargs -0 is to pass the names as nul
terminated strings rather then newline separated strings. This avoids problems
with file names containing characters that the shell with try to make sense of
(eg spaces, etc.).

>
> If extensions are allowed, we can just drop find entirely and use
> use double star globbing in Bash or any other shell that has it:
>
> for x in **/*.blend; do
> [ $(blendfile_version "$x" | jq -r .version ) -gt 304 ] && printf "%s\n" "$x"
> done
>
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

On Sat, 27 Apr 2024 13:40:52 -0000 (UTC), Christian Weisgerber wrote:

> This is problematic because the filename is simply interpolated into the
> command string, which is then interpreted by sh. If the filename
> contains whitespace or shell meta-characters, the results will be
> unexpected.

That is true. I only realized it later, after posting.

> You pass the filename as a positional parameter and reference it as such
> in the command string.

Another possibility might be to use an environment variable. I have done
this in other scripts.

Robert Heller <heller@deepsoft.com>:

>The '-n 1' tells xargs to run the command given to xargs with only one file at
>a time. There is no need for the "for x in "$@"; do...".

>find . -name '*.blend' -print0 | xargs -0 -n 1 'sh [ $(blendfile_version "$1" | \
> jq -r .version ) -gt 304 ] && printf "%s\n" "$1"'

You mean:

find . -name '*.blend' -print0 | xargs -0 -n 1 sh -c '[ $(blendfile_version "$1" | \
jq -r .version ) -gt 304 ] && printf "%s\n" "$1"' sh

Followup-To!

Lawrence D'Oliveiro <ldo@nz.invalid>:

>However, you can explicitly invoke a shell and give it a one-shot
>command with “sh -c”. While the command string must be a single word,
>it is possible to have multiple argument words following this command.
>So if the command happens to be “eval”, that gives you your ability to
>feed the separate words of the -exec command to the shell, thus:

> find . -name \*.blend -exec sh -c 'eval "${@}"' \
> sh test \$\( blendfile_version {} \| jq -r .version \) -gt 304 \; -print

>This works

No, it does not: What happens if find comes upon a file
“Adam & Eve.blend” or “;rm -rf -- "$HOME";.blend”? Yes, the
latter is a valid filename too! If you fill a filename into a
command string without recoding the filename to a notation of a
literal string, you can trick the command string to do things
that you did not have in mind.

I would rather put it this way:

find . -name \*.blend -exec sh -c \
'test "$( blendfile_version "$1" | jq -r .version )" -gt 304' \
sh {} \; -print

Here, find will replace the “{}” with the filename encountered
and give it as a positional parameter to the shell. Therefore it
must not and need not be quoted.

>GNU find will perform this substitution even if the sequence
>occurs as part of a word. This allows the -exec command to be
>simplified somewhat, by getting rid of the “eval” stage:

> find . -name \*.blend -exec \
> sh -c '[ $(blendfile_version {} | jq -r .version ) \> 304 ]' \; \
> -print

Again, this does not work with these two mindfully chosen
filenames.

The solution: Let find give the name that it comes upon as
a positional parameter to the shell:

find … -exec sh -c … sh {} \;

Please pay attention to Followup-To.