Do you think the size of the explanations for {} and friends should be smaller? I quite like them as they are, tbh.

The examples should be the same for the man pages and the help output right?

Do you think the size of the explanations for {} and friends should be smaller? I quite like them as they are, tbh.

I would not make the text on this less detailed. I just would like it to be a little bit less in the spotlight. It's not the first thing users should learn when reading about --exec. I think they should see a few easy examples (and most common use cases) first.

The examples should be the same for the man pages and the help output right?

Yes

the manpage definitely needs more attention regarding -x, it doesn't even mention the semicolon to end the command. I thought enclosing the command in quotes " would make sense as well?

the manpage definitely needs more attention regarding -x, it doesn't even mention the semicolon to end the command.

👍

I thought enclosing the command in quotes " would make sense as well?

Hm, not necessarily. fd … -x wc -l is correct. fd … -x "wc -l" will not work. fd … -x "wc" "-l" is fine, but not really needed.

i was fooled by both the manpage and --help's output, because they mention all options args are required to be before pattern and path (which none of your examples using -x adhere to), hence i assumed -x takes a string (as in: single argument, enclosed in "). would that have made parsing much easier, wouldn't it? Also more intuitive

i was fooled by both the manpage and --help's output, because they mention all options args are required to be before pattern and path

Hm, true. On the other hand, most "USAGE"/"SYNOPSIS" sections are written like this, even if the programs support flags/options after the positional arguments. Take ls, for example:

SYNOPSIS
       ls [OPTION]... [FILE]...

It still supports things like ls FILE -l though.

In fact, I think this is a quite essential feature for a command line interface. It allows users to easily repeat the last command while adding a new option (without having to move the cursor in front of the position arguments).

If you think we should improve the documentation in this respect, let us know.

hence i assumed -x takes a string

I can definitely see why you would think that. Let's add this to the list of things that should be improved in this ticket.

would that have made parsing much easier, wouldn't it? Also more intuitive

It would have made (this part of) parsing easier, yes. We still decided against this. There are several reasons:

• If we would have accepted a string like "wc -l" or something more complicated like "echo -n \"found search result {}\", " as an argument, we would have had two options: (1) use an intermediate shell to execute the command. this would have resulted in a drastic performance regression for fast-running commands. (2) we could have tried to parse the string ourselves, splitting it up into separate arguments in order to properly start the child process.
• Since file names can contain all sorts of characters (a space, a newline, a quote), we would need to know how to escape these characters when replacing patterns like {} in the command string (in both cases above!). I'm pretty sure that this is an impossible task in general. Just imagine someone wants to execute convert '{}' "{/}.png" while some search results contain a ' character and some others contain a " character. By implementing -x the way we did it, we leave all of this to the users shell. Without any nasty surprises for the user.
• I like that I can type fd … -x wc -l instead of fd … -x "wc -l".

In fact, I think this is a quite essential feature for a command line interface. It allows users to easily repeat the last command while adding a new option (without having to move the cursor in front of the position arguments).

Totally agree. I've encountered programs that absolutely require options to come before arguments, and found it very annoying.

sure, but passing a string feels natural, no matter the position

Would you consider also adding an example of using --exec with a command that redirects its output to stdout and saves as a file? I personally just ran into this and it took me a little while to figure it out. So an example in the docs might be nice. I got my solution (in part) from this SO question.

A somewhat trivial example of cating all text files below the current directory into a file with the same name in the directory above.

via a script

cat.sh

#!/usr/bin/env sh
cat "$1" > "$2"

$ fd -e .txt --exec ./cat.sh {} ../{/} \; . .

one-liner

$ fd -e .txt --exec sh -c "cat {} > ../{/}" \; . .

I appreciate there may be a better way of doing this that I haven't figured out.

Using an intermediate shell script is the best option here, I believe. Your first version is fine, but could be simplified to (this is what this ticket is about):

$ fd -e .txt --exec ./cat.sh {} ../{/}

The one-liner is not equivalent and will fail for more complex filenames with spaces, for example. Using --exec sh -c "cat '{}' > ../'{/}'" would be a bit safer, but can still fail for filenames involving quotes.

@Piraty

sure, but passing a string feels natural, no matter the position

Maybe, but I think I gave a couple of reasons why this is not a good idea. Note that find does the same. It also takes the command as a sequence of arguments instead of a string.