I'm 'still' faffing about trying to get the GnuCOBOL testsuite running within windows without Mingw Unfortunately the 'easiest' way is to actually run the testsuite (for whatever version of the compiler) you have just built (under Mingw) and save all the stdout & stderr for each of the actual tests performed.
I've managed to do that by hacking the testsuite source - I can now save the stdout & error and each file is notated by the test number 1-1137 & the internal test 1-nn. There are a lot of tests.
eg:
Test 1 (compiler help and information) actually performs 16 internal tests before it moves on to Test 2.
The total number of tests performed during a testsuite (latest ver 4.0x) is 2586 from 1137 tests.
I'm trying to use gcdiff to compare 2 files and see the result (contained in stdout) from within a Cobol program.
How do I 'call' gcdiff - or is it not possible.
Either that or the worst case would be I have to use call "SYSTEM" passing GCDIFF file1 file2 1>save. and then
opening that save file to check the results - that seems rather messy to me.
Any help appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually with GC4 you can also use STDIN for a line sequential file, this way you can directly read the output via READ. The test suite should have a test case for that, showcasing it.
Thank you for the responses Simon - I didn't realise CALL "SYSTEM" would give a return code.
I 'may' try the STDIN method - but since I'm trying to get something that works on all versions of GnuCOBOL - I'd rather utilise something more standard over the 3 versions.
I actually resorted to the 'somewhat simple' - created a batch file & ran it - containing:
FOR %%I IN ("ABC*) DO ECHO %%~znI >>ERR which created a ERR file with the filesize & name of file - run that twice with different file names & then open that file within the program & just read & delete it. I get records like 456 fredfile & 234 billfile which is perfect.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Back to using GCDIFF - I appreciate it is used in the Mingw testsuite to compare a referencefile with the output of a particular test - I'm trying to use it to compare the same referencefile with the output of that same test performed under Windows (not Mingw).
Should I expect some sort of output from the GCDIFF program because even if the two files are completely different there is NO output produced in either the stderr or stdout files.
All of the uses of GCDIFF in the MIngw tests produce NO output - but then again this is to be expected if the test passes ??.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The test expects no output, if there is one and/or the return code is not zero the test fail.
From a quick glance at its source code it should output in different formats.
I suggest to check that first on the command line (where you also can see the options in its help).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have done that & the two files I am running gcdiff against are certainly different but still get NO output - am confused.
I appreciate that the testsuite expects there to be no difference otherwise the test has failed but I have not been able to get gcdiff to produce any output despite what the two files contain.
If two files have 5 records with a b c d e in one & a b x d e in the other I would expect some sort of output but get nothing - does the program actually do anything ??.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually - checking the test results of my latest build of ver 4.0 - dated Sep 26 - test 206 testing XFD directive and creation - the test runs OK according to the test results BUT if you check the actual data files produced and compared in the gcdiff test - reference and tspfilex.xd they are different - the .xd file has two extra fields in it.
Can you explain this ??.
Files and testsuite log attached.
In other tests the generated GnuCOBOL listing has both the Compiler version in the headings yet the reference file has the letters V.R.P. in that place - yet there are NO complaints from the testsuite.
Strange - You responded within minutes to my question 4 hours ago - yet when I question the program actually doing something there's no instant rebuttal. Maybe nobody actually checks that the program does the right thing - so long as the test doesn't fail that's ok.
I know I'm being a little rough but in my opinion the program doesn't do it's job, and I think I've actually proved that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually I've had a bigger merge from 3.x to trunk and in that have seen gcdiff actually working (the only thing that it does not that well is a multiline diff and handling of inserts (one file with 4 additional lines in was shown as "completely different from this place" instead of "has for lines more; but in general it "works").
I don't think so but maybe there's an issue on Win32 with that program?
What does gcdiff --help say? Does that call work?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Simon - I've shown above that specific test 206 - testing XFD directive and creation passes the tests with OK - but I presume it IS actually comparing the reference and tspfilex.xd.
I attached the two files above and they ARE DIFFERENT.
See attached screen dump of Beyond-compare showing that the D1 & D2 records have 4 extra bytes on the end. I know the program ignores the first line with the #.
If the files are different in the tested area then the test should fail - it's as simple as that.
If the test shows OK then the program isn't working correctly.
Bear in mind - The data I show below is from the Mingw testsuite - no Win32 involved.
I notice the program has had a couple of amendments since it appeared in early versions of 4.0x testsuite - perhaps one of those broke it. ?? I can't find it other than in the history files.
It ONLY checks the test file against the reference file as far as the length of the reference file record exists.
In the case of the two files above - test 206 reference & tspfilex.xd - the test file tspfilex.xd has 2 records longer than the reference file - presumably because the test file source program has been modified since the test reference file was created & someone hasn't bothered to change it.
AND ASSUMED THAT BECAUSE GCDIFF DOESN'T THROW AN ERROR - ALL IS OK.
I reversed the test so the reference file was tspfilex.xd & the test file was called reference and gcdiff threw up an error - see: attached file -If I show it inline the file shows in stupid bold case.
To my way of thinking - if the two files are different then GCDIFF should reflect that properly - not assume there isn't more data after the reference record ends. That's poor logic.
There are 41 tests in version 4.0 testsuite involving 67 uses of gcdiff & any one of them could be invalid but we'd never know.
I've also attached a list of the tests that use gcdiff (just for info).
Apart from the problem indicated above with GCDIFF - explained again below.
Where if the reference file has shorter data lines than the tested file (but the data is identical up to the end of the reference file line) then NO MISMATCH is reported.
If however the two files are reversed then since the 'now' reference file has longer data lines then the missing data in the 'now' test file IS REPORTED.
Another problem I have found recently is that if the option -I is used with a string containing blanks - then the use of ' (single quote) as a string boundary does not work under Win32 whereas using a " (double quote) does work.
EG: This line -I'Head Line" file1 file2 gives error Line': No such file or directory.
Whereas using -i"Head Line" file1 file2 works fine.
This is obviously a fault of Win32 as opposed to GCDIFF - but unfortunately for me - trying to replicate the testsuite tests under Windows - any tests using GCDIFF -I also use the ' (single quote) character which causes the error above. Easily fixed but a nuisance.
It 'would be nice' if the first problem could be fixed - & I notice that GCDIFF is only used in the testsuite for ver 4.0x - but since the data tested is actually different - then getting the correct result might be better.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm 'still' faffing about trying to get the GnuCOBOL testsuite running within windows without Mingw Unfortunately the 'easiest' way is to actually run the testsuite (for whatever version of the compiler) you have just built (under Mingw) and save all the stdout & stderr for each of the actual tests performed.
I've managed to do that by hacking the testsuite source - I can now save the stdout & error and each file is notated by the test number 1-1137 & the internal test 1-nn. There are a lot of tests.
eg:
Test 1 (compiler help and information) actually performs 16 internal tests before it moves on to Test 2.
The total number of tests performed during a testsuite (latest ver 4.0x) is 2586 from 1137 tests.
I'm trying to use gcdiff to compare 2 files and see the result (contained in stdout) from within a Cobol program.
How do I 'call' gcdiff - or is it not possible.
Either that or the worst case would be I have to use call "SYSTEM" passing GCDIFF file1 file2 1>save. and then
opening that save file to check the results - that seems rather messy to me.
Any help appreciated.
CALL "SYSTEM" ... RETURNING diff-state.
Actually with GC4 you can also use STDIN for a line sequential file, this way you can directly read the output via READ. The test suite should have a test case for that, showcasing it.
Thank you for the responses Simon - I didn't realise CALL "SYSTEM" would give a return code.
I 'may' try the STDIN method - but since I'm trying to get something that works on all versions of GnuCOBOL - I'd rather utilise something more standard over the 3 versions.
I actually resorted to the 'somewhat simple' - created a batch file & ran it - containing:
FOR %%I IN ("ABC*) DO ECHO %%~znI >>ERR which created a ERR file with the filesize & name of file - run that twice with different file names & then open that file within the program & just read & delete it. I get records like 456 fredfile & 234 billfile which is perfect.
Back to using GCDIFF - I appreciate it is used in the Mingw testsuite to compare a referencefile with the output of a particular test - I'm trying to use it to compare the same referencefile with the output of that same test performed under Windows (not Mingw).
Should I expect some sort of output from the GCDIFF program because even if the two files are completely different there is NO output produced in either the stderr or stdout files.
All of the uses of GCDIFF in the MIngw tests produce NO output - but then again this is to be expected if the test passes ??.
The test expects no output, if there is one and/or the return code is not zero the test fail.
From a quick glance at its source code it should output in different formats.
I suggest to check that first on the command line (where you also can see the options in its help).
I have done that & the two files I am running gcdiff against are certainly different but still get NO output - am confused.
I appreciate that the testsuite expects there to be no difference otherwise the test has failed but I have not been able to get gcdiff to produce any output despite what the two files contain.
If two files have 5 records with a b c d e in one & a b x d e in the other I would expect some sort of output but get nothing - does the program actually do anything ??.
Actually - checking the test results of my latest build of ver 4.0 - dated Sep 26 - test 206 testing XFD directive and creation - the test runs OK according to the test results BUT if you check the actual data files produced and compared in the gcdiff test - reference and tspfilex.xd they are different - the .xd file has two extra fields in it.
Can you explain this ??.
Files and testsuite log attached.
In other tests the generated GnuCOBOL listing has both the Compiler version in the headings yet the reference file has the letters V.R.P. in that place - yet there are NO complaints from the testsuite.
Last edit: David Wall 2021-10-01
Strange - You responded within minutes to my question 4 hours ago - yet when I question the program actually doing something there's no instant rebuttal. Maybe nobody actually checks that the program does the right thing - so long as the test doesn't fail that's ok.
I know I'm being a little rough but in my opinion the program doesn't do it's job, and I think I've actually proved that.
Actually I've had a bigger merge from 3.x to trunk and in that have seen gcdiff actually working (the only thing that it does not that well is a multiline diff and handling of inserts (one file with 4 additional lines in was shown as "completely different from this place" instead of "has for lines more; but in general it "works").
I don't think so but maybe there's an issue on Win32 with that program?
What does
gcdiff --helpsay? Does that call work?Simon - I've shown above that specific test 206 - testing XFD directive and creation passes the tests with OK - but I presume it IS actually comparing the reference and tspfilex.xd.
I attached the two files above and they ARE DIFFERENT.
See attached screen dump of Beyond-compare showing that the D1 & D2 records have 4 extra bytes on the end. I know the program ignores the first line with the #.
If the files are different in the tested area then the test should fail - it's as simple as that.
If the test shows OK then the program isn't working correctly.
Bear in mind - The data I show below is from the Mingw testsuite - no Win32 involved.
I notice the program has had a couple of amendments since it appeared in early versions of 4.0x testsuite - perhaps one of those broke it. ?? I can't find it other than in the history files.
Finally found the problem with GCDIFF.
It ONLY checks the test file against the reference file as far as the length of the reference file record exists.
In the case of the two files above - test 206 reference & tspfilex.xd - the test file tspfilex.xd has 2 records longer than the reference file - presumably because the test file source program has been modified since the test reference file was created & someone hasn't bothered to change it.
AND ASSUMED THAT BECAUSE GCDIFF DOESN'T THROW AN ERROR - ALL IS OK.
I reversed the test so the reference file was tspfilex.xd & the test file was called reference and gcdiff threw up an error - see: attached file -If I show it inline the file shows in stupid bold case.
To my way of thinking - if the two files are different then GCDIFF should reflect that properly - not assume there isn't more data after the reference record ends. That's poor logic.
There are 41 tests in version 4.0 testsuite involving 67 uses of gcdiff & any one of them could be invalid but we'd never know.
I've also attached a list of the tests that use gcdiff (just for info).
Last edit: David Wall 2021-10-02
Apart from the problem indicated above with GCDIFF - explained again below.
Where if the reference file has shorter data lines than the tested file (but the data is identical up to the end of the reference file line) then NO MISMATCH is reported.
If however the two files are reversed then since the 'now' reference file has longer data lines then the missing data in the 'now' test file IS REPORTED.
Another problem I have found recently is that if the option -I is used with a string containing blanks - then the use of ' (single quote) as a string boundary does not work under Win32 whereas using a " (double quote) does work.
EG: This line -I'Head Line" file1 file2 gives error Line': No such file or directory.
Whereas using -i"Head Line" file1 file2 works fine.
This is obviously a fault of Win32 as opposed to GCDIFF - but unfortunately for me - trying to replicate the testsuite tests under Windows - any tests using GCDIFF -I also use the ' (single quote) character which causes the error above. Easily fixed but a nuisance.
It 'would be nice' if the first problem could be fixed - & I notice that GCDIFF is only used in the testsuite for ver 4.0x - but since the data tested is actually different - then getting the correct result might be better.