Lost history

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
Hello.
Several time I was annoying by loosing history when started another TCC session. Now I'm ready to define an issue.

Environment: TCC 16.03.55 Windows 7 [Version 6.1.7601]
or: TCC LE 13.06.77 Windows 7 [Version 6.1.7601]

Settings:
Code:
History=509952
HistCopy=No
HistMove=Yes
HistWrap=Yes
HistCase=No
HistDups=Last
HistFile=Z:\History.dat
LocalHistory=No
tcStart.bat
Code:
@*Echo === tcStart ===
@*History
@*Echo ===============
and History.dat:
Code:
dir 1
dir 2
dir 3
Scenario:
Start tcc.exe
Code:
=== tcStart ===
dir 1
dir 2
dir 3
===============
OK.

Some commands:
Code:
dir 2
@history
And the result is:
Code:
dir 1
dir 3
dir 2
Very good, as expected.

Now let's start another TCC session:
Code:
=== tcStart ===
dir 1
dir 3
dir 2
dir 1
dir 2
dir 3
===============
It looks, that: Tcc.exe uses history from global history (the first three lines), then appends History.dat. Would be OK. Don't execute anything in that session, go back to the first session:

Code:
@history
And the result is:
Code:
dir 1
dir 3
dir 2
dir 1
dir 2
dir 3
Ooops. I've got history shared from second session. My last issued command "dir 2" is not he last one. Ma last activities are hidden by re-read of history.dat file.

It is a simple example, the real problem is: I issued dozens of commands. All of them are available to be recalled/reviewed using just several "Up" cursor keys. Starting second shell - my work is hidden by thousands of commands reread from history file.

I'm not sure, if my last activities are hidden, or may be they are lost (due to size of history exceeding limit).

IMHO: order of operations should be reversed: 1st read from history file, 2nd append from global list.
 
Last edited:
#2
A global list is just that ... a global list. TCC doesn't read from it, it just attaches to it, There is no mechanism for prepending to the history (if there were, it would be god-awful slow). I doubt the HistFile was meant to be used with a global history. I wouldn't dream of doing it. Consider using SHRALIAS. SHRALIAS protects the global history when no instances of TCC are running so there's no need to load/save the history every time you start/stop TCC.
 
#3
In that approach: it would be enough not to read history.dat if it was possible to attach to global list - global list was already filled from history.dat in the first session.

ShraAlias doesn't resolves anything, everything is working as described previously
 
#4
In that approach: it would be enough not to read history.dat if it was possible to attach to global list - global list was already filled from history.dat in the first session.

ShraAlias doesn't resolves anything, everything is working as described previously
To your second point ... if you use a global history (with SHRALIAS or not) and a HistFile it will work as you described before. A suggestion: if you want a global history, don't use a HistFile.

To your first point ... I think folks do that themselves if they want a global history loaded in the "first" session. For as long as I can remember, I have used a login script to load the (global) history (dirhistory, aliases, functions too) from files saved by SHRALIAS ... and then start SHRALIAS. That's the end of the story. I never mess with the history again. It's always there and it's the same in every instance of TCC. And TCC starts instantly (~.07 sec.) not having to load anything. I must confess to being obsessed with how fast TCC starts. I start it roughly 70-80 times a day.
 
Last edited:
#5
It doesn't work correctly with global history. I use global directory history, so I manage saving/loading it myself in tcstart.btm and tcexit.btm.

Code:
iff %_pipe == 0 .and. %_ide == 0 then
   iff %_transient == 0 .and. "%@execstr[dirhistory /t1>&>nul]" == "" then
      dirhistory /r c:\Sys\Data\DirectoryHistory.dat
   endiff
endiff
Code:
iff %_pipe == 0 .and. %_transient == 0 then
   dirhistory > c:\Sys\Data\DirectoryHistory.dat
endiff