hstr: hstr shouldn't use .bash_history as data source and not advertise to use "history -n" in PROMPT_COMMAND

Hey.

Not sure whether the following would really work in the end, but perhaps it’s a better way of handling things.

AFAIU there are actually two histories…

• the in-memory one of each shell process, which is what’s actually used by bash itself, e.g. by the built-in-command history, bash’s Ctrl-r or UP-key.
• the history file (typically .bash_history), more or less “shared” by all open bash shell processes and either overwritten or appended to when a shell process quits (or when calling history with some parameters).

Also, AFAIU, there are basically two ways to use hstr:

1. without PROMPT_COMMAND="history -a; history -n"
2. or with

Each of them has problems associated:

(1): When not using PROMPT_COMMAND="history -a; history -n", then newly entered commands in this shell won’t get appended to the history file until the shell quits. This also means, that any invocation of hstr won’t see those commands, which is obviously bad.

(2): When using PROMPT_COMMAND="history -a; history -n", then newly entered commands will get appended to the history file immediately. While this solves the problem of not seeing newly entered commands of this shell it makes things pretty messy when using multiple shells:

Example, with two shells (the comment after each command is the order in which commands were entered in the two shells): Shell I:

$ aaa #1
$ bbb #2
$ ccc #4

Shell II:

$ AAA #3
$ BBB #5

Looking at the actual .bash_history things look as expected:

aaa #1
bbb #2
AAA #3
ccc #4
BBB #5

But looking at the in-memory-histories of the two shells (which is what will also be used for e.g. the UP-key) things are pretty messed up: Shell I:

 5032  aaa #1
 5033  bbb #2
 5034  ccc #4
 5035  ccc #4

Shell II:

 5032  AAA #3
 5033  bbb #2
 5034  AAA #3
 5035  BBB #5
 5036  BBB #5

Some entries are doubled, some are even missing. Strangely they’re still missing when entering further commands (so it’s not just one further missing reading of the history file), guess that’s because of how bash appends/merges the history to/from the history file.

The whole thing can get even quite disastrous when people don’t expect this behaviour, especially when e.g. multiple people use the same user account (role accounts like root), consider in chronological order e.g.: User A: $ date User A: # presses UP key, gets date again, presses ENTER User B: $ cd tmp User B: $ rm -rf * User A: # presses UP key, gets date again, presses ENTER

It’s not so unlikely, that A does this so fast (not expecting rm -rf might show up, that he actually executesrm -rf * wherever he is.

A partial solution for this might be to not advertise people to use: PROMPT_COMMAND="history -a; history -n" but rather just PROMPT_COMMAND="history -a" that way changes from other shells wouldn’t be read in again (only for newly started shells).

This has however still the behaviour that commands are immediately appended to the history file, which has the following properties: Since hstr uses the history file as data source, commands from other shells will show up immediately in this shell This can be both, an advantage:

• one will get commands from other shells in the history

and disadvantage:

• one will get commands from other shells in the history (in the sense, it clutters mixes up the linear history (e.g. when using the raw-history view). Also it can again lead to unexpected results, when doing quick incremental searches. User A: might expect “Ctrl-r f ENTER” to execute his most recently entered “firefox --profile foo & exit”, while he’ll actually get User B’s “rm -rf” which was more recent in the history file.

I think the disadvantage overweights by far,… it’s effectively the same problem as above just with hstr and not the UP key or Bash’s Ctrl-r (after all, a user might have kept Bash’s Ctrl-r for use and bound hstr to another key).

I think the following could possibly solve this: Don’t use the history file at all as a data source, except perhaps when deleting commands from it. Instead have someting like like “history | hstr --” bound to the key. hsrt would then need to read the history from stdin (removing a portion of something like “^\(\*\|\)[[:digit:]]* *” from it’s beginning - the history entry numbers might be prefixed with *).

The same would need to be done for directly invoking hstr, e.g. something like alias hstr='history | hstr'

Has the advantage of not getting messed up with history file manipulations of other shells, while still seeing new commands in this shell. No need to set any PROMPT_COMMAND at all, no need to sync the file after each command (which can easily cause defragmentation especially on CoW filesystems).

Deleting an entry would also need to be done via the buil-tin history -d offset and no longer affect the histories of other shells unless these are re-loaded. But I think it would have the advantage of not having to write to the history file, which bash probably doesn’t expect anyone elese to ever do.

Cheers, Chris.