How to disable history sharing?

[The-Judge]

Hello everyone,

after installing OMB, my shell history behaves weird: It seems like the history is shared between sessions now. When I open two iTerm2 windows and type something to the first one, that typing ends up in my shell history (pressing up key) of the other window.
I recorded a short screencast to demonstrate this, in which you also see the keys pressed:

https://youtu.be/iaW0mLbUhMc

This pretty much collides with what I am used to working with terminals and since this is active, it happened more than once that I execute a command in the wrong shell and context, already. And I consider it a matter of time before I accidentially cause harm with this.
So I'd like to disable that.

For "Oh-my-ZSH", I found this an often addressed thing already (Google for "oh my zsh disable shared history"). There, this can be disabled using unsetopt share_history, according to this issue: ohmyzsh#2537
But I did not find something similar for Oh-My-Bash.

I am using OMB with:

• Theme: agnoster
• completions=(git composer ssh)
• aliases=(general)
• plugins=(git bashmarks poetry)

Can someone point me to the correct resource or explain how to best do this, please?

[akinomyoga]

The themes doubletime*, nwinkler_random_colors, pete, and rainbowbrite contains the history-sharing setting, but agnoster doesn't contain such a setting as far as I know. One possibility is that you might actually use a theme that contains the settings for history sharing. Another possibility is that the plugin poetry in your plugins contains such the setting (Note: OMB doesn't seem to provide the plugin named poetry). Or even another possibility would be that there is a setting in /etc/profile.d/*.

To identify what causes the history sharing, could you provide the output of the following command?

$ declare -p PROMPT_COMMAND _omb_util_prompt_command

[The-Judge]

I've tried to reproduce my steps to find out where the plugin poetry came from, but I could not remember. Since that insight alone was reason enough to deactivate it, I did so.
Restarting two shells after that did not change this history behavior. So: Plugin Poetry is now gone, but the history - issue persists.

So, after that, I disabled OMB completely to ensure 100% that it came with enabling it, and yes: As soon as OMB is not sourced from my .bashrc anymore, the issue is gone and shell instances do not share history anymore.
After that test, I re-enabled OMB.

With OMB enabled, declare -p PROMPT_COMMAND _omb_util_prompt_command returns:

declare -ax PROMPT_COMMAND=([0]="history -a; history -n; " [1]="_omb_util_prompt_command_hook")
declare -a _omb_util_prompt_command=([0]="history -a" [1]="_omb_deprecate_const__sync" [2]="_omb_theme_PROMPT_COMMAND")

PS: I also tried to choose font instead of agnoster for a theme and repeated the history-test. The result is that I have the same issue with font; so I think we can stop looking at the theme as a possible source for the behavior.

[The-Judge]

I looked a bit into this myself now and it leaves me quite puzzled:

I found in ~/.oh-my-bash/oh-my-bash.sh lines 104-112 load all files in lib/, ending in {bash,sh}.
In lib/history.sh lines 28-29:

# Record each line as it gets issued
_omb_util_add_prompt_command 'history -a'

I'm using the Homebrew-bash on my Mac, which is 5.2.15. There, history -a does:

-a     Append the ``new'' history lines to the history file.  These are history lines
       entered since the beginning of the current bash session, but not already appended
       to the history file.

And history -n, which is also part of PROMPT_COMMAND, does:

-n     Read the history lines not already read from the history file into the current
       history list.  These are lines appended to the history file since the beginning
       of the current bash session.

With history -a and history -n (as can be seen in the output of declare -p PROMPT_COMMAND _omb_util_prompt_command I pasted before) being in PROMPT_COMMAND like this, these two commands are executed each time a prompt is rendered; so: After each command, which seems to be exactly the behavior I am witnessing:
Since history -a is executed after each command entered, it is added to the history file, immediately. And since history -n is also executed after each command, the lines added to the history file from another shell are also loaded into the current shell history.

What puzzled me is that with OMB sourcing disabled, PROMPT_COMMAND also contains these two commands on my system, but it does not cause this behavior:

$ declare -p PROMPT_COMMAND
declare -x PROMPT_COMMAND="history -a; history -n; "
$

So my current guess is, that it's not OMB that "mixes" the history writing/reading from other shells, but messing up with the history access that happens when "UP" is pressed.

[The-Judge]

I now found the following:
As already shared: The PROMPT_COMMAND on my system is like this, even with OMB not sourced:

PROMPT_COMMAND="history -a; history -n; "

I now did some trial & error and found, that as soon as one of the two lines in lib/history.sh are set, my shells switch to that strange behavior:

• Line 37: HISTCONTROL="erasedups:ignoreboth"
• Line 40: export HISTIGNORE="&:[ ]*:exit:ls:bg:fg:history:clear"

When I comment out both, shells are back to expected history behavior.
When I have both or even one of them active, shells share the same "Up"-History.

[The-Judge]

Even more background: I found out that the element, which is responsible for my shells to have those two history commands (history -a and history -n) in PROMPT_COMMAND is a tool called hstr:

$ hstr --show-configuration

# HSTR configuration - add this to ~/.bashrc
alias hh=hstr                    # hh to be alias for hstr
export HSTR_CONFIG=hicolor       # get more colors
shopt -s histappend              # append new history items to .bash_history
export HISTCONTROL=ignorespace   # leading space hides commands from history
export HISTFILESIZE=10000        # increase history file size (default is 500)
export HISTSIZE=${HISTFILESIZE}  # increase history size (default is 500)
# ensure synchronization between bash memory and history file
export PROMPT_COMMAND="history -a; history -n; ${PROMPT_COMMAND}"
# if this is interactive shell, then bind hstr to Ctrl-r (for Vi mode check doc)
if [[ $- =~ .*i.* ]]; then bind '"\C-r": "\C-a hstr -- \C-j"'; fi
# if this is interactive shell, then bind 'kill last command' to Ctrl-x k
if [[ $- =~ .*i.* ]]; then bind '"\C-xk": "\C-a hstr -k \C-j"'; fi

Install instructions say to have these lines in any of the shell source files; note the line exporting PROMPT_COMMAND.

[akinomyoga]

So this is a bug of hstr. First of all, the strange behavior that you reported is actually the intended behavior of hstr. You might feel it strange, but not a small number of people want shared history intensionally. However, the hstr setting trying to use history -a; history -n is wrong and will not work by itself. Only with the settings from OMB, the setting sometimes seems to work by accident.

---

This is how history -a; history -n is wrong: By running history -a; history -n, Bash saves the new entries to the history file (which is shared by sessions) and reads new entries from the file. However, it will never work as expected because Bash only remembers which line to start to read from with history -n but that information is broken by the preceding history -a. Then, history -n results in reading the same entries that history -a has just written, which are not the expected entries.

This hstr setting only succeeds when there are no additional entries that history -a writes. In your case, I think it is achieved by HISTCONTROL or HISTIGNORE. When the previous command is not added to the history (because it matches the previous command or any pattern in HISTIGNORE) or the size of history is unchanged or reduced by erasedups in HISTCONTROL, history -a might not add entries in the history file. Only in that case, the subsequent history -n behaves as hstr expected.

It is also explained in the following Q&A:

• linux - Can history files be unified in bash? - Super User

Those who want the shared-history feature (including hstr) need to use history -a; history -c; history -r, which is a common practice. For example, it is described in the following Q&A:

• Preserve bash history in multiple terminal windows - Unix & Linux Stack Exchange

[akinomyoga]

It seems to be discussed in dvorka/hstr#400, but there, no one seems to be aware of what is the actual problem.

[The-Judge]

gg That's my understanding as well! Thank you very much for this enlightenment and sorry for hijacking your project to sort out hstr's issues - it was unintentional!

I thought about changing hstr's config lines, so this BS does not happen anymore, but after seeing these stupid, unrelated config suggestions of the project and noticing, that lots of hstr's functionality are provided by OMB's configs (like incremental history search with up/down arrows), I decided to get rid of the tool, entirely.

Thank you very much for your help!

[akinomyoga]

Thank you very much for this enlightenment and sorry for hijacking your project to sort out hstr's issues - it was unintentional!

I don't mind it at all! It is normal that we don't know the actual cause of a problem at the initial stage of the investigation.