spcecdt@ucscb.UCSC.EDU (Space Cadet) (09/23/88)
I have been having a problem with the history file that the MKS korn
shell uses. It uses the HISTSIZE variable to determine how many recent
command are available when the various history mechanisms are invoked.
However, this does not seem to affect the size of the file at all; it just
keeps growing though only the $HISTSIZE most recent command are available.
This causes a problem when I start up subshells (which I do quite
frequently due to DOS's lack of job control :-( .) I have taken to leaving
my machine on normally. Since I don't often reboot, the history file
grows to several hundred commands. I don't care about the disk space this
takes up (which isn't much), but MKS sh shares the history file between
invokations of the shell. This means that every time I start up a subshell,
it reads in the entire history file and puts the last $HISTFILE commands in
the history list. That, unfortunately, takes a while which becomes annoying
when I repeatedly invoke shells.
My first thought was to use a different history file for subshells, by
setting HISTFILE to a different value in the file (specified by $ENV) that
is sourced by subshells. I did this, and made sure that HISTFILE was not
exported by the login shell so the subshell should have no clue as to what
file is being used as the history file by the login shell... but, the subshell
somehow finds the history file the login shell is using and uses that instead
of the file specified to it by HISTFILE! The login shell and further
invokations of the shell seem to be communicating by some other means than
environment variables. This happens when I invoke a subshell directly from
the login shell, or when it is started up as a command interpreter by a
program like tc or Crosstalk, by the spawn() routine in Turbo C, etc. Oddly
enough, the one case in which I can get it to use the new HISTFILE is if I
first invoke command.com, and the invoke sh from that. command.com seems to
somehow "insulate" the shells (and whatever communication they're using) from
each other.
Since the above failed, I tried other things. I found that doing an
exec /bin/sh -L from the login shell would reset the history file, but
it also toasted my print spooler and typematic rate speedup. Doing sh -L
as a subshell also reset the history file, but when I exited to the login
shell the history was munged as you might expect.
Does anyone have any ideas about how to get around this problem? I don't
want to have to reboot my machine every time I've given a hundred commands or
so. All I can think of is to write a program that will invoke
command -c /bin/sh and then set COMSPEC to that program. Yes, that would
still be faster than waiting for sh to read in even a couple of hundred old
commands, but... yuck!
--
> John H. DuBois III # spcecdt@ucscb.ucsc.EDU ...!ucbvax!ucscc!ucscb!spcecdt <