Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!agate!saturn!ucscb.UCSC.EDU!spcecdt From: spcecdt@ucscb.UCSC.EDU (Space Cadet) Newsgroups: comp.sys.ibm.pc Subject: MKS history file Message-ID: <4919@saturn.ucsc.edu> Date: 23 Sep 88 11:15:07 GMT Sender: usenet@saturn.ucsc.edu Reply-To: spcecdt@ucscb.UCSC.EDU (Space Cadet) Distribution: na Organization: FCIPs (Frivolous CPU Intensive Programs) Ltd. Lines: 43 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 <