I typed a bunch of commands and when I ran history
I saw they were not present in there.
Beside the case when the command start with a (space) what are the cases when commands will not be logged in history?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this communityI typed a bunch of commands and when I ran history
I saw they were not present in there.
Beside the case when the command start with a (space) what are the cases when commands will not be logged in history?
You've already mentioned the leading space, and another answer has mentioned settings that will intentionally change what is saved in the history such as the HISTIGNORE
setting and simply turning history off.
Another scenario is multiple interactive shells run by the same user. The Z shell has a share_history
option that makes it possible to have more than one Z shell instance updating a shared history file. It re-reads the file looking for new entries, and it applies timestamps to each entry.
The Bourne Again shell does not have this built-in (albeit that one can sort of do so using shenanighans to execute commands when the prompt is printed). The default history file behaviour that this is altering is that neither shell expects anything other than itself to be writing to the history file, and does not update the history after every command line executed.
The default behaviour in the Bourne Again shell, specifically, only updates the history file when the shell exits or one explicitly tells it to with the history
command. This means not only that one shell will simply overwrite the history written by another when a user has multiple interactive shell sessions; but also that it is possible for a shell that is not terminated cleanly to not write out the history file and thus to lose whatever command history occurred between the shell being uncleanly terminated and its last (explicit) update of the history file.
The history in mostly controlled by shell parameters.
HISTCONTROL
HISTCONTROL
is one of these parameters.
Here is what man bash
says:
HISTCONTROL
A colon-separated list of values controlling how commands are
saved on the history list. If the list of values includes
ignorespace, lines which begin with a space character are not
saved in the history list. A value of ignoredups causes lines
matching the previous history entry to not be saved. A value
of ignoreboth is shorthand for ignorespace and ignoredups. A
value of erasedups causes all previous lines matching the cur‐
rent line to be removed from the history list before that line
is saved. Any value not in the above list is ignored. If
HISTCONTROL is unset, or does not include a valid value, all
lines read by the shell parser are saved on the history list,
subject to the value of HISTIGNORE. The second and subsequent
lines of a multi-line compound command are not tested, and are
added to the history regardless of the value of HISTCONTROL.
Type echo $HISTCONTROL
to see how it is set for you.
My guess is that you have erasedups
enabled and commands are missing, because they have been reused at a later point.
HISTIGNORE
It is also possible to completely ban certain commands or patterns from appearing in the history.
Type echo $HISTIGNORE
to see which are banned for you. The list of patterns is separated by colons :
. It is also possible to ban a pattern like history*
would ban all commands starting with the word history.
Disabled history
Also the history can be disabled althogher.
If none of these cases applies to you, you could clarify your question, by adding a sequence of commands not fully preserved in the history.
~/.bash_history
for me. With mutliple shells it becomes a problem how and when to save, so nothing is lost. Crashes likely increase this problem.
Sep 18, 2017 at 13:44