Command history getting reloaded

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
Aug 19, 2008
146
0
#1
So I leave a TCMD window open 24/7. For months I wondered why my command history just wasn't acting right. Now I know.

Open a TCMD session and create some distinctive entries in the command history. Make sure TCC options specify a command history file. Exit the session.

Open a TCMD session and verify the history was loaded. Bring up the history window and delete an entry. Now select File/New tab. Note the command history in both tabs now contain the entry you just deleted.

So, it's reloading the history file any time a new tab is opened and apparently any time a TCC command is issued.

While a PITA, I guess this is working as designed. The help states that the history file is loaded before TCSTART is run and TCSTART is run each time TCC starts.

Why would you ever want your command history for the past few days discarded and replaced by the history you had a few days ago just because you needed to open a new tab???
 
Aug 19, 2008
146
0
#3
Exactly.

My reply to Rexx's comment - why did you add the option if I should be doing it in TCSTART.

Here's what I ended up doing.

TCSTART:

@echo off
iff %_Elevated == 1 then
set TITLEPROMPT=Admin:
endiff
iff %_SHRALIAS != 1 then
shralias
echo Loading command and directory history...
history /r c:\ProgramData\JPSoft\history.sav
alias /r c:\ProgramData\JPSoft\alias.sav
dirhistory /r c:\ProgramData\JPSoft\dirhist.sav
endiff

TCEXIT:

@echo off
iff %_SHRALIAS == 1 then
echo Saving command and directory history...
history > c:\ProgramData\JPSoft\history.sav
alias > c:\ProgramData\JPSoft\alias.sav
dirhistory > c:\ProgramData\JPSoft\dirhist.sav
endiff

Lastly...

SHRALIAS_SAVE_PATH=c:\ProgramData\JPSoft

I'll probably add a scheduled task to periodically run TCEXIT to protect me from BSOD's.
 
Aug 19, 2008
146
0
#4
Bug fixed in v13 :-)

"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)."
 
#5
Ron, I think you're missing part of the point of SHRALIAS. If SHRALIAS is
running, there is no reason to save any of the lists in TCEXIT. The history is
in memory, guarded by SHRALIAS. It will be there for any subsequent TCCs with
global lists, and SHRALIAS will automatically save the lists (if
SHRALIAS_SAVE_PATH is set) when you logoff/shutdown.

As for loading the lists and starting SHRALIAS, I have always preferred to do
that in either a logon script or a BTM placed in the startup folder. If you do
that, and let SHRALIAS run from logon to logoff, there's no need to do anything
related in TCSTART or TCEXIT.

I like your idea of a task to dump the lists to the SAV files ince in a while
but it makes me wonder ... do you have a lot of BSODs? If I have a catastrophy
where SHRALIAS doesn't save the lists and I must get back recent commands, I
recover by using HISTORY /R on the log file (which is separate from the SHRALIAS
svae files). That can take a while since the log file grows without bound, but
it's only necessary in emergencies. The other lists don't bother me. I can use
the restored command history to fix the alias and function lists (neither of
which change often), and I just let the dirhistory list re-populate due to
normal use.

On Tue, 30 Aug 2011 21:09:39 -0400, ron <> wrote:

|TCSTART:
|
|@echo off
|iff %_Elevated == 1 then
|set TITLEPROMPT=Admin:
|endiff
|iff %_SHRALIAS != 1 then
|shralias
|echo Loading command and directory history...
|history /r c:\ProgramData\JPSoft\history.sav
|alias /r c:\ProgramData\JPSoft\alias.sav
|dirhistory /r c:\ProgramData\JPSoft\dirhist.sav
|endiff
|
|TCEXIT:
|
|@echo off
|iff %_SHRALIAS == 1 then
|echo Saving command and directory history...
|history > c:\ProgramData\JPSoft\history.sav
|alias > c:\ProgramData\JPSoft\alias.sav
|dirhistory > c:\ProgramData\JPSoft\dirhist.sav
|endiff
|
|Lastly...
|
|SHRALIAS_SAVE_PATH=c:\ProgramData\JPSoft
|
|I'll probably add a scheduled task to periodically run TCEXIT to protect me from BSOD's.
 
Aug 19, 2008
146
0
#6
For "me", I only experience BSOD's or complete system hangs after I've just happened to spend allot of time doing command line work. It has nothing to do with TCMD, just "my" luck.

So, saving every time a TCC session is closed and occasionally by automated task is merely insurance :-) Why can't TCMD have an autosave? Word does. What's the purpose of a command history if you have to shutdown Windows to save your recent history - unless you do what I did with TCEXIT.

I don't know what the typical process load is but I average around 150. In addition, I only reboot when absolutely necessary. Given how well Windows handles issues that in the past would result in BSOD's, it's not unusual for me to go 30 days between reboots. That's ALLOT of command history to loose if I encounter the rare hang on day 29!
 
#7
On Tue, 30 Aug 2011 22:22:36 -0400, ron <> wrote:

|I don't know what the typical process load is but I average around 150. In addition, I only reboot when absolutely necessary. Given how well Windows handles issues that in the past would result in BSOD's, it's not unusual for me to go 30 days between reboots. That's ALLOT of command history to loose if I encounter the rare hang on day 29!

The same here. Except for the recent warming up to Windows 7, 50-100 day
sessions are not uncommon here. My XP machine at work was over 200 days until a
crew excavated right through an electrical supply this summer.

I like the idea of periodically saving the global lists as a hedge against a
catastrophic failure (though such failures are so seldom that I might never
benefit from it).

Back around v7, I collaborated a bit with Rex on adding the auto_save_at_logoff
feature to SHRALIAS. If things haven't changed much, SHRALIAS already has
nearly all it needs to save the lists to files periodically ... a window
process which could handle a WM_TIMER message, and a handy function to dump the
lists to files. A mere handful of lines of codes could implement periodic
saving. Perhaps Rex would consider it.

I might test it here in one of the countless versions of SHRALIAS I have hanging
around. Are there any suggestions on how it should work (when/how often to dump
the lists)?
 
#8
From: vefatica
| I might test it here in one of the countless versions of SHRALIAS I have hanging
| around. Are there any suggestions on how it should work (when/how often to dump
| the lists)?

Since SHRALIAS.EXE is loaded by an internal TCC command which has no options, the best I can suggest is an environment variable that must be defined before the SHRALIAS command is executed, akin to the SHRALIAS_SAVE_PATH variable. Resolution could be hours or even days, starting when the command loading it is executed. Since the program has no access to current environment variables, modification of the dumping interval and forced dumping are not feasible, UNLESS you make a SHRALIAS plug-in command that can communicate with the process. If you do, all kinds of other features become possible, e.g., dynamic choice of encoding (ASCII, Unicode, UTF-8, etc), suspension of periodic dumping, change of dumping interval, "dump on command", "partial dumping" (i.e., dumping only selected global tables, not all), (selective) hiding of global tables (temporarily forcing the use of local tables), automatic loading of tables when SHRALIAS is started, etc.
--
Steve
 
Aug 19, 2008
146
0
#9
Every n hours should be sufficient. That would simplify the implementation since you don't have to worry about multiple scheduled saves.

At work I had a script that ran while I was at lunch and after I went home. So I'd set it to 12.
 
#10
On Wed, 31 Aug 2011 00:12:31 -0400, ron <> wrote:

|Every n hours should be sufficient. That would simplify the implementation since you don't have to worry about multiple scheduled saves.
|
|At work I had a script that ran while I was at lunch and after I went home. So I'd set it to 12.

Having given it a little more thought, I'm more concerned with when it happens
(as opposed to how often). I imagine corruption could occur if TCC is writing
to a memory-mapped file at the same time that SHRALIAS is dumping it to a file.

Perhaps Rex will chime in here.
 
Aug 19, 2008
146
0
#11
If it's too risky to implement, I'm content with setting up scheduled tasks to handle my particular needs.

Not to mention that this is not likely something that would appeal to the masses.
 

samintz

Scott Mintz
May 20, 2008
1,203
11
Solon, OH, USA
#12
Since it is a MMF, why can't you actually
use a file to back it? An unnamed MMF uses the pagefile to back it.
A named file uses the same mechanism, but backs it with the actual
file. Then there is no scheduling of anything. The OS handles it.

-Scott




If it's too risky to implement, I'm content
with setting up scheduled tasks to handle my particular needs.

Not to mention that this is not likely something that would appeal to the
masses.
 
#13
On Wed, 31 Aug 2011 13:38:44 -0400, ron <> wrote:

|If it's too risky to implement, I'm content with setting up scheduled tasks to handle my particular needs.

I think you can already implement that with a scheduled task. Run the task as
yourself (the logged-on user). It could be as simple as

Code:
(path\)tcc.exe /c (path\)shrdump.btm
where shrdump.btm does

Code:
SHRALIAS /U
DELAY 1
SHRALIAS
DELAY 1
(not sure the delays are necessary). SHRALIAS dumps the files when you
terminate it (via SHRALIAS /U) so just stop it and start it again.
 
#14
On Wed, 31 Aug 2011 15:18:45 -0400, samintz <> wrote:

|Since it is a MMF, why can't you actually
|use a file to back it? An unnamed MMF uses the pagefile to back it.
| A named file uses the same mechanism, but backs it with the actual
|file. Then there is no scheduling of anything. The OS handles it.

Hmmm! Maybe Rex will comment on that. I don't think SHRALIAS.EXE knows the
maximum list sizes (which are TCC user specs). More communication between TCC
and SHRALIAS might be needed to get the on-disk file size right.
 
#15
From: samintz
| Since it is a MMF, why can't you actually
| use a file to back it? An unnamed MMF uses the pagefile to back it.
| A named file uses the same mechanism, but backs it with the actual
| file. Then there is no scheduling of anything. The OS handles it.

Excellent suggestion! SHRALIAS_SAVE_PATH already fixes the filenames, so there is no user action needed - all changes are instantly saved, totally transparently to the user.
--
Steve
 
#16
From: vefatica
| I think you can already implement that with a scheduled task. Run the
| task as yourself (the logged-on user). It could be as simple as
|
| Code:
| (path\)tcc.exe /c (path\)shrdump.btm
|
| where shrdump.btm does
|
|
| Code:
| SHRALIAS /U
| DELAY 1
| SHRALIAS
| DELAY 1(not sure the delays are necessary).
|
| SHRALIAS dumps the files when you
| terminate it (via SHRALIAS /U) so just stop it and start it again.

Neither as simple nor as elegant as Scott's suggestion, but it would not require change to any existing SHRALIAS.EXE. If you are willing, I'd like you to modify SHRALIAS.EXE to examine an environment variable (say SHRALIAS_SAVE_ENCODING) when it is loaded to determine the encoding used in the *.SAV files (at least ASCII and UNICODE, possibly also base-64 and UTF8), and to access them as MMFs - thus ensuring that any sudden death of the system would have up-to-date files. If desired, another variable might be used to enable or disable MMF mode.
--
TIA, Steve
 
#17
On Wed, 31 Aug 2011 17:46:41 -0400, Steve Fabian <> wrote:

|From: samintz
|| Since it is a MMF, why can't you actually
|| use a file to back it? An unnamed MMF uses the pagefile to back it.
|| A named file uses the same mechanism, but backs it with the actual
|| file. Then there is no scheduling of anything. The OS handles it.
|
|Excellent suggestion! SHRALIAS_SAVE_PATH already fixes the filenames, so there is no user action needed - all changes are instantly saved, totally transparently to the user.

After further thought, that's something TCC would have to do when it created the
file map (SHRALIAS merely opens an existing file map). In theory, it would do
away with the need for SHRALIAS altogether ... if the map already exists (a
concurrent TCC has created it), then a new TCC would merely open it and use it.
Otherwise a new TCC would create it with the on-disk file as backup. But I
suspect we'd see (i.e., notice) a performance hit in the loading of the file
(with every TCC started when no others were running) and possibly in the
continual sync'ing of the file and the file map. Rex probably considered that
approach a long time ago. The reading of the SAV files, which I do in a
StartUpFolder BTM takes a noticeable amount of time.

Sync on demand would be easy for TCC to do (just send a message to SHRALIAS's
window) after SHRALIAS were programmed to react to such a message.

If I'm not mistaken, a scheduled task can require an idle period (yes/no?). That
might lessen the possibility of corruption if the file dumping were done at
regular intervals.