Trick to find commands in the terminal quickly | Hacker News Reader

Trick to find commands in the terminal quickly

github.com

97 pointsToby1VC77 comments

Install "fzf" [0] and set it up to be used with control+r, there's no going back. You get as a bonus the chance to use fzf in a lot of other places :)

I guess that more advance tool would be "atuin" [1], but it is too much for my use case.

[0] https://github.com/junegunn/fzf [1] https://github.com/atuinsh/atuin

I switched to atuin and it's a huge step up from native Ctrl + R and fzf because you can press Ctrl + R again and again and it switches between searching through directory, session, host, or global history.

I listened to an interview with the creator of atuin on the changelog podcast. It seems like a compelling idea. The only thing that makes me consider switching from the fzf/ctr-r combo is syncing my history between tmux sessions. But I don't spend enough time in the terminal to really justify the time to set it up.

Never heard of atuin but it looks awesome. I'm going to try it out.

Oh, looked at the feature set. Sounds interesting.

"Sync your shell history to all of your machines, wherever they are"

That sounds like a potential security issue though.

Just a note that this is an optional add-on that I don't use.

It also just uses a SQLite db, so you can sync it manually yourself if you want. But their implementation seems pretty secure.

Regardless, I just run it local only on each of my machines, separately. It’s still really helpful!

FWIW the sync server can be self-hosted.

Seconding `fzf`, it's such an improvement from the stock Ctrl-R behavior I think it's worth installing even if you never actually run `fzf` at the command line itself. Hence why I led with the new shortcuts at https://andrew-quinn.me/fzf (fuzzy `cd` with Alt-C being the other one of note).

Interestingly, the default fish shell also comes with something similar these days, although I still prefer the look of `fzf`.

fzf is also really good when you want to make interactive bash scripts (or recipes in Justfiles or Makefiles).

This has been a larger productivity boost for me than LLMs. I suppose I should use LLMs more.

+1 for `fzf`. And if you're using Oh My Zsh then check out fzf-zsh-plugin: https://github.com/unixorn/fzf-zsh-plugin

Came here to say this. Fzf is almost too good, it's so convenient to find past commands that I've gotten two years into a career as a software developer without committing any of my most common command line tools to memory.

Interesting.

For me, C-r is sufficient (and/or M-r in Emacs, where C-r by default does reverse interactive search on the text in buffer; it's nice to have both at the same time, actually). However, I must have skipped some education about shell history and/or its default settings, because half the time I need it, the command I want isn't there to be found. I also observed the following kinds of behaviors:

- Sometimes, shell history seems to be scoped (or reacting to) current working directory;

- Sometimes, commands executed on remote machines end up being saved in local history;

- When the shell gets killed (e.g. when Emacs crashes and takes down the shells open inside with it), or the system crashes, sometimes the history gets saved, and sometimes nothing remains from a session that spanned multiple days;

- When I have multiple terminals open, it's a coin toss whether only one will have history saved or all of them, and then another toss as to whether histories will be CWD-sensitive or not.

Is there a good primer/community consensus on how to configure shell so all history gets saved in sensible manner (including continuously, so it survives a crash)?

> Is there a good primer/community consensus on how to configure shell so all history gets saved in sensible manner (including continuously, so it survives a crash)?

I find that zsh is quite good at addressing some of the issues you mention.

Install fzf and ctrl-r will become much better.

Fzf has been a district before and after type tool for me. There's so many use cases for it, and the fuzzy search in history is amazing.

Yeah, for example I've started looking at making tui:s in go using tview and here fzf-tmux works great as a (multi-)select fuzzy find popup.

.. have added a gist in comments below, i got used to saving separate history files for each project and launch gnome-terminal with that .. and Ctrl-R within that scope

There are shell options you need to set to, for example, make shell history saving work when multiple terminals are used (the defaults are bad). Read the manual

Fish shell does not have this problems

You should definitely give atuin a try. It addresses all these things really well.

Just gotta set your bashrc!

   # Ensure history is written after every command, allowing it to persist across sessions
   shopt -s histappend  # Append to history instead of overwriting
   PROMPT_COMMAND="history -a; history -c; history -r; $PROMPT_COMMAND"

   # Set the history size (adjust as needed)
   HISTSIZE=50000   # Number of commands kept in memory
   HISTFILESIZE=1000000  # Number of commands kept in the history file

   # Add timestamps to history (format: YYYY-MM-DD HH:MM:SS)
   HISTTIMEFORMAT="%Y-%m-%d %H:%M:%S "

   # Ignore duplicate and space-prefixed commands
   HISTCONTROL=ignoredups:ignorespace

   # Save multi-line commands as a single entry
   shopt -s cmdhist

   # Allow history expansion with Ctrl + R
   bind '"\e[A":history-search-backward'
   bind '"\e[B":history-search-forward'

Also, if you are on shells you worry about, use gnu screen (or tmux if you prefer) imho. It will give you a second layer of history to be able to dig through.

For bash there’s oh-my-bash that comes with sensible defaults: https://ohmybash.nntoan.com/

This will do what you want: Append this to your .bashrc.

```export PROMPT_COMMAND="history -a; history -c; history -r; $PROMPT_COMMAND"```

-a = append to history file -c = 'clear' aka write the history file -r = reload

Every time you hit 'enter' this will add the command to the history file, and will reload your bash prompt history. That means that every terminal window will share a common history file and you don't need to close the TERM to 'save' the session to history.

This is ESPECIALLY helpful on remote (SSH) connections. Downside: You 'Up Arrow' history gets altered by every term window you have running. So you can't just blindly `up` to repeat a command.

It takes a little to get used to, but VERY handy.

This allows EV

https://github.com/cantino/mcfly

https://github.com/atuinsh/atuin

You're welcome.

atuin is the G.O.A.T.

+1 for autin, and in case anyone is wondering, it works on windows with e.g. git bash too. You just need to build it yourself.

came here to add atuin!

atuin forever. I'm never going back. My shell history will be curated in a sqlite db for the rest of my life.

Heavy user and I moved to Atuin because of the shell history scoping issue with regular bash history.

No matter my config it would always glitch. Atuin is backed by a global sqlite db: problem solved. And unlimited history.

I don't use sync though, commands sent to 3rd party servers are a no-go.

For these commands I want to rerun, but not often enough, I add a comment to the command like `yay - Sc # clear pacman and yay caches` so it's easier to search in the future

I use this a lot too, often with cherry-picks and reverts that can't be merged into this or that branch yet, too. It's very convenient and works everywhere without installing anything.

Oh man that's clever, I never thought of doing that!

I just add " ###" to the end of commands run frequently. It makes easier to identify important commands with atuin, fzf or plain bash/fish history search.

I prefix them with comments

    # sometag
    the --actual --command

"Bashtags" I call them, despite not actually being in bash these days.

Same, but as a suffix

> Instead of icons you could use text which you can grep later easily.

An obvious improvement! And if you're using text you don't even need to be watching out to recognise it, you can search with Ctrl-R.

The icon idea is cool. I do something similar but optimized for searching rather than identifying. I put a "tag" in front of my commands. Then I can type the command and press up.

For example

    mc= sexec nix-shell -p jdk17 prismlauncher --run 'exec prismlauncher -l 1.19.4 -s mc.example'

Will start the right version of Minecraft with the right version of Java. I just type mc<Up> to find it.

I use this for commands that I know I will want to reuse, but not frequent enough to always be near the top of my history. In this case I could probably search for "prism" and it would be good enough but for things like specific ffmpeg incantations it is hard to remember a unique part, so the tagging lets me give my own name to the command.

I wish history would differentiate between non commands errors and commands that ran without error.

Most of the time I don't need the rubbish I typed along the way in my history.

In fact, there's a system already in place, it's just that almost no one uses it and there's no codified convention.

Error code 22 is EINVAL, "invalid argument". If most of the CLI frameworks agreed to use it on invalid commands, shells could diferrentiate user errors and program errors and keep histories clean.

Adding this to POSIX Utility Conventions and GNU Coding Standards would be a great kickstart.

https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...

https://www.gnu.org/prep/standards/html_node/index.html#Top

Visual cues are welcome and can be very nice when applied effectively. For example, Readline has support for color highlighting: https://wiki.archlinux.org/title/Readline

I haven’t played with emojis in the terminal before. Wouldn’t this emoji trick depend on font support?

Ctrl+R for reverse search is okay but can get a bit tedious when looking for variations on the command.

If you "set -o vi" then (Esc)/ becomes reverse search.

Like vi in reverse, n goes further back, but N goes forward.

The "set -o vi" option is a POSIX optional feature, and should work in any compliant shell.

I’ll give it a try, might see if could integrate it into telescope for vim too because I find myself a bit slow when there using harpoon at the moment.

Using C-r is a little too much navigation overhead for me personally. For things that I'll need long-term, I just use a pair of aliases to add a new alias to my .bashrc and source it (alias vib='vim ~/.bashrc' and alias .b='source ~/.bashrc'). I also have 'vit' and 'viv' aliases to do the same thing for my .tmux.conf and .vimrc.

For short-term stuff, I use https://github.com/dp12/fastdiract to save frequently used commands and run them instantly with a two-key combo (f0-f9).

Clever approach, but one extra step for me.

I made a shell script "hg" which stands for "history | grep." So "hg .wine" brings up all commands in the bash command history buffer with the string .wine in them, say "1601 ls .wine" To run one of course you just enter ! and the number of the command. So like... !1601. Whole process is extremely ergonomic.

Although - if anyone wants to write a shell extension that always runs the command output in a separate panel and keeps the parent panel (or tab) to just the commands entered that would be cool too.

You can search the history with ctrl-r and then type the search. To make it even better use fzf as well.

> I made a shell script "hg" which stands for "history | grep."

Not a Mercurial user, I take it? (hg is the standard command for Mercurial.)

In the TXR Lisp repl, I implemented a feature I hadn't seen anywhere: submit a command recalled from history, and then move onto the next command in history. I assigned it to Ctrl-X Enter.

Turns out, Korn shell had this first: Ctrl-O. And newer Bash has it also.

You can repeat sequences of multiple commands in your history without having to navigate back to each one individually. Just find the first one and submit one by one with Ctrl-O.

Then I'd spend even more time looking for an icon I'd think represents best the command, and then looking for that icon in the emoji selector

Or use the right tools, like atuin[1] and hoard[2], to manage your shell history and preserve frequent/favorite commands.

[1] https://terminaltrove.com/atuin/

[2] https://terminaltrove.com/hoard/

I always found it most useful to have up and down arrows search through history for what I've already typed. So to run my tests via Gradle, I usually just type ’.g‘ followed by up arrow.

I think I set it up with ‘‘‘ "\e[A": history-search-backward "\e[B": history-search-forward ’’’ (Not near a computer right now to confirm)

I find this somehow much faster than C-r

sligthly ontopic of emoji commands on shell for dyslexics and/or visual people, here's one i use often https://github.com/gcb/emojihash.sh?tab=readme-ov-file

Ctrl+R followed by key parts of it.

Yes, this. For example, `Ctrl+R makedo` would go back in history to the first command that matches this, to use the ` ./scripts/makedocs.sh` example from the article.

And Ctrl+s goes forward in history, but if you don’t have flow control disabled you might think your terminal became frozen in time. Ctrl+q will resume the flow in that case.

Also got to watch out for Ctrl+d on qwerty kb layouts where s and d keys live side by side.

Yup. Then if you want to run the commands that you ran after it last time, hit `Ctrl+O` instead of `Enter` and the next command you ran will be pre-filled on the prompt.

I use television (https://github.com/alexpasmantier/television) with shell integration

so basically I end up doing ctrl-r, then fuzzy find the command and run it

I love making little bash scripts to improve my workflow, and I think everyone should do it, but-- on their own.

For example I have 'glast' to list the 5 previous git branches.

Or I have 'phelp' that basically lists the available commands in a package file.

The tool this guy is looking for is called "make". You build a makefile with the appropriate targets then you type "make check", "make build", "make debug", "make tag".

I made a tool some years ago to store commands in a dot files https://github.com/seiferteric/clamp

I usually copy and paste my bash history to a LLM and ask questions. But I also use Ctrl (Cmd) + R for a exact keyword search.

The first thing I add to my shell RC file is 'set -o vi'

Then I can use the vi/vim search keys

- escape

- '/'

- <type words>

- hit n or N to move back and forth

Way way easier than using the up or down arrow.

Unless you use emacs, then the shell history keys seem normal

POSIX outlines vi mode, but emacs is not mentioned.

"vi - Allow shell command line editing using the built-in vi editor. Enabling vi mode shall disable any other command line editing mode provided as an implementation extension."

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

Fair fair. I guess the most important thing is that you pick one style of efficient command line searching and editing and run with it.

If you have a command you run over and over, make an alias for it. That way if your shell history gets clobbered you still have it.

$ <some long command I will probably need later> # <some memorable name>

Later, search for <some memorable name>

Emojis are underutilized in so many ways. THis is a fun way. Are there other ways? Sure. This is one of them.

.. another cheap trick .. when juggling different projects i keep a separate history file for each under ~/.histories/ .. shameless plug to my gist .. bash script that launches gnome-terminal with a named history file ..

https://gist.github.com/appsmatics/ff27e885460bd345eabe1c5f7...

genius!

bravo! you can also search with grep, I did not know!

``` history | grep ICON ```

especially for many, like me, who cannot change shell... since we are not working with our pc, but we are SSH connecting to plenty of different servers

zsh-autosuggestions is very useful!

Ctrl shift R

do you mean

CTRL+r

CTRL+R (so Ctrl shift R)

I've tried, and see no difference: what should it be?

shift usually means to go backwards.

So ctrl shift R goes from the latest command backwards that fit your search term.

Oh I see, ctrl R does the same thing interesting.

Reply on news.ycombinator.com