Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Directory history file and global directory history

D

David Marcus

Jun
793
7
I have global directory history (i.e., "Local Directory History" is not checked) and I have a Directory History File specified. But, each time I do Ctrl-T in TCmd, the directory history file is loaded.

I don't understand the statement in the Help that "TCC can only guess (based on the TCMD.INI inheritance)". What is TCMD.INI inheritance?

What I used to do (long ago before the Directory History File option was added) was check in TCStart.btm to see if the directory history list was empty and only load my directory history file if it was. I guess that isn't what TCC is doing.

TCC 13.00.19 Windows Vista [Version 6.0.6002]
 
If you specify any history file, TCMD will reload that file on startup and whenever another TCC window is opened, overwriting any history you had accumulated.

Are you implying that it also does this when you invoke the command to display the directory history?
 
ron said:
If you specify any history file, TCMD will reload that file on startup and whenever another TCC window is opened, overwriting any history you had accumulated.
Click to expand...

I didn't mean to imply it has anything to do with TCmd. I just meant that it happens when I start a new TCC, e.g., in a tab.

This was supposed to be changed in V13. It was one of the feedback requests (which is marked "Competed"):

http://jpsoft.uservoice.com/forums/...ry-file-check-for-global-directory-?ref=title

And, the What's New says, "The persistent directory history file is now only loaded if either local directory history is set, or TCC thinks it is the first instance. But since there's no such thing as 'shell levels' in Windows, TCC can only guess (based on the TCMD.INI inheritance)."
 
On Mon, 12 Sep 2011 22:36:48 -0400, David Marcus <> wrote:

|And, the What's New says, "The persistent directory history file is now only loaded if either local directory history is set, or TCC thinks it is the first instance. But since there's no such thing as 'shell levels' in Windows, TCC can only guess (based on the TCMD.INI inheritance)."

I suspect that when tabs are involved (TCCs started by TCMD) every one will
think it's the first because it wasn't started by another TCC.
 
vefatica said:
I suspect that when tabs are involved (TCCs started by TCMD) every one will think it's the first because it wasn't started by another TCC.
Click to expand...

I don't really understand why this is so hard. If it is hard, then I'll just do it myself in TCStart.btm.

When TCC starts with global history (command or directory), it has to connect to the global history. I don't know if it can tell if the global history already existed or if it is creating it. If it can tell, it knows whether to load the history file. If it can't tell, it can check whether the global history is empty. If it is empty, it loads the history file. If it is not empty, it does not load the history file.

As for exiting, if it can tell if other instances are still using the global history, then it knows whether to write the history file. If it can't tell, it could just always write the history file. The last one to exit will write the final history file, which can then be loaded the next time a TCC starts.
 
David Marcus said:
This was supposed to be changed in V13. It was one of the feedback requests (which is marked "Competed"):
Click to expand...

Well duh, I forgot that - even after griping about it. Anyway, I just tested it with the last beta build (I know, I'm behind) and it seems to be working as it should. Set up both cmd and dir histories, exited, restarted tcmd, entered commands, exited so they would save, restarted tcmd, commands are there, enter a new command, open a new tcc tab, the new command is in the history - not overwritten.

Correction, that test was with 13.0.19.
 
Ok, now I'm seeing something unexpected. I'll note that in this test VM I'm not using Shralias but all histories are 'global'.

Opening up TCMD, I get the history from yesterday.

Enter the command wacka, then open a new tab. The wacka command is in the history. BUT, the history seems larger.

Subsequently opened 4 more tabs and noted the history doubled in size each time. Looking at the command history, everything was duplicated except for wacka. After opening the 4th tab, the history was 4 times the size of the original will duplicate entries for all except for wacka.

My TCC prefs are move to end, save last.

It's certainly not wiping out the existing history (for me) as 12.x did but is appending to the history in memory 'each' time a tcc window is opened.
 
My tests are without shralias, with "Move to end" and "Wrap" checked, and with "Save Last" selected.

Usually, I use local command history and global directory history.
 
rconn said:
No, it's you requesting a feature that isn't doable in Windows.
Click to expand...

What's wrong with the algorithm I posted in message #5 in this thread, i.e.:

"When TCC starts with global history (command or directory), it has to connect to the global history. I don't know if it can tell if the global history already existed or if it is creating it. If it can tell, it knows whether to load the history file. If it can't tell, it can check whether the global history is empty. If it is empty, it loads the history file. If it is not empty, it does not load the history file.

"As for exiting, if it can tell if other instances are still using the global history, then it knows whether to write the history file. If it can't tell, it could just always write the history file. The last one to exit will write the final history file, which can then be loaded the next time a TCC starts."
 
> What's wrong with the algorithm I posted in message #5 in this thread
Click to expand...

Nothing, except that it requires a lot of interprocess communications
between unrelated TCC instances that doesn't currently exist.

And there isn't any way for a TCC instance to tell if somebody else is using
the global history -- at least, not without injecting code into every other
process. (And I won't be doing that.)

You're requesting a feature, not reporting a bug.
 
rconn said:
No, it's you requesting a feature that isn't doable in Windows.
Click to expand...

So would it be fair to say that using a global history setting and specifying "History File" and "Directory History" files is not recommended? Otherwise each new session reloads the same file, every time, appending to any previously loaded history from other sessions.

*update* Guess I need to 'refresh' right before posting :-) I understand the explanation below now - just didn't know for certain if that was why I was seeing the behavior.
 
rconn said:
Nothing, except that it requires a lot of interprocess communications between unrelated TCC instances that doesn't currently exist.
Click to expand...

Can't you avoid the interprocess communication if you do the following:

When TCC starts with global history (command or directory), it checks whether the history is empty. If it is empty, it loads the history file. If it is not empty, it does not load the history file. When TCC exits, it always writes the history file.

And there isn't any way for a TCC instance to tell if somebody else is using the global history -- at least, not without injecting code into every other process. (And I won't be doing that.)
Click to expand...

Do you mean when it exits or also when it starts?. Can it tell when it starts if the global history already existed?

You're requesting a feature, not reporting a bug.
Click to expand...

Indeed I did request this feature before V13 came out:

http://jpsoft.uservoice.com/forums/...ry-file-check-for-global-directory-?ref=title

The feature request is marked as "completed", but it doesn't do what I was requesting. So, what was implemented? I don't see any difference between V12 and V13 in how this works.
 
rconn said:
It can tell at startup if the global history already existed, but that doesn't mean that there's one or more active TCC processes. (You could have SHRALIAS running.)
Click to expand...

I think if someone runs SHRALIAS, they can take responsibility for loading the history themselves. Or, there could be an option for the user to specify what happens in this case. I haven't been running SHRALIAS, so I'm more interested in what happens when SHRALIAS isn't running.

Rex, What's the status with this? Are you going to change it, should I add it back to the feedback page (I still don't understand what change you made in V13 that led to marking this as completed), and/or should I fix it myself in my tcstart.btm?
 
I have always used SHRALIAS and never considered a dirhistory file. Having considered it a little, I can see only two uses for it.

(1) ... with global dirhistory, as a replacement for SHRALIAS ... in which case, it should work as David proposes ... read by a TCC started when no others are running and written at exit by a TCC that will leave no others running ... anything else and you don't really have a global (shared) dirhistory

(2) ... with local dirhistory ... to load a basic set of frequented directories; if that were my intent, I'd want it loaded by every instance of TCC.

Do others see it differently?
 
I'm probably the odd-man out in this group.
I never use global lists or SHRALIAS. I almost exclusively
work from a single instance of TCC running in TCMD. On the rare occasions
when I start additional tabs, I usually don't care about the histories
of other tabs. That being said, I do have specialty code in my TCSTART
file to restore my work environment if I choose to do that.

My work environment consists of:
the environment (i.e. SET)
aliases
dirhistory
history
and CWD's of each drive (the output
of CDD /A).

Code: 
set s=Y
inkey /c /k"YN[Enter]" /w10
/x Restore Previous Environment? (Yn) %%s
echo.
iff "%s" eq "Y"
.OR. "%s" eq "@28" then
  for %%s in (@c:\JPSOFT\drives.dat)
do cdd %%s
  set /r c:\JPSOFT\env.dat
  dirhistory /r c:\JPSOFT\dirhist.dat
  history /r c:\jpsoft\history.dat
endiff

-Scott

vefatica <> wrote on 10/19/2011
07:58:14 PM:


>
> I have always used SHRALIAS and never considered a dirhistory file.
Click to expand...


> Having considered it a little, I can see only two uses for it.
>
> (1) ... with global dirhistory, as a replacement for SHRALIAS ...
Click to expand...
in

> which case, it should work as David proposes ... read by a TCC
> started when no others are running and written at exit by a TCC that
> will leave no others running ... anything else and you don't really
Click to expand...


> have a global (shared) dirhistory
>
> (2) ... with local dirhistory ... to load a basic set of frequented
Click to expand...


> directories; if that were my intent, I'd want it loaded by every
> instance of TCC.
>
> Do others see it differently?
>
>
Click to expand...
 
On Wed, 19 Oct 2011 21:12:23 -0400, David Marcus <> wrote:

|---Quote (Originally by vefatica)---
|(2) ... with local dirhistory ... to load a basic set of frequented directories; if that were my intent, I'd want it loaded by every instance of TCC.
|---End Quote---
|In which case, you probably wouldn't want TCC to overwrite your file when it exits, would you?

Very correct! I didn't think of that.
 
You must log in or register to reply here.
Back
Top