hood@osiris.cso.uiuc.edu (08/09/88)
Come on guys... A very simple solution to the problem of multiple history files is to tack on the process ID to the file name. HISTFILE=$HOME/.history$$ Works for me... Emmet P. Gray US Army, HQ III Corps & Fort Hood ..!uunet!uiucuxc!fthood!egray Attn: AFZF-DE-ENV DEH, Environmental Management Office Fort Hood, TX 76544-5057
bill@ssbn.WLK.COM (Bill Kennedy) (08/10/88)
In article <11300001@osiris.cso.uiuc.edu> hood@osiris.cso.uiuc.edu writes: > >Come on guys... > >A very simple solution to the problem of multiple history files is to >tack on the process ID to the file name. > > HISTFILE=$HOME/.history$$ > >Works for me... > >Emmet P. Gray US Army, HQ III Corps & Fort Hood Once again a tip of the hat to Emmet for a useful and welcome contribution. I knew there was some way to do it but never read enough to know how. This is handy, Thanks! Not to be a nit picker, but how do you get rid of them when you log out? If you stay logged in all the time I can see how it works A-OK, but it looks like it persists after you're gone. To demonstrate my ignorance, I can see putting some stuff in /etc/profile that does an ls | grep and a ps to see if the PID is gone and rm if so, but that seems to be pretty brute force (I specialize in brute force :-). It would have to be something like that or when you logged in again, if you still had a log in active (I mean rm $HOME/.history*) you'd wipe out one you were still using. Might this be a candidate for the cleanup script that clears out /tmp or somesuch? Just curious... -- Bill Kennedy usenet {killer,att,rutgers,sun!daver,uunet!bigtex}!ssbn!bill internet bill@ssbn.WLK.COM
cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) (08/11/88)
In article <226@ssbn.WLK.COM>, bill@ssbn.UUCP writes: Referring to ksh history files with unique names... > > Not to be a nit picker, but how do you get rid of them when you log out? Since .profile is only read when logging in, not with every invocation - that's what ENV is for, put something like this in your .profile: ... ... HISTFILE=$HOME/.kshistory$$ /bin/ksh rm .kshistory$$ -- -------- Christopher J. Calabrese AT&T Bell Laboratories ulysses!cjc
gmark@ihlpf.ATT.COM (Stewart) (08/12/88)
In article <226@ssbn.WLK.COM>, bill@ssbn.WLK.COM (Bill Kennedy) writes: > In article <11300001@osiris.cso.uiuc.edu> hood@osiris.cso.uiuc.edu writes: > >A very simple solution to the problem of multiple history files is to > >tack on the process ID to the file name. > > HISTFILE=$HOME/.history$$ > > > >Works for me... > ... > Not to be a nit picker, but how do you get rid of them when you log out? Yeah, I posted something like that, awhile back and it works fine. Just add a trap instruction in your login file (.profile) that appends your particular .historyXXXX to the main .history (assuming that's what you want to do). If you're trying to separate the history files of multiple layers, and not truly separate logins, the trap instruction will execute when the last layer dies (you log out). If you do this for multiple logins, checking the process IDs doesn't sound THAT inelegant. This will work for all the .historyXXXXs. Pretty handy. - Mark G. Mark Stewart ATT_BTL, Naperville, Ill. ix1g266 ixlpq!gms (312)979-0914
gst@gnosys.UUCP (Gary S. Trujillo) (08/12/88)
In article <10504@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: |In article <226@ssbn.WLK.COM>, bill@ssbn.UUCP writes: |Referring to ksh history files with unique names... |> |> Not to be a nit picker, but how do you get rid of them when you log out? | |Since .profile is only read when logging in, not with every invocation - |that's what ENV is for, put something like this in your .profile: | | HISTFILE=$HOME/.kshistory$$ | /bin/ksh | rm .kshistory$$ Well, this suggestion takes care of the problem, but at the expense of an extra process per window (since there's a shell waiting around for the /bin/ksh to die). So it takes an extra slot in the process table, but maybe it doesn't matter that much since the extra shells are sharing text space, and I assume their data space is swappable. Opinions? Emmet? -- Gary S. Trujillo {ihnp4,linus,bbn,m2c}!spdcc!gnosys!gst Somerville, Massachusetts {cirl,ima,stech,wjh12}!gnosys!gst
gst@gnosys.UUCP (Gary S. Trujillo) (08/12/88)
In article <5609@ihlpf.ATT.COM> gmark@ihlpf.ATT.COM (Stewart) writes: >In article <318@anumb.UUCP>, adh@anumb.UUCP (a.d.hay) writes: >> actually, it's <esc>/string and ksh finds the most recent command >> containing the string -anywhere- within it. > >Oh, and remember to tell 'im that successive presses of "/" and "cret" >will give him the rest of the commands that contain the string. Am I the only one losing interest in this discussion? The behavior of ksh under these circumstances is governed by that of either the EMACS or vi editor commands, so whatever one needs to know can be gleaned from the appropriate reference. Further, in the case cited (which is true only if one has ksh configured to use vi mode (which can be done by setting the EDITOR environment variable to the path of the vi editor on your system - and I think there's another way also)), you needn't use "/<CR>" to get the indicated behavior. Just use "n", as in vi! Please - enough already! :-) -- Gary S. Trujillo {ihnp4,linus,bbn,m2c}!spdcc!gnosys!gst Somerville, Massachusetts {cirl,ima,stech,wjh12}!gnosys!gst