11.11.1 bash and ksh

Here's the basic way to give a separate history file to each Korn shell or bash : Customize your setup file (2.2 ) to set a different HISTFILE on each host or each window. Use names like $HOME/.sh_history.window n or ~/.bash_history. hostname to match each file to its window or host. If your setup is always the same each time you log in, that should give each window and/or host the same history it had on the last invocation. (There are related tips in articles 2.12 and 2.13 .)

If you open random windows, though, you'll have a harder time automatically matching a history file to a shell the next time you log in. Cook up your own scheme.

The simplest fix is to use $$ (8.19 ) -which will probably expand differently in almost every shell you ever start - as a unique part of the filename. Here are two possibilities:

HISTFILE=/tmp/sh_hist.$$
HISTFILE=$HOME/.sh_hist.$$

The first example uses the system's temporary-file directory; article 21.3 explains and shows one way to clean up. If your system's /tmp is cleaned out often, you may be able to leave your history files there and let the system remove them; ask the administrator. Note that the history file may be world-readable (22.2 ) if your umask (22.4 ) isn't set to protect your files. If that matters to you, you could make the temporary files in your home directory (or some protected directory), as in the second example shown earlier. Article 3.4 shows a way to delete those files.

Two more bits of trivia:

• The Korn shell maintains the history file constantly, adding a new line to it as soon as you run a command. This means you share history between all your current shells with the same HISTFILE name, which can be a benefit or a problem.

• In bash , each shell process keeps its own history list in memory. History isn't written to the history file (named by the HISTFILE variable in each shell) until the shell exits.

  You can force a write with the command history -w . In the same way, if you have an existing history file (or, actually, any file full of command lines), you can read it into your current bash with history -r . Article 11.12 has another example.

11.11.2 C Shell

The C shell has only one possible filename for its automatic history file: .history . If you set the C shell variable savehist in each of your windows (e.g., by setting it in your .cshrc ), they will all try to write .history at once, leading to trouble. And even if that weren't true, you get the history from every window or host, which might not be what you want.

Of course, you could set savehist manually in a single window when you thought you might be doing work you might want to pick up later. But there is another way: use the C shell's command history -h (which prints the history list without leading numbers, so it can be read back in later) and redirect the output to a file. Then use source -h to read it back into your history list when you log in.

Do you want to automate this? First, you'll need to choose a system of filenames, like ~/.history.window n or ~/.history. hostname , to match each file to its window or host. If each of your C shells is a login shell\** (2.8 ) , [1] you can run history -h from your .logout file and source -h from your .login file. For non-login shells, automation is tougher - try this:

[1] In the X Window System (1.31 ) , set the xterm -ls option to force a login shell.

• Set the ignoreeof variable (3.5 ) to force you to leave the shell with an exit (38.4 ) command.

• Set an alias for exit (10.6 ) that runs history -h before exiting.

• Run source -h from your .cshrc file. Use a $?prompt test (2.9 ) to be sure this only runs in interactive shells.

If you choose to run history -h and source -h by hand occasionally, they will allow you the kind of control you need to write a script (11.12 ) that saves and restores only what you want.