Jump to content
Ketarin forum

Setting variables within commands


Recommended Posts

  • 2 weeks later...

As part of my post-download processing, I want to read a string from a text file, then use that string in the next post-download command step. To do this, I need to store the retrieved string within a variable. I haven't tried this yet, but presume I can just use a Windows environment variable, but was wondering if there's a better way to do this.

Link to comment
Share on other sites

Hi Jim,


If I understand your question correctly, you are asking for more information on best practices when writing certain kinds of design logic in Windows scripts, such as in the scripts you can launch from within Ketarin?


If that's the case, IMO there's not a single best approach to any particular design, such as your example of passing a string value down through the script or even into another script. An environment variable might be a viable method, it depends on whether the variable needs to be static or temporary, how long the string is, can you make your environment space large enough to hold what you need, etc.


Other options could be to use .vbs scripts within or instead of .bat or .cmd files, they have more processing options but may be a security risk depending on your installation. Or perhaps installing 3rd party command line tools such as Cygwin for Windows gives you the options you need.


I hope I underrstood your question correctly and gave you some ideas to look into? But if I'm still being daft :-) and missing your question, please let me know.



Link to comment
Share on other sites

Not at all, I appreciate your taking the time to try to help, appyface :-).


Let me be more specific. My goal is to retain previous versions of all apps, at least until I can work out how their settings are stored and automate copying them across from previous version to new version as part of a customized post-download command. My tentative plan is to have an app structure that looks like this:








CCleaner.lnk (points to .exe in \Current folder)














Each app has its own folder, which contains the latest version in a \Current subfolder; subfolders for previous versions; a shortcut to the most recent executable, which will always be in the app's \Current folder; and a log file for that app.


My thinking is that this way I don't need to update the shortcut every time I update an app. But that means that before downloading a new update, I have to rename the \Current folder to its appropriate version number in a pre-download command, raising the question of where I'm going to get the version# from.


I'd like to update the app's log file every time a new version is downloaded, with date and version number. In order to rename the \Current folder, I'd first read its version number from the log file. I haven't tried to do this yet, but was wondering how I'd store that info between the two pre-download commands - one reading the version number from log file, the second renaming the \Current folder. Hence my original question about variables.


Perhaps there's an easier way. One alternative would be to use version numbers as the folder name for all versions, including the latest, as I always have version# accessible at the time of downloading. But then I'd need to update the shortcut, and the executable path and file vary greatly from app to app. Another possibility might be to read the version number from the Ketarin database, though I haven't looked into that (I store version# in a custom column).


Perhaps I'm making this too complicated, or overlooking something simple. The end result I'm looking for is storing all previous app versions, ideally in a folder named after the version number; and having a shortcut that can always access the executable of the latest app version.


Have your eyes glazed over yet? ;-)





Link to comment
Share on other sites

Have your eyes glazed over yet? ;-)

Not at all :-) Now it's my turn to ask you, after you read the below. :-)


First off, I'm really sorry, I'm so swamped right now and don't have time to dive into this in any real depth, but I'll give you as much as I can.


Yes I do believe the approach you outlined may be more complex than is required to achieve your objectives. But first I'd ask you to strip away "how" you've decided on (using shortcuts, organizing in folders, etc. those are all "implementation" and not desired objectives necessarily) and ask yourself just what it is you'd like to achieve with "some kind of as yet unknown how".


Because I'm thinking your real objective is not yet stated. This is only my supposition but it appears to me you may be trying to build a repository of current installers/portable apps etc., you want to be sure you don't lose any prior files just in case you need them, and you'd like to automate or semi-automate running the installation of the current version downloaded to your machine, and/or to multiple machines and not just the one with the downloaded app files?


As that's probably the objective of 80% of the people using Ketarin, I'm hoping that supposition is close! :-)


Given my supposition, I'll leave you now with some ideas and things to ponder: :-)


1. Most people scrape version from the webpage where the app is


2. Have a look at the Ketarin documentation (link at top of forum).


Even if you've looked at it before, go through it again. Forget the implementation ("how") and think about what really really want to achieve and what are your constraints. Yes you'll naturally be thinking "how do I use this" when you look at what's available with Ketarin, as in "if I do this I could use that to..." just stay open minded and away from forming an implementation design just yet.


Constraints are hard or physical world limitations the ultimate "how" must take into account. Example from your task, You do not want to lose, or lose track of, prior version files. That's a constraint on how you implement your objective -- one implementation method might sacrifice this and so is not a good design choice for you. Think along those lines first.


3. Search these forums, many people have posted their "hows" to for all or part of these things, many different implementations, with differing constraints. Again evaluate these other ideas for what they achieve, what constraints they obey, and whether they sacrifice any of your constraints. Just absorb ideas as 'building blocks' to the ultimate design.



I'll leave you with a brief sketch of my own setup from objectives point of view and my constraints...




I want to keep all the machines in my local network, installed with the current versions of the applications they use.




1. I want a local ("offline") repository that is available to me all the time. I do not want to be dependent on an internet connection or multiple places where these files might reside, I want them all together and local for my convenience.


2. Not all apps get installed on all machines, I want an automated or semi-automated way of installing only the ones I want to each machine.


3. Ketarin does not maintain all apps in the repository. Other methods will be employed to achieve the objectives, so the design I settle on must be compatible with other sources of getting current version files downloaded.


4. I do not want to lose my prior installation file copies, or their identity (name, version, dates, etc.) just in case I should want them again.


5. I do not want any method that is high maintenance or frequently fallable. If it requires either of those, manual updating is more efficient for me, however nice automation may be :-)


6. I don't want automatic installation of newest version when it arrives. In my experience it's been too much trouble to "automatically" push updates as soon as they arrive. I want to examine them first, and install to one machine at a time of my choosing and make sure it looks OK. THEN I'll update the other machines that use the app(s).







1. I don't need an ongoing automated method or semi-automated method for REPEAT re-install of same version. In other words, when the new version installer becomes available, if THAT is automated or semi-automated to install/update the appropriate machines that is good enough. If I should need to re-install anything that's probably a "one-off" situation for me and I'll do that manually, as I believe from experience it will be very high maintenance and problematic to attempt to automate the complete reinstallion of the same versions to their machines... so I don't need that complexity in my solution.


2. While it wouldn't be desirable for efficiency reasons, it doesn't matter to me if the implementation I settle on, collects a small number of duplicate installers. (I already have a separate automated process that runs and deletes exact duplicates from disk regardless of name.) So a little inefficiency in this manner, if it keeps my chosen implementation much simpler or less problematic, is OK with me.



I have additional portions to my objective, and additional more detailed constraints to my actual setup, but I hope the above is detailed enough to give you an idea how to first define what you're wanting to acheive before you settle on "how" you're going to achieve it.



Now a word about my own implementation, which uses a different approach from yours:


1. In the case of the apps Ketarin maintains for me, I use pre and post command scripts to MOVE the prior file to a separate repository. I keep two repositories -- all the prior versions are in one, and the current version Ketarin downloads is in another. (Other sources that keep up some of the apps the repository for me obey this same implementation design)


2. Ketarin's scripts build for me, executable batch files containing the name of the file just downloaded, so I don't care what it is called, Ketarin knew the name at the time of download and inserts it into a .bat file. My other sources do the same.


3. The .bat files are customized to one per machine. There won't be a .bat file for a particular machine if it doesn't need any of the versions just downloaded to the current version repository. Other than Ketarin itself, this is the only real ongoing maintenance task I have with my chosen implementation, to manually maintain the list of which apps go to which machines. The .bat files date/timestamped as I may collect several of them before I'm ready to install, I like this rather than appending to the same one all the time. Just a personal preference with how I like to work.


4. All the downloaded files are named including version, date/time, or other unique identifier for that version (not all authors build this right into their filenames, so I make sure I do when I download it). Therefore I don't need subdirectories for individual files and versions. What I have instead, are subdirectories for groups of similar applications (a subdirectory that holds all text editors, another that holds all MP3 players, etc.) Both my local and prior-version repository have the same structure, usually just one layer deep. ALL files with similar purpose live in the subdirectory.



So, when I am ready to install, I run the batch file(s). That's it.



The above is not actually my full objective and list of constraints and "don't care's". But I hope what I've written is complex enough to give you food for thought. Kick what you really want to accomplish without thinking "how", and really think about your constraints to that achievement. Then glean ideas from the documentation and this forum and I think your approach will turn into something a lot simpler :-)


I will check back on you later on when I can. But in the meantime make sure that no matter what you do, you have a lot of fun doing it!!!!


Best regards,



Link to comment
Share on other sites

P.S. I didn't necessarily know ALL of my constraints at the start. Think of as many as you can. Some I discovered as I did my research and homework on "how" I might string this together. I might like how so-and-so implemented something, but then I realized the downside is I don't get or I lose xxxxx. So I added a "must make sure I have xxxxx" to my list of constraints right then and there, so I wouldn't lose track of my constraints as I started to formulate my ultimate "how".

Link to comment
Share on other sites



The approach that I use is very similar to what appyface has described although I use a FreeNAS server available to any PC / Linux Box that is connected to my LAN. I use pre & post commands for delete, copy, move, etc. and extract with 7-Zip and Universal Extractor which archives all of my main installs in an 'Install Cache' folder on my FreeNAS. By design, the sub-folders are named by the current version of the app downloaded. In this way, all the machines that I build and maintain have access to this archive! For portability, I mirror this folder to a thumb drive. I use global commands to call 7-Zip and Universal Extractor from Ketarin. As appyface has suggested, the info required to do all this has been discussed at some point in the forum which may require a little searching to put it all together. If you run into any snags, let us know and we will try to help.

Link to comment
Share on other sites

That's a lot of depth for someone who's swamped, appyface :-)


Because I'm thinking your real objective is not yet stated. This is only my supposition but it appears to me you may be trying to build a repository of current installers/portable apps etc., you want to be sure you don't lose any prior files just in case you need them, and you'd like to automate or semi-automate running the installation of the current version downloaded to your machine, and/or to multiple machines and not just the one with the downloaded app files?


As that's probably the objective of 80% of the people using Ketarin, I'm hoping that supposition is close! :-)


Darn close. I want:

  • A repository of portable apps, current and previous versions (all app files, not just installers)
  • Automated installation of latest version where practical
  • The same apps available across multiple machines across LAN and Internet (implementation detail: currently successfully done using Windows Live Sync.)


In addition, I want to be able to invoke any of these portable apps via the Windows Start menu, not via a separate launcher (PStart, PortableApps, etc.).


I've scoured documentation and forums. I've learned all about version scraping and regular expressions, and haven't met a download site yet that I haven't been able to reliably scrape version information from (though I'm sure they exist :-)). I've learned how to use Ketarin variables, and how to automate installation of .exe, .zip and .paf packages, using 7-zip, Universal Extractor and AutoHotkey. And I've seen some good ideas on logging, which I haven't implemented yet. I've even contributed an AHK script to near-silently install PAF files.


I think I have a good idea of my objectives and constraints. The biggest (or at least, most pertinent) difference between our objectives is that I'm only dealing with portable apps, and I want to install/extract them at time of download. The other possible difference is how the installed apps are started - I want hem to be accessible the same way my non-portable apps are, via the Start menu.


Because of the last requirement (Start menu), I need static shortcuts to the unpacked app's executable file. That means I need a path that doesn't change when new versions are installed, so can't include the version number in it. But I want the app's previous versions to include version# in their paths.


That brings me back to my original question: when I'm about to download a new version of an app, how to determine the version# of the about-to-be-obsolete version currently installed, so that I can rename its folder with the version number.


At this stage, I'm thinking of logging downloads to a log file, including version number. In a Ketarin pre-download command, I could read the last line of the log file, use a regex to extract the version number, store it temporarily in an environment variable, then rename the about-to-be-obsolete version's folder (i.e. move the app) with its version# read from the environment variable. But I'm wondering if there might be a smarter way to tackle this...

Link to comment
Share on other sites

Why not a folder structure of:









1) Copy the zip file to the Archived folder

2) Delete the contents of the Current folder

3) Extract the newly downloaded app to the Current folder


If you do not want the Current version duplicated in the Archived folder, you could work out a pre-download move, etc....


The compressed versions in the Archived folder could include version info as part of their name.


A similar scheme could be used for installers...


Just my two-cents AussieJim. ;)

Link to comment
Share on other sites

The problem with that approach is that it doesn't satisfy the first criteria above - a repository of portable apps, current and previous versions (all app files, not just installers). If I nuke the contents of the Current folder, I'm nuking any INI files in there too, that I may later need.

Link to comment
Share on other sites

The INI and CFG files, etc. can be preserved with a double move/copy setup (i.e. move to a temp folder and then back). I'm convinced what you are attempting can be done with perseverance and possibly some compromise. I wish I had more time to test solutions for you but right now I'm swamped. :(

Link to comment
Share on other sites

I'm convinced there's a relatively simple, elegant solution, too :-). Just gotta find it!


If I'm going to copy INI files, I need to know what they are, which means customizing for every app. I'm not convinced *.INI, *.CFG, *.DAT is going to catch them all, and in some cases, a CFG etc. file might not be user customizations, and the newer file might be wanted.


I also thought about copying the installer to 2 locations, Current and Archived, and just installing over the top of the previous version in Current. That would usually leave previous .INI files intact, but some apps come with a blank or minimalist .INI file by default, which would overwrite my needed one.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.