No announcement yet.

Inconsistent behavior with the comparison results in Linux compared to Windows

  • Filter
  • Time
  • Show
Clear All
new posts

  • Inconsistent behavior with the comparison results in Linux compared to Windows


    I am trying to automate folder Comparision through java in the Linux Red Hat environment.
    On windows, the application gives expected results for comparison as match and mismatch for the files. But when I run the same application on Linux the result is not expected. It shows all the files as Binary same and returns the exit code as 1.
    The files in the folders have differences and have been checked manually.

    I am using the below code:

    1. To get the exit code of the file to find match or mismatch:
    bcompareExePath = bcompare;
    processBuilder.command(bcompareExePath, "-qc=binary", file1, file2);

    2. Command to get the Html output file:
    bcompareExePath = bcompare;
    processBuilder.command(bcompareExePath, bcompareScriptPath, sourceFile, destinationFile, outputFilePath, reportType);

    3. ScriptFile.txt
    text-report layout:"%4" &
    options:display-mismatches &
    output-to:"%3" output-options:html-color "%1" "%2"

    When I try the same code on windows I get correct results, while in Linux the code shows all files as Binary same and generates no Html file.

  • #2

    When are you calculating the return code? -qc would return the results of the scan, but the script run would return 1 for a successful script. If these are run sequentially, then the later would update the ErrorLevel.

    If you remove 2 and 3, does checking Error level for -qc return the results you expect?

    It would also be good to verify on the command line, outside of your code, that the return codes are what you expect, to verify the current user settings are loaded and used, and nothing external is updating the ErrorLevel between running and checking for it.

    On Windows, Bcompare.exe and BComp.exe also don't wait on the command line. is more often needed to then echo %ErrorLevel%.
    Aaron P Scooter Software


    • #3
      Hello Aaron,

      Firstly I would thank you for your response.

      The java code first uses point 1 to get the return code and depending on the return code it checks if the file is equal or different, then the code calls point 2 to generate the HTML comparison report. I am having a large volume of files (bulky data) to be compared automatedly by the application.
      But from the application on the very first instance i.e. on point 1, I get the wrong return codes as Binary same (1) for all the files.

      However, when I verify the command line outside the code and I get the expected resultant file, I am using the below command for checking it
      bcompare "@/script/ScriptFile.txt" "file1" "file2" "Result.html"
      I have purchased a copy of beyond compare and the BC version is 4.3.7 (build 25118) running on a Linux server OS: Red Hat Enterprise Linux Server release 7.9 (Maipo) I would like to know if the version of BC compatible with the Linux?


      • #4

        RHEL 7 is in our supported list:

        And yes, you have the right general strategy of running the -qc first, determining the error code, and then running bc again with @script to generate the report.

        So if you run the command line outside of your external automation script, you get the correct error, but when incorporated into your automation, you always see "1"? Just to verify, is your manual command for verifying point 1 outside of your automation:
        bcompare -qc=binary "file1" "file2"
        And the values match the Help file documentation (1 = Binary same, 11 = binary differences)?

        It's not uncommon for a process to set a return code of 1; could anything else be running that is setting over the return code before you get a chance to read it?
        Aaron P Scooter Software


        • #5

          Thank you for the response, when I run the command line outside of the automation script, using bcompare -qc=binary "file1" "file2" I see the correct $errorlevel code as expected.

          I don't suspect anything else would override the error code before I read it, any limitation that beyond compare has on the Linux version that could help me to drill down the root cause. As I am unable to get the root cause that is causing the wrong result displayed.

          Thank you !


          • #6

            Would it be possible to get a more complete echo of the script construction at each step? The return code for -qc=binary really should match. If it were a rules-based scan, a different in user settings might have an impact, if the user account was somehow different between the terminal and automation attempts, but =binary should match either way.
            Aaron P Scooter Software