Remix.run Logo
bwhaley 5 hours ago

Once you start using CTRL+r, you may find that you never reach for up arrow again.

soraminazuki 36 minutes ago | parent | next [-]

Prefix search is faster for the majority of cases. CTRL-r / FZF is useful for the remaining ones.

pavel_lishin 4 hours ago | parent | prev | next [-]

I'm familiar with ctrl-r, but I still very much like the up-arrow behavior described by that commenter.

flir 2 hours ago | parent [-]

Looking at it from a "law of least surprise" angle, it's exactly how it should behave.

"I typed 'cd di↑' and you're giving me 'pwd'??"

kuschkufan 5 hours ago | parent | prev | next [-]

And once you want to one-up this look into fzf.

nidnogg 5 hours ago | parent [-]

And once you get tired of fzf and want something better, you reach for https://atuin.sh.

Completely transformed all of my workflows

seedie 4 hours ago | parent [-]

From the atuin.sh website

> Sync your shell history to all of your machines

I think of my shell history as very machine specific. Can you give some insights on how you benefit from history sync? If you use it.

Cyphus 3 hours ago | parent | next [-]

That feature is entirely optional and disabled by default. Atuin stores your shell history locally in a sqlite db regardless of whether you choose to sync it. I thought fzf was fast, but atuin makes it look slow by comparison.

foobarian 3 hours ago | parent | prev [-]

Same, I find shared history not very useful.

However what I do find useful is eternal history. It's doable with some .bashrc hacks, and slow because it's file based on every command, but:

- never delete history

- associate history with a session token

- set separate tokens in each screen, tmux, whatever session

- sort such that backward search (ctrl-R) hits current session history first, and the rest second

Like half my corporate brain is in a 11M history file at this point, going back years.

What I would love is to integrate this into the shell better so it's using sqlite or similar so it doesn't feel "sluggish." But even now the pain is worth the prize.

commandersaki 2 hours ago | parent | next [-]

I just want to give a perspective of someone that uses the 'eternal history' in bash per Eli Bandersky [1] and reluctance to use something like atuin (without/ignoring shared history).

First, as for speed and responsiveness, if there is a degradation, it is imperceptible to me. I wouldn't have a clue that my interactive shell is slowing down because it is logging a command to ~/.persistent_history.

My persistent_history is 4MB and has been migrated from machine to machine as I've upgraded, it's never felt slow to edit with (neo)vim or search with system supplied grep.

Eli's way of doing it also includes the timestamps for all commands, so it's easy to trace back when I had run the command, and duplicates are suppressed. In fact my longest persistent_history goes back to 2019-07-04, so I've been using it for quite some time now.

But the larger point I wanted to make is that I wouldn't feel comfortable switching this, in my opinion, quite efficient setup to displace it with an sqlite database. That would require a special tool to drill through the history and search rendering simple unix utilities useless. As Eli suggested, if your history gets too big, simply rotate the file and carry on. I have the alias phgrep to grep ~/.persistent_history, but I can easily have another alias to grep ~/.persistent_history*.

[1]: https://eli.thegreenplace.net/2013/06/11/keeping-persistent-...

fragmede 2 hours ago | parent | prev | next [-]

You don't have to setup shared history with Atuin if you don't want to and that's what's holding you back. Otherwise it hits the rest of your requirements. Just don't hesitate to change from the default config.

2 hours ago | parent | prev [-]
[deleted]
noisy_boy 3 hours ago | parent | prev | next [-]

export EDITOR=vi and then hitting Esc puts you into vi mode; k, j to move up/down through history or pressing / to search etc including using regex is all available.

BeetleB 3 hours ago | parent | prev [-]

There is a difference, I believe. Doesn't Ctrl+r do a substring search instead?

imglorp an hour ago | parent [-]

Yes it's different: it will match anywhere in the previous command lines.