You are not logged in.
Pages: 1
Hi,
this line is part of a script I use
DIR=$(fd -t d -a | fzf --preview="tree -C -L 1 {}" --bind="space:toggle-preview")
This used to work fine but I always wondered why fd terminated as soon as one the entries piped into fzf was selected.
However, something changed and since a few days or maybe weeks fd keeps running, no matter whether something got selected.
It would be great if someone could give me a clue why this happens and how to fix that.
Last edited by jaywk (2023-08-05 16:14:42)
Offline
I'd say that fd probably responded to input on the terminal and now doesn't.
https://archlinux.org/packages/extra/x86_64/fd/ has however not been updated since 2½ months…
fzf hasn't been uzpdated for 1½ months
So check your pacman log what changed "a few days or maybe weeks" ago.
how to fix that
Errrr… fix *what*?
Edit: wait a second, what exactly do you mean by "as soon as one the entries piped into fzf was selected" (esp. the "selected" part)?
Do you mean fd continues after fzf terminated??
top -b | fzf
does top continue when fzf terminates?
Did you test the behavior outside your script?
Last edited by seth (2023-08-04 19:41:26)
Offline
Yes exactly, fd continues running after fzf terminated
(and fzf terminates when I select something of the list by pressing enter - that's what I meant by 'selected')
Yes, I tested this also outside of my script.
Just running
fd | fzd
leads to the same behaviour. fd keeps running after fzf terminated.
When trying
top -b | fzf
top needs a second to termiate.
And yes immediately terminates when fzf terminated when running the following command
yes | fzd
Last edited by jaywk (2023-08-04 20:14:29)
Offline
Figured as much (I initially thought you meant when sel… moving the cursor
fd keeps searching, but not finding, maybe something about the search path changed:
https://unix.stackexchange.com/question … terminates
Offline
I mean fd doesn't run forever. It runs as long as it normaly does when you just run fd alone (without piping its output to fzf).
The point is, somehow fd now doesn't stop running after fzf terminated, which it did some days or weeks ago.
And thank you for the link, this looks very promising.
Last edited by jaywk (2023-08-04 20:47:49)
Offline
fd will stop the moment it realizes the pipe is gone.
It realizes the pipe is gone when it wants to write something there.
If wants to write something there when it finds something to write.
If it doesn't find anything (in a while) it won't write, won't realize that the pipe is gone and won't terminate.
So what has changed is the results, previously it would find more stuff more frequently, now it doesn't and just searches on.
If you're certain that't no the case (ie. fd would find and print lots results after fzf terminated): did you alias it?
type fd
Offline
I mean fd doesn't run forever. It runs as long as it normaly does when you just run fd alone
Which should be a split second. How long is fd running? Given that the pipe and fzf don't seem to be relevant here, the only question is why fd is not finishing promptly, and that can be explored much more simply by leaving out the pipe and fzf for all diagnostics.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Online
Perhaps cyclic directory symlinks?
Does the regular-ass "find" behave the same?
Offline
Thanks again for your clues.
Regular-ass find does not behave the same.
And yes, it seems like there are cyclic directory symlinks.
I looks like the /proc directory is the 'culprit'.
Running fd /proc doesn't terminate while find /proc does.
So simply excluding /proc in the fd-search fixes the problem.
Offline
Pages: 1