Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

document path only syntax #385

Closed
ghost opened this issue Jan 8, 2019 · 10 comments
Closed

document path only syntax #385

ghost opened this issue Jan 8, 2019 · 10 comments

Comments

@ghost
Copy link

ghost commented Jan 8, 2019

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
Copy link
Author

ghost commented Jan 8, 2019

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

@ghost ghost changed the title document (or better yet change) path only syntax document path only syntax Jan 8, 2019
@sharkdp
Copy link
Owner

sharkdp commented Jan 8, 2019

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
Copy link
Author

ghost commented Jan 8, 2019

@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
Copy link
Owner

sharkdp commented Jan 8, 2019

@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
Copy link
Author

ghost commented Jan 8, 2019

@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
Copy link

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
Copy link
Owner

sharkdp commented Jan 10, 2019

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
Copy link
Author

ghost commented Jan 10, 2019

@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
Copy link
Owner

sharkdp commented Jan 10, 2019

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

image

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

@ghost
Copy link
Author

ghost commented Jan 10, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants