HISTFILE question...
George W. Fleming
I am running bash (1.07.cwru) with X11. Each xterm window that I bring
up gets by default ~/.bash_history as the history file (I think). I
noticed that (by some mysterious ways) that each shell (after a period
of time) seems to update the .bash_history file, but not immediately.
The consequences of this is that I cannot recall commands that I just
entered in a different window. It is possible to make the history file
sort of window-transparent?
To carry it a step further, it is possible to have all users (and all
their bash processes) share a single history file? I very often use
the 'su' command and it would be nice to recall a command that I entered
before the 'su'.
Any info would be appreciated.
--
-------------------------
George W. Fleming
g...@sapphire.bellcore.com
-------------------------
Chet Ramey
>Is it possible for various bash processes to share a single HISTFILE?
With great difficulty. It requires flushing the commands to the history
file after each is executed, which probably would require source changes.
Bash really wants to do everything in memory.
Ksh can do this because it does not do everything in memory, but jumps
through hoops synchronizing access to a file, with everyone keeping an
open copy.
>I am running bash (1.07.cwru) with X11. Each xterm window that I bring
>up gets by default ~/.bash_history as the history file (I think). I
>noticed that (by some mysterious ways) that each shell (after a period
>of time) seems to update the .bash_history file, but not immediately.
You can specify $HISTFILE in your startup files. I have one per host
that shares my home directory, all under a blanket .histfiles directory
(HISTFILE=~/.histfiles/$(hostname)).
Each bash process reads the contents of HISTFILE when it starts up (look
at the call to load_history() in shell.c). When the file is read, it is
automatically truncated contain no more than the number of lines found
in the value of $HISTFILESIZE, which defaults to the value of $HISTSIZE.
The function that actually does the truncation is history_truncate_file(),
which is called from sv_histfilesize(), which is called from load_history()
via stupidly_hack_special_variables().
Chet
--
Chet Ramey Internet: ch...@po.CWRU.Edu
Case Western Reserve University NeXT Mail: ch...@macbeth.INS.CWRU.Edu
``Now, somehow we've brought our sins back physically -- and they're pissed.''
Dan R. Greening
>
>With great difficulty. It requires flushing the commands to the history
>file after each is executed, which probably would require source changes.
>Bash really wants to do everything in memory.
>
>Ksh can do this because it does not do everything in memory, but jumps
>through hoops synchronizing access to a file, with everyone keeping an
>open copy.
I don't think that bash should try to resynchronize the history file all
the time, or at least not by default. On networked systems this causes a
MAJOR (and I really mean MAJOR) slowdown at login time. Furthermore,
the problem is not easy to locate.
This is an existing problem with ksh. You resolve it by doing
something like "export HISTFILE=/tmp/$LOGNAME.$$.history", but that
implies no sharing of the history file.
>You can specify $HISTFILE in your startup files. I have one per host
>that shares my home directory, all under a blanket .histfiles directory
>(HISTFILE=~/.histfiles/$(hostname)).
Use "export HISTFILE=/tmp/$LOGNAME.history" for a more efficient mechanism.
--
____
\ /Dan Greening Software Transformation 1601 Saratoga-Sunnyvale Rd
\/ dgr...@cs.ucla.edu (408) 973-8081 x313 Cupertino, CA 95014
Mark R. Rubin
In article <gwf.671985359@sapphire> g...@SAPPHIRE.BELLCORE.COM
(GeorgeW. Fleming) writes:
> Is it possible for various bash processes to share a single
HISTFILE?
o ... Please, no! I haved used kshells in windowed environments that
attempt, unreliably, to do this. You're left with a history
mechanism that *sometimes*, but not always, pages through other
window's histories.
o Either way (global or local) history would be liveable, but an
unpredictable combination is a disaster. Frankly, I prefer
non-shared history, with cut-and-paste making up for the
inter-window cases.
o So keep bash the way it is.
o (Except if we could just get rid of incremental history search --
or at least supplement with ksh-style non-incremental.)
Mark Rubin (ma...@jpl-devvax.jpl.nasa.gov)