Not sure where this falls on your compatibility of whatever it is you're doing but why not just use separate user accounts on the server? Also, another +1 for screen multiplexing. I fall into the same "been using screen -------- Original message -------- From: Jon Schewe <jpschewe at mtu.net> Date:01/06/2014 8:58 PM (GMT-06:00) To: TCLUG Mailing List <tclug-list at mn-linux.org> Subject: Re: [tclug-list] assigning tty to ssh session 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. 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. On Mon, Jan 6, 2014 at 10:39 AM, Mike Miller <mbmiller+l at gmail.com> wrote: 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? 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. Mike On Sun, 5 Jan 2014, Gavin Purcell wrote: Maybe tmux or screen could be of use. On Sun, Jan 5, 2014 at 8:50 PM, Mike Miller <mbmiller+l at gmail.com> wrote: On Sun, 5 Jan 2014, Erik Anderson wrote: I'm curious to hear about *why* you are separating your HISTFILEs, though. My guess is that you have a set of different ssh session "types", and you want to be able to isolate history entries for each function. Is that correct? I'll have maybe 10 connections open to the server at once and each of them will be for my work on some project. So every connection is of its own type -- there is no sort of classification scheme, if that's what you were asking. Every time the command prompt returns, it writes the previous command to the HISTFILE: export PROMPT_COMMAND='history -a' So I have to use separate HISTFILEs or else the commands from different projects will be interlaced. If I don't write every command immediately to a histfile, when the sessions are killed by power failure or network outage, I'll lose all the command histories. I have ways to work around the tty issue using history commands, copying files, etc. But I can also get the tty I want, if it is unused, by occupying the lower /dev/pts/ numbers. This is working great for me, and I would recommend it strongly to others. I'm sharing the relevant lines from my .bashrc below. It would be great if anyone has anything to add or to correct. Thanks. Mike # Use multi_history? Change to "yes" if you will often have multiple # interactive bash shells running simultaneously on this system. This # will cause you to save multiple history files, one per shell -- see # HISTFILE info below. multi_history=yes ############################################## # # HISTORY settings # ############################################## # append to the history file on exit, don't overwrite it shopt -s histappend # If $multi_history=yes, then tty is used to create a different # $HISTFILE for every tty. This will be a big advantage for people # who have multiple interactive bash shells running simultaneously. # It is not recommended for people who only run one at a time. # if requested, add the tty to the name of the history file if [ "$multi_history" = "yes" ]; then export HISTFILE=~/.bash_history$(tty | sed 's|/|_|g') if [ ! -s $HISTFILE ] ; then if [ -s ~/.bash_history_init ] ; then cp -fp ~/.bash_history_init $HISTFILE else echo -e "#1\ncd" >> ~/.bash_history_init chmod 600 ~/.bash_history_init cp -fp ~/.bash_history_init $HISTFILE fi fi fi # immediately write every new command to the history file export PROMPT_COMMAND='history -a' # don't put duplicate lines in the history nor lines beginning with a space export HISTCONTROL=ignoreboth # For setting history length see HISTSIZE and HISTFILESIZE in bash(1) # Save 10,000 lines of history but 100,000 lines in the history file: export HISTSIZE=10000 export HISTFILESIZE=100000 # commands to ignore and not add to history (recommendation: do not # add "cd" to this list because doing so makes it hard to track the # default directory where commands were executed) HISTIGNORE='ls:laf:jobs:bg:fg' # set time format for history file display # in saved file, it uses seconds since 1/1/1970, but those can be converted # for viewing using this command (where 1234567890 is the date in seconds): # date +"%F %T" -d @1234567890 export HISTTIMEFORMAT="%F %T%t" ############################################## # # Prompt settings # ############################################## # somone wrote, "color prompt is turned off by default to not distract # the user: the focus in a terminal window should be on the output of # commands, not on the prompt" # Mike Miller disagrees -- when looking at the scrollback in the # command window, the focus often is on the prompt because the prompt # shows where the commands are. force_color_prompt=yes if [ -n "$force_color_prompt" ]; then if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then # We have color support; assume it's compliant with Ecma-48 # (ISO/IEC-6429). (Lack of such support is extremely rare, and such # a case would tend to support setf rather than setaf.) color_prompt=yes else color_prompt=no fi fi if [ "$color_prompt" = yes ]; then if [ "$multi_history" = "yes" ]; then # add tty info to prompt for multi_history PS1="\[\e]0;\u@\h : $(tty) : \w\a\]\n\[\e[32m\]\u@\h\[\e[34m\]:\[\e[36m\]$(tty) \[\e[33m\]\w\[\e[0m\]\n\$ " else PS1='\[\e]0;\u@\h: \w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' fi else if [ "$multi_history" = "yes" ]; then # add tty info to prompt for multi_history PS1='\n\u@\h $(tty) \w\n\$ ' else PS1='\n\u@\h \w\n\$ ' fi fi unset color_prompt force_color_prompt _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota tclug-list at mn-linux.org http://mailman.mn-linux.org/mailman/listinfo/tclug-list _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota tclug-list at mn-linux.org http://mailman.mn-linux.org/mailman/listinfo/tclug-list -- http://mtu.net/~jpschewe -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20140106/523ef2d0/attachment.html>