Welcome!

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

SignUp Now!

Dir History file check

I added
Code: 
iff %_pipe == 0 .and. %_transient == 0 .and. "%@execstr[dirhistory /t1>&>nul]" == "" then
  dirhistory /r c:\Foo\DirectoryHistory.dat
endiff
to TCStart.btm and
Code: 
iff %_pipe == 0 .and. %_transient == 0 then
  dirhistory > c:\Foo\DirectoryHistory.dat
endiff
to TCExit.btm.
 
If you use SHRALIAS, you do not need to explicitly save global tables. From V14 HELP -> SHRALIAS:

"If you have an environment variable named SHRALIAS_SAVE_PATH, SHRALIAS will save the alias, history, dirhistory, and function lists to the path specified by SHRALIAS_SAVE_PATH when SHRALIAS exits. The files will be saved in Unicode format as alias.sav, history.sav, dirhistory.sav, and function.sav."

SHRALIAS.EXE exits if any instance of TCC issues the SHRALIAS /U command, or when you log out (including shutdown, power off, Windows restart [reboot]).

Should you desire the tables to be saved in ASCII format, Vince Fatica has an alternate SHRALIAS.EXE. I use its 32b version on WinXP, and a single copy of his SHRALIAS.EXE is hardlinked into the installation directories of 4NT V6, V7, V8, and TCMD V9, V10, V11, V12, V13 and V14. This allows me to share my global tables between all 4NT and TCC instances.

Furthermore, I have a shortcut in my "%userprofile\Start Menu\Programs\Startup", executed each time I log into my account, which starts a non-transient instance of TCC without using TCSTART.BTM or TCEXIT.BTM (command-line option /ISX), and a nearly empty .INI file which just specifies global history and directory history sizes. The batch file run by the startup command does nothing if SHRALIAS.EXE is already running (value of internal variable _SHRALIAS is 1); defines SHRALIAS_SAVE_PATH, loads all tables from their saved version - as you do for directory history only in TCStart.btm, starts SHRALIAS.EXE. It can also perform any other user- and platform-dependent startup (none at present). The batch file ends with the EXIT command, which terminates the TCC instance. I had considered, but not implemented initiating various monitor commands (e.g., USBMONITOR). If I did that, the TCC instance would need to remain active but dormant, e.g., by using "DELAY UNTIL 2030-12-31 23:59"...
--
HTH, Steve
 
Yes, I know all that. But, it seems overly complicated considering it should just be a built-in feature (which has been requested twice on Feedback and marked Completed both times), and is easy to do in TCStart and TCExit.
 
David Marcus said:
Yes, I know all that. But, it seems overly complicated considering it should just be a built-in feature (which has been requested twice on Feedback and marked Completed both times), and is easy to do in TCStart and TCExit.
Click to expand...
SHRALIAS **can't** be built in because the shared/global lists must exist when there are no TCCs running. I have used SHARALIAS as long as it has existed. I get it started in a login script (BTM) which does this.
Code: 
iff defined SHRALIAS_SAVE_PATH then
    cdd %SHRALIAS_SAV_PATH
    for %c in ( history dirhistory alias function ) %c /r %c.sav
    shralias
    delay 2
endiff
and I never think about it again. The lists are automatically saved upon logoff/shutdown.
 
I didn't mean shralias should be built in. I meant the feature of saving/restoring the dirhistory properly when using a global dir history. All TCC needs to do is mimic the code I put in my TCStart and TCExit. I'm perplexed that this Feedback item could be marked "Completed" twice when it still doesn't seem to work. It is pretty easy to do myself, so it is no big deal. But, there have been several posts over the years of people being confused by the current behavior. And, no one who has defended the current behavior. You can find links to previous threads in Feedback.
 
Undoubtedly "built-in feature" does not mean "built into TCC.EXE" nor "built into TakeCommand.dll", rather, David meant it as "incorporated into the TCMD package". Regardless, I just submitted in Feedback a request to improve the SHRALIAS feature.
 
Steve Fabian said:
Undoubtedly "built-in feature" does not mean "built into TCC.EXE"
Click to expand...
Yes, I meant built into TCC. No, I wasn't referring to SHRALIAS, which I don't see any need to use. I was referring to the Options > Configure TCC > Command Line > Directory History > File feature. (Similar comments would apply to the Options > Configure TCC > Command Line > Command History > History File feature.) There are already two items in Feedback and several threads in this forum on the topic. Sorry to have brought it up again.
 
OK, I get it now. It shouldn't do it if another TCC with global history/dirhistory is already running (but it does). That was your original suggestion (right?). It makes perfect sense. I agree, it wasn't implemented. Part of it would seem easy ... if the global shared files don't exist (no other instances and no shralias) create them and populate them. Deciding if there are other instances using them at exit-time (so don't write them) might be trickier.

That said, do you really want to do it at all. A modest (?) 176-line dirhistory file makes starting TCC take 25% more time. Saved/reloaded command histories tend to get big. When I tried the command history (mine is 156KB) it took TCC over 4 seconds to start. If you want a global history/dirhistory and you want it to be there even after a period when there are no TCCs running, SHRALIAS is the perfect solution.
 
vefatica said:
That was your original suggestion (right?).
Click to expand...
Right.

Deciding if there are other instances using them at exit-time (so don't write them) might be trickier.
Click to expand...
That isn't necessary. It can just always write it, just like in the code I posted.

A modest (?) 176-line dirhistory file makes starting TCC take 25% more time.
Click to expand...
I used a large dirhistory for a while, but decided it was too big. If I don't see the directory I want quickly, I might as well just use the extended directory search. I have the directory history buffer size set to 1000. And, of course, it only has to read the file when the first TCC is started.

I use local command history, have the Command History File set, and the file is currently 46,778 bytes. TCC starts in under a second. I've never noticed a delay.
 
David Marcus said:
Right.

That isn't necessary. It can just always write it, just like in the code I posted.

I used a large dirhistory for a while, but decided it was too big. If I don't see the directory I want quickly, I might as well just use the extended directory search. I have the directory history buffer size set to 1000. And, of course, it only has to read the file when the first TCC is started.

I use local command history, have the Command History File set, and the file is currently 46,778 bytes. TCC starts in under a second. I've never noticed a delay.
Click to expand...
I'd be screaming bloody murder (ask Rex) if I couldn't start/stop 10 TCCs in under a second.
 
David Marcus said:
I didn't time ten. I timed one by looking at the clock. The time to start one is between zero and one second.
Click to expand...
This has been my test for many years and Rex has tried to keep it down (thanks, Rex).
Code: 
v:\> timer & for /l %i in (1,1,10) %comspec /c & timer
Timer 1 on: 23:03:21
Timer 1 off: 23:03:22  Elapsed: 0:00:00.48
 
OK, I'll bite: Why would you want to do that?

My code above tests %_transient, so that test wouldn't be affected by my code. In fact, I don't see much point in TCC loading the Command History File if %_pipe or %_transient aren't zero.
 
David Marcus said:
OK, I'll bite: Why would you want to do that?

My code above tests %_transient, so that test wouldn't be affected by my code. In fact, I don't see much point in TCC loading the Command History File if %_pipe or %_transient aren't zero.
Click to expand...
I start TCC probably a hundred times a day (often much more, I'd guess) and I notice its quickness (or lack thereof). I have similar tests for transience in my TCSTART file and whatever I may or may not do there is subject to the "is it worth it" test. The answer has always been "no" for loading info that I can keep loaded with SHRALIAS. And testing shells that do very little in TCSTART and TCEXIT is the only good measure of things that Rex has control over. Here's the test with non-transient shells.
Code: 
g:\tc14>v:\> timer & do i=1 to 10 (%comspec /q exit) & timer
Timer 1 on: 23:56:03
Timer 1 off: 23:56:04  Elapsed: 0:00:00.70
 
I, too, start TCC many times daily - mostly temporary instances (though often using EXIT command instead of /C in the invoking command) to accomplish such things as changing screen resolution, screen saver timeout, etc. The primary working instance is usu. just minimized (using Vince's autotray.dll) while this other instances run.
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate