User to user discussion and support for UltraEdit, UEStudio, UltraCompare, and other IDM applications.

This forum is user-to-user based and not regularly monitored by IDM.
Please see technical support page on how to contact IDM.
7 posts Page 1 of 1
I was caught off guard when I was unable to do a simple grep search of the UltraCompare output text file. I was simply trying to see if the files were identical (this was part of a batch file which compares several hundred files). Is there a way to turn off this formatting "feature" for text output?

If not, does anyone know of a DOS program that can convert this output file to "standard" ASCII? As a workaround I piped the output of a "type <filename>" to grep for the search and then fielded the command errorlevel. There ought to be an easier way.

Is there a program option that does not generate an output file if the 2 files are identical?
The results file is by default a Unicode file with UTF-16 Little Endian encoding which contains the appropriate BOM (byte order mark) and of course lots of null bytes. If you compare only ASCII/ANSI files and want to process the results file within a batch script, it is of course better to use ASCII/ANSI encoding for the results file.

There is the setting Save result in Unicode in configuration at Backup & Save which must be unchecked to get the results encoded in ASCII/ANSI. The configuration can be opened in toolbar/menu mode by clicking in menu Options on Configuration or in ribbon mode by clicking on ribbon tab Home on item Settings (top right item).

By the way: type "UC Results File.txt" >AnsiResults.txt can be used in a batch file to convert a UTF-16 LE encoded file to ASCII/ANSI file as long as the results file contains really on ASCII characters.

The help of UltraCompare contains on Contents tab under Getting Started the page Command Line Options. You have not described what you actually do in your batch file, but for a simple comparison of two files on equality there is the command line option -qc which is designed for being used by batch files.
Best regards from Austria
Thanks for the reply. I'm sorry it's taken so long to get back. I thought that I had auto-notify turned ON to let me know when someone posted a reply. (I checked the box on the Options, below for a reply to this.)

I have unchecked the "Save result in Unicode" box from the GUI side of things. Will this, then, change that for the command-line invocation, as well?

The last thing that my batch file does, for ~1200 instances, is to compare 2 files. If they are different, I want the full report of differences, otherwise I do not want the output file created. I was trying to do this with a grep of the output file for "identical" to then delete that output file, to accomplish this. That is where I ran up against the issue with the null bytes. I ended up type(ing) the UC output file to another file to then perform the grep, like your hint said. This just seemed a little awkward, but if the GUI option setting does not affect the command-line, then I will have to live with this.

Thanks for you reply calls always uc.exe for comparison and uc.exe reads the current user configuration settings from registry respectively INI file and overwrites those which are specified on command line for the actual comparison. So yes, unchecking Save result in Unicode produces a results file in ASCII/ANSI also on invocation from console.

I can't really answer your second question as I don't know which type of comparison you do on the ~1200 files. Do you run a basic folder comparison, a full folder comparison, a smart folder comparison, or do you compare always two files individually with a binary or a text comparison without or with ignoring options?

Show us the commands used in your batch file and I can suggest perhaps something better than currently used by you.
Best regards from Austria
That's great to hear that this configuration option data is preserved for the command line, as well. The command I use is below, where <...> will be substituted with its respective folder path. I wasn't sure that a global symbol had been set for UC when it was installed, so I forced the issue.

set uc="C:\Program Files\IDM Computer Solutions\UltraCompare\uc.exe"
%uc% -t <folder path 1>\%3 <folder path 2>\%3 -a -o <Dif Output folder path>\%3
I suggest to use a batch file with following code where third parameter passed to the batch file is the name of the file without path:

Code: Select all
@echo off
setlocal EnableExtensions EnableDelayedExpansion
cd /D "%ProgramFiles%\IDM Computer Solutions\UltraCompare"
for /F %%I in (' -qc "<folder path 1>\%~3" "<folder path 2>\%~3"') do (
    set "Result=%%I"
    if "!Result:~0,4!" == "Diff" -a -t "<folder path 1>\%~3" "<folder path 2>\%~3" -o "<Dif Output folder path>\%~3"

Windows command processor requires that the application to run by FOR is specified without surrounding double quotes in this case with that command line which is the reason why the current working directory is switched to program files folder of UltraCompare. The command ENDLOCAL restores the initial working directory.

English is executed for a quick binary comparison of the file in the two different directories. The result is just Same or Different for this comparison.

It would be fine if would additionally on a quick binary comparison exit with return code 1 on different files and with exit code 0 only on identical files. But this is not the case and therefore usage of language independent errorlevel for results evaluation is not possible as demonstrated below with using fc.exe for the quick binary comparison.

Well, I could see on a test with an older version of UltraCompare (v15.10.0.20) that does not really output just Same or Different, but appends an additional carriage return to this string. That's a problem because this lets a simple string comparison with below line always fail.

Code: Select all
    if "%%I" == "Different" -a -t "<folder path 1>\%~3" "<folder path 2>\%~3" -o "<Dif Output folder path>\%~3"

The loop variable holds also the erroneous carriage return and the strings are for that reason never equal.

As a workaround for this specific issue the result is assigned from the loop to an environment variable and compared are only the first 4 characters of the environment variable case-sensitive with the string Diff.

In case of the two compared files are not binary equal a text comparison is made writing the differences into the output file.

This task could be also achieved with the following batch code using Windows standard console application fc.exe for the quick binary comparison and UltraCompare only for producing the output on different files:

Code: Select all
@echo off
%SystemRoot%\System32\fc.exe /B "<folder path 1>\%~3" "<folder path 2>\%~3" >nul
if errorlevel 1 "%ProgramFiles%\IDM Computer Solutions\UltraCompare\uc.exe" -a -t "<folder path 1>\%~3" "<folder path 2>\%~3" -o "<Dif Output folder path>\%~3"

Both solutions can't be used if for text comparison some ignore options are enabled by default in configuration and therefore each text comparison is a smart comparison on which 2 text files being binary not equal can be nevertheless equal with taking the ignoring options into account.

In this case it would be really needed to run always a text comparison with producing an output file and using FINDSTR to check if the output file contains the information that there are no differences and delete the output file in this case.

Code: Select all
@echo off
"%ProgramFiles%\IDM Computer Solutions\UltraCompare\uc.exe" -a -t "<folder path 1>\%~3" "<folder path 2>\%~3" -o "<Dif Output folder path>\%~3"
%SystemRoot%\System32\findstr.exe /M /L /C:"0 : 0 Line(s) diff" "<Dif Output folder path>\%~3" >nul
if not errorlevel 1 del "<Dif Output folder path>\%~3"

The string "0 : 0 Line(s) diff" must be adapted according to used version of UltraCompare and configured format for results file.
Best regards from Austria

You've given me a lot to chew on here. Thanks for all of the input. I have some other pressing tasks that will keep me from really checking all this out, at the present time, but you can close this for now.
7 posts Page 1 of 1