How to? Shralias and producing history.sav, alias.sav ..

[rps]

If I load shralias and define shralias_save_path in the TCstart.btm file, with global history, aliases, dirhistory, and functions.
Then unload shralias; history.sav, alias.sav, function.sav and dirhistory.sav are not updated.

In the same TCC sesson, if I reload shralias from the command line and then unload it, the ".sav" files are updated.

The way I understand the help docs, these .sav files should be updated after unloading shralias for the first time.

I see the same behavior in both v23 and v24 BETA.

Is this a bug or maybe I don't understand the documentation?

 

[vefatica]

In what order are you doing things (and is it all done in TCSTART)? TCC will start SHRALIAS.EXE and SHRALIAS.EXE needs SHRALIAS_SAVE_PATH in its own environment. So SHRALIAS_SAVE_PATH needs to be set before the SHRALIAS command

 

[rps]

In what order are you doing things (and is it all done in TCSTART)? TCC will start SHRALIAS.EXE and SHRALIAS.EXE needs SHRALIAS_SAVE_PATH in its own environment. So SHRALIAS_SAVE_PATH needs to be set before the SHRALIAS command

Yep. SHRALIAS_SAVE_PATH is defined waaaayyy before shralias is loaded, all done in TCSTART.btm.
So, are you actually getting .sav file updates with that order?
I must have missed this is the docs?

Perhaps things happen to fast during the execution of tcstart.btm, which would be very unfortunate.

 

[vefatica]

Is this in a transient TCC (perhaps a logon script)? If so, there should be a delay after issuing SHRALIAS and before TCC terminates. Without such a delay, TCC can terminate, closing the memory-mapped global files before SHRALIAS.EXE has grabbed onto them. If SHRALIAS.EXE doesn't find any lists to protect, it will gracefully terminate. Do you have a way of checking whether SHRALIAS.EXE is actually running and whether SHRALIAS_SAVE_PATH is actually set in SHRALIAS.EXE?

 

[rps]

Is this in a transient TCC (perhaps a logon script)? If so, there should be a delay after issuing SHRALIAS and before TCC terminates. Without such a delay, TCC can terminate, closing the memory-mapped global files before SHRALIAS.EXE has grabbed onto them. If SHRALIAS.EXE doesn't find any lists to protect, it will gracefully terminate. Do you have a way of checking whether SHRALIAS.EXE is actually running and whether SHRALIAS_SAVE_PATH is actually set in SHRALIAS.EXE?

No, these are not transient TCC's.
Even though shralias_save_path is defined at the very beginning of my tcstart.btm, I added a "defer shralias" to my tcstart.btm.
After the TCC tab displayed a prompt, I unloaded shralias and as if by magic the .sav files were updated.
So, this issue is clearly all about timing.

Bottom line, setting up things so they will automatically update the .sav files isn't worth it to me.
I am unwilling to give up a very fast TCMD/TCC startup for this little bit of automation which I can't get to work as expected.
In future, I will deal with this manually.

 

[vefatica]

I use a Windows login script (a BTM shortcut in the startup folder). It only needs to be done once. And I never unload shralias. It automatically dumps the files upon logout or shutdown

set SHRALIAS_SAVE_PATH=h:\ShrDump
cdd %SHRALIAS_SAVE_PATH
do c in /L history dirhistory alias function ( %c /r %c.sav )
delay 3
shralias
:: also start PowerPro, TclockEx, and Outlook

 

[rps]

I use a Windows login script (a BTM shortcut in the startup folder). It only needs to be done once. And I never unload shralias. It automatically dumps the files upon logout or shutdown

set SHRALIAS_SAVE_PATH=h:\ShrDump
cdd %SHRALIAS_SAVE_PATH
do c in /L history dirhistory alias function ( %c /r %c.sav )
delay 3
shralias
:: also start PowerPro, TclockEx, and Outlook

Very good idea.
Way back, perhaps in single digit versions, I had something in my startup folder, but it didn't prove itself as having any value.
Your idea has merit. I may give it a try.
Thanks.