Per-session history about yash HOT 6 OPEN

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

from yash.

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?

from yash.

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?

from yash.

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.

from yash.

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.

from yash.

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.

from yash.