You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The latter would allow piping the output of other commands directly to fzf without needing to write the output to a file first.
Not sure if this is stretching the purpose of fzf too far...
EDIT: I'm aware of the tools that make jq interactive, or other tools like fx, jless, jellex, etc. that are also interactive JSON viewers, but using fzf has the benefit of both:
being generic and being able to turn virtually any other tool interactive, and
The standard input is a stream; we can't restart a stream. What fzf can do, is hold the raw input in memory and feed it to its child processes. But of course, that is not equivalent to rerunning the original command, so it may confuse the users.
(date;echo$RANDOM) | fzf
And I don't think fzf having to hold the original raw input in memory just in case the child process may use it can be justified.
Since the suggested feature doesn't solve a problem that can't be circumvented, I'm going to pass on this one, but thanks for the suggestion.
man fzf
)Info
Problem / Steps to reproduce
Hi 👋
Following up on #1723 for using fzf as a visualization tool rather than a filter, I'm trying to use fzf to turn jq into an interactive tool.
I'd like to be able to make the command in
--bind
receive the original stdin that fzf received. So instead of:I would instead be able to do something like:
The latter would allow piping the output of other commands directly to fzf without needing to write the output to a file first.
Not sure if this is stretching the purpose of fzf too far...
EDIT: I'm aware of the tools that make jq interactive, or other tools like fx, jless, jellex, etc. that are also interactive JSON viewers, but using fzf has the benefit of both:
The text was updated successfully, but these errors were encountered: