BASH history features...
Chet Ramey
> usually run multiple virtual screens, the history got mixed up between
> different invocations. Did I do something incorrect, or was that a
> bug that has been fixed, or is there a workaround?
I assume you mean when saving the history. You can make the history
file anything you want by assigning a value to $HISTFILE. You can
have a separate file for each virtual screen, if you'd like.
--
"You can watch an actor absolutely sabotage a good script and then read
reviews like 'Unfortunately, even the impressive talents of Cheech Marin
could not salvage Anton Chekhov's trite and meandering script.'"
Chet Ramey, Case Western Reserve University Internet: ch...@po.CWRU.Edu
Clayton Haapala
>When I first tried BASH, the history was stored in a file. Since I
>usually run multiple virtual screens, the history got mixed up between
>different invocations. Did I do something incorrect, or was that a
>bug that has been fixed, or is there a workaround?
>
>
I make HISTFILE point to some filename based on the tty I'm on, as in this
excerpt from my .bash_profile:
# Init this session with the shell
t=`tty`
t=${t##/dev/}
t=${t##pty/}
HISTFILE=$HOME/.bhist.$t
cp /dev/null $HISTFILE # only if you want it zeroed. ">" would work too
export HISTFILE
--
Clayton Haapala (cl...@network.com)
Network Systems Corp. "... and the alligators are on FIRE."
7600 Boone Ave N MS614 -- S.E.K.
Minneapolis, MN 55428-1099
lar3ry gensch
interspersing history lines between virtual sessions when the HISTFILE
is identical? Eg:
<virtual terminal 1> <virtual terminal 2>
$ ls
$ cat .profile
$ make
$ make install
$ vi .profile
$ . ./.profile
$ ^D
$ ^D
In ksh, the history file would contain:
ls
cat .profile
make
make install
vi .profile
. ./.profile
In bash, the history file only contains those commands from one of the
sessions (I believe from the last one to exit); eg:
ls
make
make install
Although my history size is rather large, I have found that trying to
recall a command from a day or two ago usually fails because it
happened in a session whose history got overwritten by another
concurrent session.
--
(void) lar3ry(); lar...@world.std.com
"A theme park near Paris makes the revenues go down...
In the most expensive way." -- _DIS' 'n' DAT_ / March 1994
Tom Tromey
behavior by putting the appropriate command into your PROMPT_COMMAND
(ie, something to write the newest line to the history file).
Tom
--
tro...@cns.caltech.edu
"In a riddle whose answer is chess, what is the only prohibited word?"
I thought a moment and replied, "The word chess".
-- Jorge Luis Borges
Richard Smith
: Although my history size is rather large, I have found that trying to
: recall a command from a day or two ago usually fails because it
: happened in a session whose history got overwritten by another
: concurrent session.
I have never seen the history file get "overwritten". It is my understanding
that the following happens:
1. When an interactive shell is invoked, the command history maintained by
that shell is initialized to the contents of the history file, as
defined by $HISTFILE, up to the number defined by $HISTSIZE. The point
at which the "loaded-in" part ends and the "new stuff" begins is
remembered by bash.
2. As commands are entered by the user during an interactive session, they
are appended to the internal list. They are *not* written to the
history file unless the user makes some sort of specific arrangment for
this to happen. If the size of the list exceeds $HISTSIZE, commands are
deleted from the top of the list.
3. When an interactive shell terminates normally, the contents of the
command history (the "new stuff") is appended to the history file. If
the size of the file exceeds $HISTFILESIZE, comands are truncated from
the top of the file before it is written back.
Since I frequently use multiple sessions and sessions within sessions, I
have become accustomed to this behavior. The rules are logical, consistent,
and avoid behavior that would seem "odd" (commands being recalled from
history out of contiguous sequence), or inefficient (writing to the history
file after each command).
I have never seen the ksh behavior that Larry described. It would seem
that Chet has two options if he felt inclined to implement it:
A. Use streams or some other form of interprocess comunication. Painful
and not-very-portable.
B. Create yet_another_long_enviroment_variable with a name like
"synchronous_histfile_update". This is a little more feasible, but
just as painful from a coding standpoint. It would slow the shell
down by a significant factor.
My vote: Let Chet deal with more important things. If I got any of the
rules wrong, or if someone has a good PS1 hack to cause synchronous updates
to the history file, I would love to be informed about it.
--
+------------------------------------------------------------------------+
| Richard S. Smith | PROGRESS(tm) 4GL Developer | Monrovia, California |
| rsm...@netcom.com | "Holding my breath for V7" | Voice: (818) 303-7346 |
+------------------------------------------------------------------------+
Andreas Schwab
|> I have never worked out a good way to keep consistant history. Here is
|> the hack I use in my .bash_logout:
|> not() { if $@ ; then false ; else true ; fi }
|> cd
|> while not mkdir .bash_history.lock 2>&- ; do
|> echo waiting for lock on .bash_history
|> sleep 5
|> done
|> history -a .bash_history
|> rmdir .bash_history.lock
|> HISTSIZE=0
|> Is there a better way of doing this?
Yes, you can write ! instead of not:
while ! mkdir .bash_history.lock 2>&- ; do
...
done
This saves some fork()s.
--
----------------------------------------------------------------------
Andreas Schwab "And now for something
sch...@ls5.informatik.uni-dortmund.de completely different"