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)?
And the next lesson: C-r will search the command history (at least in most *nix shells). So when needing to do something but you aren't sure how far back it was (not on the screen or not recallable) but you know it is in the history and some text in it, just C-r <something> [C-r repeatedly until you get to the correct version].
I do not disagree about the shell history being very important. Some histories do end up getting truncated at a set interval. That was the main reason I brought up tracking this command trail at some point close to the task being completed.
Note that I think that's a Bash thing, and the default is Emacs-style bindings (C-a, C-e, C-p, C-n) which include C-r for reverse interactive search of the history. I use that every day, a dozen or more times.
Wow, cool! How does this handle the case of multiple shells writing to the history at the same time? I have yet to find a safe way to preserve all that.
You can do the saving part automatically by setting a different history file automatically for each instance of the shell, for example using a timestamp on your rc file and force them to append after every command.
Then if you open a new shell and want history from a particular older shell you can do `history -r <filename>`
So it is an hybrid automatically saved, manually recovered mode.
Which shell are you using? With fish I find that it's history is somewhat context sensitive based on the present directory. Because of this I've found myself less frustrated when working with the history across multiple tabs.
That's pretty much it. I used to have to use quite a few different shells, so `<CTRL> + r` wasn't always available, but `history | grep` usually was. Once I'd got in the the habit of using `history | grep` I found that I liked the extra context provided by seeing a group of commands with a few variations between the lines. So often it helps jog my memory of what parameters I'll need to change before using it.
Some people dislike it, but I LOVE it. I like being able to run a command, open a new terminal, and be able to control-r to find that command again. It ensures that I don't have race conditions over which terminal writes its history to disk first, as well, so I lost far fewer (zero?) history elements.
Modern shells are powerful enough to help you remember, if you learn to configure them appropriately. My histories are always saved because each shell instance gets its own HISTFILE, like so:
export HISTFILE=$HOME/.history/${TTY##\*/}.$SHLVL
As I use different terminal windows for different tasks, this keeps history files rather concise thematically.
And I let the shell add timestamps too, so I can grep for entries produced during a certain time span:
zsh:
setopt EXTENDEDHISTORY # add timestamps
bash:
HISTTIMEFORMAT="%F %T "
I write perl or shell script files, of course, if it's more than some a handful of lines.
If any one has tried this, can you confirm whether it copes with having multiple shells overwriting the history files
There is nothing more disappointing than not being able to find the cool command line I used a week ago because the shell I opened briefly and forgot about has overwritten it - maybe that's my poor setup though
Wow so it looks like I'm in the minority in having shell command history disabled? I have a small number of commands (20) that go into the live history of login shells for convenience, but nothing gets saved when I log out.
If there's something I do repeatedly, I make an alias or a function for it.
It seems like Bash history was made for a time that is long gone, and has not been fixed to work in a modern environment. I have tons of shells open, and I cannot promise to close them carefully and sequentially.
That's a cool idea. I have a similar, but less elegant setup: I just append every single command that I type to a global (synchronized between machines) history file, one file per month, then I use fzf to search through these when I need something (which is plugged into the usual ^R shell binding). Every command I've typed over the past couple of years is accessible immediately that way.
It's not scoped by directory though, but I'm not sure I'd personally need that feature.
Except that this doesn't save commands which haven't finished yet, and it never saves the current pending command when the shell is killed (e.g. the user closes the terminal window or logs out or the SSH connection is broken).
Sometimes the rare, long-running commands are the most valuable.
If I set up history software, it should preserve all history, and as early as possible.
Even with that command line, shell history needs to be disabled, or the shell needs to be configured to filter when it saves history (for example, the bash ignorespace HISTCONTROL option is useful here). This is, of course, shell specific.
Agreed, but even nicer than control-r are the readline functions `history-search-backward` and `history-search-forward`.
Personally I bind them to up/down which on OS X at least involves:
# Put this in some file like ~/.readline-bindings
"\e[A": history-search-backward
"\e[B": history-search-forward
# And this in your ~/.bashrc or ~/.zshrc
bind -f ~/.readline-bindings
That way if you haven't typed any input it behaves like normal up (previous command), but if you've typed some characters it only retrieves matching commands.
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)?
reply