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.
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 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.
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.
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`.
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.
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’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.
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.
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
# 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.
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.
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."
.. 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 ..
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
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)
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).
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?
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.
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.
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.
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.
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".
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.
reply