<div dir="ltr">I'm thinking tmux combined with your bashrc would work. I typically start a tmux session for each project. You could have your bashrc query tmux for which named session it is in and then create the name of the history file based on the tmux session and thus the project name. <div>
<br></div><div>Now that I think of it, this sounds like something I should do as well. However I run multiple bash sessions for the same project, so I'm not sure how to fix the interleave problem.</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Jan 6, 2014 at 10:39 AM, Mike Miller <span dir="ltr"><<a href="mailto:mbmiller+l@gmail.com" target="_blank">mbmiller+l@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Does either of those keep the command histories for multiple login sessions stored in separate files? My guess is "no," but that it still would help when a connection is lost. I have been wanting for years to learn to use GNU Screen but I haven't gotten around to it. Is there a good tutorial?<br>
<br>
If I weren't doing what I am doing, and the server crashed, I would lose all command histories. This way I lose nothing. I don't think screen would help unless it is continually storing its state and command history in a file.<span class="HOEnZb"><font color="#888888"><br>
<br>
Mike</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Sun, 5 Jan 2014, Gavin Purcell wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe tmux or screen could be of use.<br>
<br>
<br>
On Sun, Jan 5, 2014 at 8:50 PM, Mike Miller <<a href="mailto:mbmiller%2Bl@gmail.com" target="_blank">mbmiller+l@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, 5 Jan 2014, Erik Anderson wrote:<br>
<br>
I'm curious to hear about *why* you are separating your HISTFILEs,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
though. My guess is that you have a set of different ssh session "types",<br>
and you want to be able to isolate history entries for each function. Is<br>
that correct?<br>
<br>
</blockquote>
<br>
<br>
I'll have maybe 10 connections open to the server at once and each of them<br>
will be for my work on some project. So every connection is of its own<br>
type -- there is no sort of classification scheme, if that's what you were<br>
asking.<br>
<br>
Every time the command prompt returns, it writes the previous command to<br>
the HISTFILE:<br>
<br>
export PROMPT_COMMAND='history -a'<br>
<br>
So I have to use separate HISTFILEs or else the commands from different<br>
projects will be interlaced. If I don't write every command immediately to<br>
a histfile, when the sessions are killed by power failure or network<br>
outage, I'll lose all the command histories.<br>
<br>
I have ways to work around the tty issue using history commands, copying<br>
files, etc. But I can also get the tty I want, if it is unused, by<br>
occupying the lower /dev/pts/ numbers.<br>
<br>
This is working great for me, and I would recommend it strongly to others.<br>
I'm sharing the relevant lines from my .bashrc below. It would be great if<br>
anyone has anything to add or to correct. Thanks.<br>
<br>
Mike<br>
<br>
<br>
<br>
# Use multi_history? Change to "yes" if you will often have multiple<br>
# interactive bash shells running simultaneously on this system. This<br>
# will cause you to save multiple history files, one per shell -- see<br>
# HISTFILE info below.<br>
multi_history=yes<br>
<br>
<br>
##############################<u></u>################<br>
#<br>
# HISTORY settings<br>
#<br>
##############################<u></u>################<br>
<br>
# append to the history file on exit, don't overwrite it<br>
shopt -s histappend<br>
<br>
<br>
# If $multi_history=yes, then tty is used to create a different<br>
# $HISTFILE for every tty. This will be a big advantage for people<br>
# who have multiple interactive bash shells running simultaneously.<br>
# It is not recommended for people who only run one at a time.<br>
<br>
# if requested, add the tty to the name of the history file<br>
if [ "$multi_history" = "yes" ]; then<br>
<br>
export HISTFILE=~/.bash_history$(tty | sed 's|/|_|g')<br>
if [ ! -s $HISTFILE ] ; then<br>
if [ -s ~/.bash_history_init ] ; then<br>
cp -fp ~/.bash_history_init $HISTFILE<br>
else<br>
echo -e "#1\ncd" >> ~/.bash_history_init<br>
chmod 600 ~/.bash_history_init<br>
cp -fp ~/.bash_history_init $HISTFILE<br>
fi<br>
fi<br>
fi<br>
<br>
# immediately write every new command to the history file<br>
export PROMPT_COMMAND='history -a'<br>
<br>
# don't put duplicate lines in the history nor lines beginning with a space<br>
export HISTCONTROL=ignoreboth<br>
<br>
# For setting history length see HISTSIZE and HISTFILESIZE in bash(1)<br>
# Save 10,000 lines of history but 100,000 lines in the history file:<br>
export HISTSIZE=10000<br>
export HISTFILESIZE=100000<br>
<br>
# commands to ignore and not add to history (recommendation: do not<br>
# add "cd" to this list because doing so makes it hard to track the<br>
# default directory where commands were executed)<br>
HISTIGNORE='ls:laf:jobs:bg:fg'<br>
<br>
# set time format for history file display<br>
# in saved file, it uses seconds since 1/1/1970, but those can be converted<br>
# for viewing using this command (where 1234567890 is the date in seconds):<br>
# date +"%F %T" -d @1234567890<br>
export HISTTIMEFORMAT="%F %T%t"<br>
<br>
<br>
<br>
##############################<u></u>################<br>
#<br>
# Prompt settings<br>
#<br>
##############################<u></u>################<br>
<br>
# somone wrote, "color prompt is turned off by default to not distract<br>
# the user: the focus in a terminal window should be on the output of<br>
# commands, not on the prompt"<br>
# Mike Miller disagrees -- when looking at the scrollback in the<br>
# command window, the focus often is on the prompt because the prompt<br>
# shows where the commands are.<br>
force_color_prompt=yes<br>
<br>
if [ -n "$force_color_prompt" ]; then<br>
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then<br>
# We have color support; assume it's compliant with Ecma-48<br>
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such<br>
# a case would tend to support setf rather than setaf.)<br>
color_prompt=yes<br>
else<br>
color_prompt=no<br>
fi<br>
fi<br>
<br>
if [ "$color_prompt" = yes ]; then<br>
if [ "$multi_history" = "yes" ]; then<br>
# add tty info to prompt for multi_history<br>
PS1="\[\e]0;\u@\h : $(tty) : \w\a\]\n\[\e[32m\]\u@\h\[\e[<u></u>34m\]:\[\e[36m\]$(tty)<br>
\[\e[33m\]\w\[\e[0m\]\n\$ "<br>
else<br>
PS1='\[\e]0;\u@\h: \w\a\]\n\[\e[32m\]\u@\h<br>
\[\e[33m\]\w\[\e[0m\]\n\$ '<br>
fi<br>
else<br>
if [ "$multi_history" = "yes" ]; then<br>
# add tty info to prompt for multi_history<br>
PS1='\n\u@\h $(tty) \w\n\$ '<br>
else<br>
PS1='\n\u@\h \w\n\$ '<br>
fi<br>
fi<br>
unset color_prompt force_color_prompt<br>
<br>
______________________________<u></u>_________________<br>
TCLUG Mailing List - Minneapolis/St. Paul, Minnesota<br>
<a href="mailto:tclug-list@mn-linux.org" target="_blank">tclug-list@mn-linux.org</a><br>
<a href="http://mailman.mn-linux.org/mailman/listinfo/tclug-list" target="_blank">http://mailman.mn-linux.org/<u></u>mailman/listinfo/tclug-list</a><br>
<br>
</blockquote>
<br>
</blockquote>
______________________________<u></u>_________________<br>
TCLUG Mailing List - Minneapolis/St. Paul, Minnesota<br>
<a href="mailto:tclug-list@mn-linux.org" target="_blank">tclug-list@mn-linux.org</a><br>
<a href="http://mailman.mn-linux.org/mailman/listinfo/tclug-list" target="_blank">http://mailman.mn-linux.org/<u></u>mailman/listinfo/tclug-list</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><a href="http://mtu.net/~jpschewe" target="_blank">http://mtu.net/~jpschewe</a><br><br></div>
</div>