Thank you for the feedback!

'-exec' is not supported at the moment. It's definitely something I would consider adding.

We do have '-0'/'--print0' to separate results by NULL, so 'fd' can be used in combination with 'xargs'.

Or parallel, which is slightly trickier to implement than xargs/-exec.

I'm curious why you (or anyone) uses -exec? It's often painfully slower than piping through xargs and I find the syntax (the semicolon and braces and the required quoting/escaping) uncomfortable. I haven't used -exec in 20 years.

It's not even slower (and it's safe beyond the argv limit) if you use "+" instead of the semicolon.

  find -type f -exec sed -i s/foo/bar/ {} +

This only invokes the command twice for 100k files (assuming we can pass in 64k arguments to sed)

Thanks! I never knew about the + terminator.

You need it if you want to modify the directory structure that find is traversing, so as to affect subsequent traversal, eg http://www.chiark.greenend.org.uk/~pmaydell/find/primes (cheatsheet here: http://www.chiark.greenend.org.uk/~pmaydell/find/primes-comm...)

Admittedly I wrote that nearly 20 years ago so I guess it doesn't invalidate your point :-)

In my opinion, xargs has really niche use cases, and -exec is way more fit for general use.

- There's the issue of command line length, pipe too many files and xargs will just fail.

- There's predictibility. With -exec you get to see the entire command line structure, what is escaped, what is not, what names go where. With xargs, a couple of badly named files and you are out of luck.

- Find's syntax is just more general. Xarg is limited to pushing parameters into a script, while -exec can run whatever scrit you want, with single or multiple parameters, or flags, or whatever.

Performance is almost never an issue.

see a detailed discussion here: https://unix.stackexchange.com/questions/321697/why-is-loopi...

especially this quote:

> find's business is evaluating expressions -- not locating files. Yes, find certainly locates files; but that's really just a side effect.

> I'm curious why you (or anyone) uses -exec?

I already know how to use it. It works.

> It's often painfully slower than piping through xargs

I've tried it. It has different semantics. First attempt always leads to errors and doing the wrong things. I always have to come up with some workaround to make things work as I expect they would (i.e. how -exec does things by default).

This lack of confidence also means I would never dare using xargs for anything remotely destructive (like rm).

What reason do I have not to use -exec? Why swap a perfectly perfect hammer for a broken screwdriver?

Besides: IMO the timesaving aspects of find is not strictly tied to how fast find runs. It's tied to what I can automate.

YMMV? Having used find -exec for 20+ years, I find it much more difficult to convince myself to switch to tools like this, and just simpler to use -exec. That, and the extra spawn - and potential for disaster - that putting a | into the mix can incur ..

What about commands which only take a single file as input? Is xargs -n1 noticeably faster than -exec? (And if it is, is that actually worth it for clarity's sake?)

find ... -ok ... {} \; is easier to type than find ... -print0 | xargs -0 -p -I{} ... {}

You can easily compose this with `xargs` using the`-0 / --print0` option:

fd -0 '\.log$' | xargs -0 tail

xargs does have limits on input length. On some platforms they aren't terribly high. Sound like -exec is potentially coming though.

Edit: Swore I had gotten ARG_MAX complaints out of xargs in the past. Replies are correct though. I'm wrong here...xargs adjusts on the fly. Perhaps long ago, or some obscure use of xargs?

Why is this a problem? Except in terms of performance, it's completely invisible to the user as xargs will run the command multiple times to ensure all the arguments are processed. In the most extreme/unrealistic case, if xargs could only support invoking the command with a single arguement, then the performance would regress to that of using -exec. Otherwise it's much faster.

> xargs does have limits on input length

what?

Some versions of xargs don't respect the shell's max argument length, so on older platforms (MacOS X 10.4 sticks out in my memory) it's easy to cause xargs to try invoking with a longer command line than permitted.

This is fixed with the `-n` argument to xargs, which lets you specify the number of arguments per invocation.

Yeah they can be as low as 4096 bytes. `xargs --show-limits`