Add library functions to shralias saving feature
- Thread starter fromano
- Start date
... and automatically loaded from there? I guess I don't really understand. Library functions must be in files, on disk, before they're used. If they are in the canonical place, they're loaded automatically. If you want to load them manually, you can put them wherever you want.
Actually I would like to modify this very good suggestion.
My modification is to have a %Function_Save_Path that defines an independent location for automatically & manually saved user-defined variable and library functions. This way the user can keep the alias, history, and dirhistory lists in one directory and user-defined variable & library functions in another.
- If Function_Save_Path is not defined then SHRALIAS_SAVE_PATH, if defined, would dictate.
- Function_Save_Path could be defined even if SHRALIAS_SAVE_PATH isn't.
- All user-defined variable & library functions would be automatically save in the appropriate defined function_save_path.
- All user-defined variable & library functions could be automatically loaded during TCC startup. Controlled by a tcmd.ini directive.
I think this modified suggest accomplishes what Federico's OP requested as well as a few extras.Rexx, if needed, I will add these as individual suggestions.
I like the idea of global (shared) library functions. But I must chime in against most of what else has been suggested. I see no benefit from being able to specify the location of function.sav separately from the location of alias.sav, dirhistory.sav, and history.sav.
And I still don't know what's meant by saving library functions. They're in files to begin with and (except for deletion) the in-memory copy of a library function can't be modified. So what's the saving all about? And how would SHRALIAS know how to save them? My library functions come from 4 different files and I imagine that once they're in memory, all knowledge of where they came from has been lost.
And I still don't know what's meant by saving library functions. They're in files to begin with and (except for deletion) the in-memory copy of a library function can't be modified. So what's the saving all about? And how would SHRALIAS know how to save them? My library functions come from 4 different files and I imagine that once they're in memory, all knowledge of where they came from has been lost.
Interesting since added flexibility is the goal. If not why not is a question I often ask myself when making or supporting suggestions. Don't you use the /U(pdate functions) to update the in-memory Library function without deleting and reloading?
So I believe the current definitions for user-defined functions are automatically saved. This leads to also saving Library functions.
I think we can define multiple Library functions in a single file, as with user defined functions, so why not save them in a single file, in a specified directory, if the user wants? The current SHRALIAS_SAVE_PATH offers only two options; the suggested Function_Save_Path just seemed like a logical progression, giving the user added flexibility.
As previously stated, the reason for specifying where functions are saved and read from is so the user can save the user-defined & library functions in a directory other than that defined by SHRALIAS_SAVE_PATH. The beginning suggestions only wanted to auto-save the Library functions in SHRALIAS_SAVE_PATH which I gave a thumbs up.
Sorry to here your library functions are not "organized".
I still don't get the saving of library functions. I do use /U. But in order to use /U, the updated version must already be in a (already saved) file.
I do put more than one library function into a single file. In fact I put various collections of related ones into various files with appropriate names. I'd call that "orgnized".
I do put more than one library function into a single file. In fact I put various collections of related ones into various files with appropriate names. I'd call that "orgnized".
Slightly off topic, though not much ...
I haven't used the library capability, so I'm not familiar with the details.
Can a library routine / function load other ones? I'm thinking a "master" routine/function that loads other library files.
I haven't used the library capability, so I'm not familiar with the details.
Can a library routine / function load other ones? I'm thinking a "master" routine/function that loads other library files.
Sure. I couldn't think of a reason why not, but I just tested anyway. In lib1.txt (automatically loaded) I put
Code:
loadextras {
library /r g:\tc23\library\extras\extras.txt
}I can see several uses for that:
a) With multiple users, library functions, etc., can be saved to a common folder but other things like history can be saved to a separate folder for each user.
b) Where the same program will be used for multiple data sets. For instance, Customers A, B and C. Set paths and run the program for Customer A. Change the paths and run for Customer B, etc.
c) Multiple versions / copies:
* Development / Test / Debugging copy
* Training copy that will always have the same data
* Demo copy that will always have the same data
* Production copy
From another Suggestion thread: (Add auto-load directives to tcmd.in)
With the OP and the mods previously outlined above, this modification will add even more user defined flexibility.
Thanks for the input.
To clarify, as I understand this addition, the current subject proposal would add a "Function_Save_Path" and a "Library_Save_Path" that both work in cooperation with Shralias_Save_Path .
With the OP and the mods previously outlined above, this modification will add even more user defined flexibility.
Thanks for the input.
SHRALIAS.EXE is the only program that uses (or even knows about) SHRALIAS_SAVE_PATH. If that variable is in SHRALIAS.EXE's environment, SHRALIAS.EXE will save 4 global lists there (history, dirhistory, aliases, and functions (the @functions) when it exits. It has worked well for many years. If library routines (I don't like calling them functions) become global/shared, SHRALIAS.EXE could be made to guard the new shared memory map as it does the others.
So should there be
1. Shralias_Function_Save_Path
2. Shralias_Alias_Save_Path
3. Shralias_History_Save_Path
4. Shralias_Dirhistory_Save_Path
That seems like flexibility for the sake of flexibility.
Those four lists can change without any file changing (history and dirhistory change all the time, there's ALIAS, FUNCTION, and ESET for changing the other two on the fly). So it's quite reasonable for SHRALIAS.EXE to save those when it exits (which for me is when I logoff).
Library routines cannot be changed/added until they're already in a saved file. SHRALIAS saving them seems ridiculous.
I still haven't figured out most of the current suggestions.
So should there be
1. Shralias_Function_Save_Path
2. Shralias_Alias_Save_Path
3. Shralias_History_Save_Path
4. Shralias_Dirhistory_Save_Path
That seems like flexibility for the sake of flexibility.
Those four lists can change without any file changing (history and dirhistory change all the time, there's ALIAS, FUNCTION, and ESET for changing the other two on the fly). So it's quite reasonable for SHRALIAS.EXE to save those when it exits (which for me is when I logoff).
Library routines cannot be changed/added until they're already in a saved file. SHRALIAS saving them seems ridiculous.
I still haven't figured out most of the current suggestions.