fzf
fzf copied to clipboard
junegunn
Feature request: headless mode
- [x] I have read through the manual page (
man fzf) - [x] I have the latest version of fzf
- [x] I have searched through the existing issues
It would be nice to have a headless mode when writting some scripts for fzf.
Right now, we already setup a http server to accept actions, I think the only missing part is
getting result list through GET.
The scenario in which I find this use case is that, I usually launch fzf from other programs,
and usually I don't want to run it interactively. I think if headless mode is enabled, we could
launch it with fzf --listen > /dev/null and all the interactions are done through HTTP request/response.
What do you think about this?
@junegunn I'll second this request. I use fzf, in multiple places, in my file manager, in the main view I let fzf take over but it's sub optimal because the previews are much better in the file manager and I can't have all the previews in fzf (some are graphical, other open extra programs in a different terminal).
Not sure about he web interface, maybe a simple protocol where one sends commands on std, in a format different from files, and read results on stdout, this would make it simple to run fzf in the background, results can be read in chunks, IE if 35 000 files match fzf writes nothing to stdout, only when the main program requests a chunk of file are they output.
Another use case will be launching fzf remotely, this is extremely useful when working remotely.
0f50dc848e58b47408713c2c31f2be73287c030a is what I can offer at the moment. Since I don't have a solid use case myself, I don't know if the suggested JSON schema is sufficient. Please give it a try and let me know what you think.
@junegunn if I understand the patch right, this only returns a status but there no way yet to change the query or get a subset of the results.
without wanting to complicate it at this stage, I wonder how the the user will be emulated:
- send specific commands, providing some REST API
- send keyboard keys, IE: emulating user input
In any case I'll pull this and test it, I'm curious about what the contents of 'Matches' is (hopping it's not the strings yet), and will be happy to test this as much as you need.
I'll also start integrating this in my application so I can give "real" usage feedback.
@junegunn if I understand the patch right, this only returns a status but there no way yet to change the query or get a subset of the results.
You've never used --listen before? You can invoke any action that can be specified in --bind. e.g. curl localhost:6266 -d 'change-query:foo'
No, I discovered it in your answer in this issue.
I notice that matches is limited to 100 matches. I understand that a a limit had to be set.
If possible I would like to see the possibility to:
- set the number of matches to be returned, best would be with start index and end index
- with the possibility to give 0 for both
- same thing for selection
the match entries consist of:
- text
- index
what is the index supposed to be used for?.
I'll probably decide to add limit and offset parameters, which should be familiar to anyone with SQL experience.
what is the index supposed to be used for?
It's the value of {n}. See #1482 for the motivation behind it.
@junegunn I finally integrated fzf directly in my file manger; thank you for the help.
I notice that there's a slight delay before one can get data from fzf, around 1/10 of second.
fzf --filter currently errors out when no TTY is set, e.g.:
$ fzf --filter= </dev/null
$ echo $status
1
This is the case for example when invoking from AppleScript or JXA.
To workaround, you can use:
$ unbuffer -p fzf --filter=
See https://stackoverflow.com/a/32981392
fzf --filter currently errors out when no TTY is set, e.g.:
Exit status 1 means "no match".
https://github.com/junegunn/fzf/blob/ca747a2b5465961b23aa09606412877dd482a874/man/man1/fzf.1#L875-L882
You're feeding /dev/null, so there can't be any match.
The workaround allows </dev/null without the error:
$ unbuffer -p fzf --filter= </dev/null
$ echo $status
0
Example broken AppleScript:
osascript -e 'do shell script "fzf --filter="'
Fixed by:
osascript -e 'do shell script "unbuffer -p fzf --filter="'