For example setting:
export FZF_COMPLETION_TRIGGER='~~'
Will allow fzf completion for a commands. Just need to hit the key after ~~ and fzf will pop up:
git diff main..HEAD -- ~~
ls -lh ~~
271–280 of 292 posts
For example setting:
export FZF_COMPLETION_TRIGGER='~~'
Will allow fzf completion for a commands. Just need to hit the key after ~~ and fzf will pop up:
git diff main..HEAD -- ~~
ls -lh ~~
Earlier quoted context omitted.
I also had a rather noticeable delay when launching atuin. As it turns out, this was because it checked for an update every time it launched! You can disable that update check: add a ` update_check = false` to your `~/.config/atuin/config.toml` [1]. That made the delay pretty much disappear for me. [1]: https://atuin.sh/docs/config/#update_check
We actually fixed the delay issue, but since you disabled update checking you wouldn't have known to update! It was quite annoying so we're sorry for that
I'd never heard of fzf before! It looks like there's a lot of cool stuff you can do with it, but honestly, I think it's worth it even just to replace the frustrating ctrl+R search in bash, which I use a lot, but constantly dislike. I feel like with a lot of these kinds of tools, if I have to actually actively use them, I forget that they exist ('z'[0] ended up being like this for me) and eventually remove them, but s…
Also all of the tools discussed in this thread (and more) are listed here: https://github.com/ibraheemdev/modern-unix
I love fuzzy shell history. Game changer in terms of shell productivity. I use atuin[0] instead of fzf as I find the experience a bit nicer and it has history backups built in (disclaimer, I am a maintainer) Some of our users still prefer fzf because they are used to how it fuzzy finds, but we're running an experiment with skim[1] which allows us to embed the fuzzy engine without much overhead - hopefully giving them…
If that's your use case, here's another game changer (one line bashrc change to make bash_history changes immediately, rather than upon shell exit, e.g. when you end your tmux session): https://web.archive.org/web/20090815205011/http://www.cuberi...
I'd never heard of fzf before! It looks like there's a lot of cool stuff you can do with it, but honestly, I think it's worth it even just to replace the frustrating ctrl+R search in bash, which I use a lot, but constantly dislike. I feel like with a lot of these kinds of tools, if I have to actually actively use them, I forget that they exist ('z'[0] ended up being like this for me) and eventually remove them, but s…
It does require installing some version of command-line lua.
Two things I use fuzzy finder for: 1. flog: go to git branches I had checked out in the past quickly 2. pr: preview and check out PRs I've been assigned to review flog () { branch="$( git branch --sort=-committerdate --format="%(committerdate:relative)%09%(refname:short)%09%(subject)" \ | column -ts $'\t' \ | fzf \ | sed 's/.*ago \+\([^ ]*\) .*/\1/' )" git co $branch || ( echo -n "git co $branch" | pbcopy ) } errcho(…
I whipped up a nice, performant branch picker last night that I'm pretty happy with, hopefully there are some useful tidbits for others. It's similar to your `flog` command but it uses the reflog to find the most recently checked out branches. It filters those which have been deleted using a set structure (well, map of bools), thus requiring BASH 4+. I'll be interested to see the differences in behavior and performance of your approach
https://gist.github.com/pnovotnak/4dfe9b2867bf6fea60fa94b4c8...
I love fuzzy shell history. Game changer in terms of shell productivity. I use atuin[0] instead of fzf as I find the experience a bit nicer and it has history backups built in (disclaimer, I am a maintainer) Some of our users still prefer fzf because they are used to how it fuzzy finds, but we're running an experiment with skim[1] which allows us to embed the fuzzy engine without much overhead - hopefully giving them…
Fuzzy history is nice, but the real game changer for me was the ability to pretty much stop remembering paths in big projects. The default keybindings provide the Ctrl-T shortcut to insert a path/filename on the command line using fuzzy search and Alt-C to fuzzy-cd. No more tedious completion - just search + enter.
Interesting, I'm of the first kind, who uninstalled it quickly. I use ctrl-r a lot, though I have no issue remembering exact portions of the commands, but that may just be me. I'll give it another try. In the same vein as ripgrep (rg), I recommand the author (and everybody else) to give fd-find (fd) a try as a replacement to find. It's much, much faster (multithreaded search), and has better defaults to use from the…
if the article is saying to use 'fzf' to fuzzy-find things, why do we want to install 'fd' to multi-thread find things alongside fzf ? nvm. tutorial explains https://youtu.be/qgG5Jhi_Els?t=400
fzf is also more suited to interactive search, while fd is more of a "give me a list" thing.
Interesting, I'm of the first kind, who uninstalled it quickly. I use ctrl-r a lot, though I have no issue remembering exact portions of the commands, but that may just be me. I'll give it another try. In the same vein as ripgrep (rg), I recommand the author (and everybody else) to give fd-find (fd) a try as a replacement to find. It's much, much faster (multithreaded search), and has better defaults to use from the…
>`fd abc` is equivalent to `find. -iname 'abc'` If you don't want to install a tool just for this: fs() { find -iname '*'"$1"'*' ; } I don't really have big directories where speed would be a benefit, so haven't tried `fd` yet. I do use `ripgrep` but mostly for its features (like default recursive search respecting .gitignore, `-r` option, etc) over speed benefits.
time fd --type f 4.61 user 11.27 system 120% cpu 13.172 total Second run: 4.06 user 4.35 system 178% cpu 4.720 total
That's on an SSD. Admittedly, fd skips over hidden files and some directories by default. Adding them back (-u), it seems to take about the same time. 13.74 40.58 145% 37.324
Though it falls back to 13s if I disable colored output.
Piping these in wc -l to eliminate vt overhead, I have 1.4M matches, in about 5s for fd and 11s for find (warm runs, there is quite a bit of jitter). About 1s if I let fd skip hidden directories (.cache, .git, etc: 0.4M matches).
Point is, it's usually noticeably more responsive for realistic use-cases (and has colored output, parses .gitignore files, etc).
Earlier quoted context omitted.
Pretty much par for the course, Linux distributions don't do per user configuration of tools beyond appending to PATH or setting some essential environment variables using scripts in in /etc/profile.d/. They will most certainly not mess with login scripts.
Yeah sure, that makes sense. I'm surprised that the .deb doesn't install the stuff from `$upstream/shell` into `/usr/share/fzf` though. That's the sort of thing `/usr/share/$prog` is intended for . Then it would just be (in bash anyway): source /usr/share/fzf/keybindings.bash
source /usr/share/doc/fzf/examples/completion.bash
source /usr/share/doc/fzf/examples/key-bindings.bash