Welcome!

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

SignUp Now!

how to compare version strings

Jun
137
3
Is there a TCMD function written to compare two version strings? Typically I might have two files with the same name, and want to know which one has the greater version. One is 3.10.0.0 and the other is 3.2.0.0. Obviously 3.10.0.0 is greater, but if we use the regular string compare 3.10.0.0 GT 3.2.0.0, it says that 3.2.0.0 is greater. I can write a function, but wanted to avoid it if there is already something and I'm just missing it.
 
First, TCMD is a tabbed user interface, it has NO functions. You must be referring to the command processor, TCC.

Unfortunately the variety in version strings makes this infeasible. See HELP -> @VERINFO. Once upon a time some vendors used the hour and minute fields of the file modification time stamp as the major and minor version, but it became unusable over the years, esp. since http transfer does not preserve filestamps. If the installer of the specific software you are interested in recreates the file modification stamps, as does the TCMD installer, you can just compare them to find the later version. If the dates are not reliable, AND the product of interest uses a version string composed of a series of dot-separated decimal integers, you could use the function %@word[".",%n,%version_info] to iterate through all fields, and use "IF %file1_fieldN LT %file2_fieldN echo file2 is newer", taking advantage of the TCC string comparison rule: if and only if both strings are numeric as defined in the description of the @NUMERIC function, the comparison is of the numeric values, so 9 is less than 10 - just as you want it.
--
HTH, Steve
 
Yes, of course I meant TCC. I don't care for TCMD, much preferring TCC, but that's for another time and place.

What you've suggested is exactly what I implemented. I wrote a batch file that returns different return codes based on the results of the comparison, and then filter it through an @execstr function call, since it was just too complicated to fit in a function.

BTW, our product installers (which I am the author of all of the products developed at our site) do not touch file versions. Some of our products set their file versions at compilation time, and the product version is set to match that string as well. But regardless, I've got what appears to be a working "function" now; I was just hoping there was a built-in that would be far more efficient.
 
Something else to keep in mind is many times it is sufficient to be interested in "different" and not necessarily "newer". If it is your habit to continually keep your software up to date, when the FileVersions are different, that is good enough to proceed with the update.
 
I appreciate the feedback, Steve and Scott. I've never used plugins, so I'll look into that. As for different versus newer, that won't work, because I've seen instances for some packages where the date/time is newer, but the version is older. Obviously an MSI installer will handle this properly, but my update batch file wouldn't. I have thought of that and handled it, though.
 
Something else to keep in mind is many times it is sufficient to be interested in "different" and not necessarily "newer". If it is your habit to continually keep your software up to date, when the FileVersions are different, that is good enough to proceed with the update.
I appreciate the feedback, Steve and Scott. I've never used plugins, so I'll look into that. As for different versus newer, that won't work, because I've seen instances for some packages where the date/time is newer, but the version is older. Obviously an MSI installer will handle this properly, but my update batch file wouldn't. I have thought of that and handled it, though.
Excellent point, Scott! When I know the installer is the newest available, any difference between its version string and the version string of the already installed program indicates updating ought to be performed, one need not parse the string to determine where they differ.

MickeyF: If you are a reasonably good C++ programmer (which I am not), plugins are not complicated, and offer you close to the usual 60:1 speed improvement of compiled vs. interpreted code. Delphi and other languages have also been used by developers of TCC plugins.
 
A long time ago there was a compiler for .btm scripts that would produce a .exe file. That's no longer available, right (to produce either a .exe or a .dll plugin from the .btm)? Because I already wrote my script, and would rather not reinvent the wheel.
 
You are correct, only the BATCOMP command is available, which is primarily for reducing batch file size (rarely relevant) and to allow a simple encryption to make it difficult for the unauthorized to access the source code (which might contain password or other protected information).
 
Yes, BATCOMP was what I couldn't remember but now see. And I also see that it doesn't speed things up to any degree, so it's no help. Oh well, it was worth asking. Thanks for everything.
 
You are welcome. BTW, I doubt if any user would complain about the extra time the version comparison takes using a batch file instead of a plugin (even if they were aware of it). OTOH if the issue is that you as a system administrator need to watch deployment of new software to many systems for a longer time, you might consider the brute force approach - install the new version unconditionally, after all, would anyone have the newest version without your knowledge?
 
First, I'm not dealing with production code. This is merely my efforts at maintaining a bunch of development computers I use. It's all just for my own use, and not anyone else's. Second, sometimes I get files I have to incorporate into my systems that come from others, which is why the date/time is sometimes messed up.

The performance is an issue (albeit not that big) only because sometimes I have to go through thousands of files at a time. Anyway, I think we've beaten this poor horse long enough.
 

Similar threads

Back
Top