document path only syntax

[ghost]

Given this layout:

alpha/
   beta/
gamma/
   delta/
   epsilon.txt

If I want just gamma, thats pretty simple with standard tools:

ls gamma

find gamma

but not with FD:

fd . gamma
fd ^ gamma
fd '' gamma

this seems like a pretty common use case. the obvious fix would be to implement
an explicit option for the path, that way you could do:

fd --some-option gamma

whats more troubling is that none of the current workaround are listed here:

https://github.com/sharkdp/fd

[ghost]

It seems this is already fixed via the hidden, undocumented --search-path option.

[sharkdp]

If I want just gamma, thats pretty simple with standard tools:

ls gamma

find gamma

Comparing with ls doesn't make sense to me. fd and find can be used to list all files (instead of finding certain files), but that's certainly not the prime use case.

Comparing with find's syntax is fair, okay. But I would argue that this is about the only case where finds way of placing the arguments is shorter. fd . path seems weird at first, I agree, but most of the time path is the current directory and I can just call fd.

whats more troubling is that none of the current workaround are listed here

As I said in another ticket: I don't appreciate your negative language. Nobody here is intentionally hiding pieces of information. It simply hasn't been discussed before and nobody has spent part of his free time to write that piece of documentation to share it with others.

There is a README section concerning this exact topic (https://github.com/sharkdp/fd#running-fd-without-any-arguments), so that might be a good place to add a note about using . as a catch-all pattern.

via the hidden, undocumented --search-path option.

The --search-path option is (intentionally) hidden from the short -h help text, but is very well documented in the --help text:

--search-path <search-path>...    
    Provide paths to search as an alternative to the positional <path> argument. Changes the
    usage to `fd [FLAGS/OPTIONS] --search-path <path> --search-path <path2> [<pattern>]`

[ghost]

@sharkdp thank you.

i apologize if i come off rough - i like your tool although i disagree with some design decisions

i didnt realize that -h gives different output from --help - i suppose this is akin to GNU style of something -h/--help vs man something - thanks again.

[sharkdp]

@sharkdp thank you.

i apologize if i come off rough - i like your tool although i disagree with some design decisions

Ok. Disagreeing is completely fine 😄. I'm always happy to discuss design decisions and I have often changed my mind.

i didnt realize that -h gives different output from --help - i suppose this is akin to GNU style of something -h/--help vs man something - thanks again.

Yes. My idea was that the short -h help text could be useful for (1) beginners that don't need all of the more powerful options and (2) advanced users that just want to quickly look up the name of a command-line option without scrolling through the large --help text. I recently added the following note to the end of both help texts (this is not released yet):

Note: fd -h prints a short and concise overview while fd --help gives all details.

[ghost]

@sharkdp ah yes perfect - FFmpeg does the same thing - if you do ffmpeg -h, at the end it says for full help do ffmpeg -h full or similar

[marko-avlijas]

Yes. My idea was that the short -h help text could be useful for (1) beginners that don't need all of the more powerful options and (2) advanced users that just want to quickly look up the name of a command-line option without scrolling through the large --help text. I recently added the following note to the end of both help texts (this is not released yet):

In that case I suggest -h just prints a few carefully selected examples and a single sentence something like: "To see all the options, please type fd --help".

[sharkdp]

In that case I suggest -h just prints a few carefully selected examples and a single sentence something like: "To see all the options, please type fd --help".

Hm.. no. Examples are included in the README and the man page. There is also tldr fd.

[ghost]

@sharkdp that TLDR page is a little... strange - first you have this example:

fd {{pattern}}

which leads you to think that everything inside and including {{}} should be replaced with an actual pattern - but then the next example is this

fd {{'^foo'}}

what are people supposed to make of this? if this go off the first example {{}} should not be inputted literally, but the second example presents them as being literal - also the present Tar example like tar cf, which isnt even a POSIX compatible syntax

the TLDR site is a good idea but poor implementation

[sharkdp]

I don't know why the website does that, but the command line version shows a properly formatted output:

{{ ... }} is just special syntax for colorization.

[ghost]

Hm, it seems the issue is because you didnt do [pattern] or <pattern>, so TLDR thinks both example are literal

but even if what i just said is true, then the {{}} shouldnt be there, as it wouldnt make sense to include with a literal example

so either way the TLDR site seems bugged. Oh well - i didnt know about that site until now - and it doesnt seem like im missing much - thanks