Per-session history

[magicant]

(Feature request migrated from https://osdn.net/projects/yash/ticket/40964)

Is your feature request related to a problem? Please describe. Currently, all yash processes share a single command history if they share the same $HISTFILE value. This behavior can be unhelpful if the user is doing different tasks in separate shell sessions, especially working in different directories.

Describe the solution you'd like There should be a way to keep separate command histories for different shell sessions while still having a shared $HISTFILE value so that the history is merged and saved in the file when the shell exits.

---

https://osdn.net/projects/yash/ticket/40964#comment:3863:40964:1613307018

I was thinking of adding two options to change the shell's behavior. The first option can be used to disable the shell from reading new commands from the history file written by other shell instances. The second option makes the shell write the history when the shell exits rather than each time a new command is entered.

The second option, however, turned to be harder to implement than I thought at first. More precisely, changing when to write the history is not that hard, but it introduces possibility of accidental loss of history since the shell might be killed by a signal before it writes the history on exit. For safety, the shell should install signal handlers that catch signals that would kill the shell, and that will complicate the existing signal handling logic.

For now, I'm considering adding only the first option rather than implementing the both options at once.

[magicant]

To minimize the possibility of loss of data, the shell should write to the history file immediately after each command is entered, which is the current behavior. The shell reads the history file every time it prompts for a new command, which is also the current behavior but can be undesirable as the user may want to see the history of the current session only. It may be possible for the shell not to reflect new entries from the file so that each session will have its own view of linear history. The basic idea to achieve this is to add a flag for each entry in the shell session which indicates whether the entry is visible in that session.

Unresolved questions:

• How are entries numbered? Do separate sessions need to cooperate to avoid collisions?
• If we keep the current behavior of writing each command to the file immediately, the file will contain an interspersed list of commands from different sessions, and a new session will start with that list. Can we organize the history so that all entries from a session are grouped together?
• Do we need to change the history file refreshing mechanism to support this?
• Do sessions can safely coexist when some of them have this feature enabled and some don't?

[vext01]

One possible scheme:

• the history file is loaded into memory at startup
• each shell immediately writes history to the history file AND into to the in-memory copy
• after the initial load from disk, history is only ever read from the in-memory copy.

The only thing that could be annoying about this is that sometimes you do actually want to get a history line that was created by another shell, but was added to history since your current shell has started.

I think ideally I'd like a scheme where history from all instances is available, but history from the current shell is given priority. I don't know how to efficiently implement that though...

Difficult problem... How does fish shell do it?

[vext01]

You could do something like:

• At startup, give each shell a "probably unique" ID (say, a random 32/64-bit number)
• When writing a history line into the history file, include the ID of the shell with the line.
• When searching history, prioritise entries with the current shell's ID, but maintain the order of all entries with the same identifier.

In the rare case of a identifier collision, the user would see some history from another shell...

Supposing there is a collision, the chances of two active shells having the same ID is even more slim. It's way more likely that the collision is with a long-dead shell, meaning that history entries from the dead shell will be older than the current-shell's entries.

This means that pressing the up arrow is highly likely to only show the previous entry from the current shell.

[vext01]

A refinement to the above: when an instance writes it's first line of history into the histfile, it could check that no other entry in the file used the same ID. If one did, it should re-generate its ID and check again (until there are no collisions).

I don't think this can be made totally race free (without something like advisory locks, which might be a bad idea for a shell), but it minimises the probability of an ID collision yet more.

[vext01]

Having thought about this more:

For now, I'm considering adding only the first option rather than implementing the both options at once.

This would give users most of what they'd want.

If at some point you want to get history items from anther shell, you could do exec yash.

[rofl0r]

maybe until this gets resolved, someone (preferably a shell master) could write a properly working bash-history emulation using a .yashrc snippet like the one i posted in the original bug report on osdn. the one i use is "good enuff" but far from perfect, and it still doesn't work (i.e. not update the histfile) when SIGHUP is sent.

the current version i use is this:

MYHISTF=~/.yash_history_raw
test -e "$MYHISTF" || touch "$MYHISTF"
history -r "$MYHISTF"
MYHISTF_LINES=$(history | wc -l)

save_hist() {
history -w "$MYHISTF".$$
nl_count=$(wc -l "$MYHISTF".$$ | cut -d " " -f 1)
added=$((nl_count - MYHISTF_LINES))
{
 flock -x 3
 tail -n $added "$MYHISTF".$$ >> "$MYHISTF"
 flock -u 3
} 3>"$MYHISTF".lock
rm -f "$MYHISTF".$$ "$MYHISTF".lock
}
#trap 'exec </dev/null' HUP
trap save_hist TERM EXIT
fi