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

Same concept as --bind but for UNIX signals #2019

Closed
5 of 9 tasks
edi9999 opened this issue May 6, 2020 · 4 comments
Closed
5 of 9 tasks

Same concept as --bind but for UNIX signals #2019

edi9999 opened this issue May 6, 2020 · 4 comments

Comments

@edi9999
Copy link
Contributor

edi9999 commented May 6, 2020

  • I have read through the manual page (man fzf)
  • I have the latest version of fzf
  • I have searched through the existing issues

Info

  • OS
    • Linux
    • [] Mac OS X
    • Windows
    • Etc.
  • Shell
    • bash
    • zsh
    • fish

Problem / Steps to reproduce

This is a bit similar as what is described in #1789, so maybe it still does not make sense to handle signals as events.

I use fzf for multiple cases, and in one particular usecase, I am using fzf on some json data that comes from a given file, which contains an array of items.

Since this data takes some time to refresh from its "production" source, I actually use a cached version of the data for the fzf script which is present on my local machine.

However, in parallel, when the script runs, I also do a refresh of the data so that the data is uptodate when I run the script the next time.

Refreshing the data and then running fzf would add some seconds of delay (approximately 5 probably), and since I use that command quite often, I think it makes sense to do both steps in parallel.

Now the problem I have is that quite often, I'm interested in the updated data, and since it doesn't show the uptodate version at first, it means that I usually start the script once and then again because my cached version is too much outdated.

I would find it cool to have the possibility to tell

My current script :

get_data() {
  jq '.[] | .name + " " + .version' <~/tmp/data.json
}
update_data() {
   # some refreshing command with curl that updates ~/tmp/data.json
}
update_data &
get_data | fzf

What I would like to have :

get_data() {
  jq '.[] | .name + " " + .version' <~/tmp/data.json
}
update_data() {
   # some refreshing command with curl
   kill -SIGUSR1 "$fzf_pid"
}
update_data &
fzf < <(get_data) --bind 'sigusr1:reload'  &
fzf_pid="$!"
wait "$fzf_pid"
@doronbehar
Copy link

I'd also be interested in such a feature. I'd like to make an already running fzf session reload data when an external program does something - I'd like the external program to tell fzf to reload the list. (I came to search for such an issue after trying to solve this and this).

@edi9999
Copy link
Contributor Author

edi9999 commented Jun 9, 2021

Hello @junegunn ,

I have a usecase where I would like to reopen this issue.
My usecase is running some unit test in watch mode and piping it to fzf (this is a custom script that gets a lot of different information).

What I would like to do is that between each run, I would like to reload the data.

Currently, I need to relaunch the script (and the fzf instance) if I want to be able to see results only of the latest test.

I could send a unix signal to fzf to tell it to reload the data.

@edi9999
Copy link
Contributor Author

edi9999 commented Nov 4, 2022

Hello @junegunn,

I'm pinging you back on this because I can see a pattern in many of my fzf scripts where fetching the data to fzf would take some time (3-10 seconds), and I prefer to have an fzf instance running with the cached data during the download.

What I do is the following :

  • fetch the new data in the background
  • use fzf on the cached data
  • when seeing the data, decide whether I should reload fzf using the new data or not.

I would still find it very cool to be able, after the async fetching of data is done, to send a signal to the fzf instance to reload the data from the cache.

@junegunn
Copy link
Owner

Please take a look at #3094.

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

No branches or pull requests

3 participants