how robust is fc.exe ?

[Larry__Weiss]

I'm trying to use fc.exe for some general source code comparisons and I'm finding out that it is
very buggy.

Anyone else have any experience using fc.exe ?

If so have you experienced bugs in the results, especially with respect to the line numbers you get
using the /N argument to fc.exe ?

- LarryW

[JJ]

Could you provide an example where it fails, that can be tested?

I can only think that the source codes was made under *NIX. Thus, they use
only LF as new lines instead of CR+LF. Or if they were from Mac, CR only.

[Larry__Weiss]

I played around with it some and the bug is triggered by records containing more than 127
characters (not including CR/LF delineation).

That's all it takes to throw fc.exe off the track.

[foxidrive]

Show us a reproducible example Larry. In the past it has been robust - I use Win7 atm.



--
foxi

[Larry__Weiss]

How to recreate:
Create a file named f1 with content as the three records, the first containing one character, the
second containing 128 characters, and the last containing one character.
Create a file named f2 with the same content as f1 except that the second record contains one
character instead of 128 characters:

f1:
a
1234567890 ... 123456789012345678
c

f2:
a
b
c

(I did not fill in all of the content of f1's second record above, but what I show is intended to
show that the second record has 128 characters in it).

Now execute
fc.exe f1 f2 /N

and you will get this erroneous output (again I abbreviated the extra long line)

C:>fc.exe f1 f2 /N
Comparing files f1 and F2
***** f1
1: a
2: 1234567890 ... 12345678901234567
3: 8
4: c
***** F2
1: a
2: b
3: c
*****

Just to clarify, the second line of f2 contains the characters between the double quotes below
(which you will probably see line wrapped)

"12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678"

And here is the actual output of fc.exe (indented by one space to show line wrapping in this message)

Comparing files f1 and F2
***** f1
1: a
2:
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567
3: 8
4: c
***** F2
1: a
2: b
3: c
*****

[frank.w...@gmail.com]

>I played around with it some and the bug is triggered by
>records containing more than 127
>characters (not including CR/LF delineation).

Have you considered what FC/? says about re-sync
adjustments and the number of permitted failures? I
don't think the comparisson is line oriented so "a\nb"
is not the same as "a\r\nb".

From an Android.

Frank

[foxidrive]

On Friday 19/10/2012 01:10, Larry__Weiss wrote:

>>>>> Anyone else have any experience using fc.exe ?
>>>>> If so have you experienced bugs in the results, especially with
>>>>> respect to the line numbers you get using the /N argument to fc.exe ?


>

> (I did not fill in all of the content of f1's second record above, but what I show is intended to
> show that the second record has 128 characters in it).
>
> Now execute
> fc.exe f1 f2 /N
>
> and you will get this erroneous output
>

> And here is the actual output of fc.exe (indented by one space to show line wrapping in this message)
>
> Comparing files f1 and F2
> ***** f1
> 1: a
> 2:
> 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567
> 3: 8
> 4: c
> ***** F2
> 1: a
> 2: b
> 3: c
> *****

Yes, I confirm this bug in Win 7.

It looks like FC uses a buffer of 128 bytes. I think there was a method of specifying the buffer size in
MSDOS but there isn't such an option in Win 7.

I hust checked - MSDOS V6.22 has a /LBn switch to set the number of lines in the buffer but not the line
length.

When you exceed 256 bytes it splits into three lines.


--
foxi

[foxidrive]

On Friday 19/10/2012 03:02, foxidrive wrote:

> I hust checked - MSDOS V6.22 has a /LBn switch to set the number of lines in the buffer but not the line
> length.

I missed seeing it but Win 7 has the /LBn too.



--
foxi

[Herbert Kleebauer]

An old posting:
https://groups.google.com/group/alt.msdos.batch.nt/browse_thread/thread/18921676b3134a00?hl=de&noredirect=true



Newsgroups: alt.msdos.batch.nt
Von: Herbert Kleebauer <k...@unibwm.de>
Datum: Thu, 29 May 2008 22:10:59 +0200
Lokal: Do 29 Mai 2008 22:10
Betreff: Re: FC /W Bug?
Drucken | Einzelne Nachricht | Original anzeigen | Diese Nachricht melden | Nachrichten dieses Autors suchen

- Zitierten Text ausblenden -

Scott Wegner wrote:

> I was wondering if you any of you are aware of any bugs in the FC
> command, specifically how it compares files with different EOL styles.

> It appears that FC will normally try to convert between unix- and
> Windows-style text files, and compare them as equal. We take
> advantage of this feature in our cross-platform software testing.

> FC /W test1.txt test2.txt

> and FC reports differences:

> Comparing files test1.txt and TEST2.TXT
> ***** test1.txt
> x
> ***** TEST2.TXT
> x
> *****

It's even worse. If I save your text file in DOS format
(<CR><LF>) as test1.txt and then make a copy and change
the last character in the file from "x" to "y" (line 2293)
(test2.txt still in DOS format), then a

"fc /w test1.txt test2.txt"

doesn't find any difference!!!!!! A

"fc /n test1.txt test2.txt"

does find the difference (x<->y), but in the non existing
line 2301.

Seems fc is usable only in binary mode.

[Larry__Weiss]

I played with different /LBn settings, but they did not help. Once the /LBn setting was high
enough to allow the comparison, the record length related bug kicked in.

[Larry__Weiss]

On 10/18/2012 11:02 AM, foxidrive wrote:
> On Friday 19/10/2012 01:10, Larry__Weiss wrote:
>>>>>> Anyone else have any experience using fc.exe ?
>>>>>> If so have you experienced bugs in the results, especially with
>>>>>> respect to the line numbers you get using the /N argument to fc.exe ?
>>>>

>>>> . . .

>
> Yes, I confirm this bug in Win 7.
>
> It looks like FC uses a buffer of 128 bytes. I think there was a method of specifying the buffer size in
> MSDOS but there isn't such an option in Win 7.
>
> I hust checked - MSDOS V6.22 has a /LBn switch to set the number of lines in the buffer but not the line
> length.
>
> When you exceed 256 bytes it splits into three lines.
>

Looks like we are stuck with this bug. I don't expect Microsoft to fix it.

I'll try truncating lines to 127 or less and live with it for now.
(Perhaps squeezing whitespace out before the truncation).

Or, switch to a 3rd party UNIX-like "diff" utility.

I'm writing a wrapper around the output to add line context (for example, 5 lines above and below
the difference).

[frank.w...@gmail.com]

After a few seconds on a Windows machine I see that

>Have you considered what FC/? says about re-sync
>adjustments and the number of permitted failures? I
>don't think the comparisson is line oriented so "a\nb"
>is not the same as "a\r\nb".

is all hogwash. My apology for the comment.

If you need to work-around this problem maybe you could
append a self-designated end of line marker to each line
in the files then use FOR to read FC's output and
concatenate lines if necessary to fix the output. I
could put together a general solution Saturday morning
but I expect someone else will have something before
then.


Frank

[Larry__Weiss]

On 10/18/2012 1:19 PM, Larry__Weiss wrote:
> I'll try truncating lines to 127 or less and live with it for now.
> (Perhaps squeezing whitespace out before the truncation).

> I'm writing a wrapper around the output to add line context (for example, 5 lines above and below
> the difference).
>

The wrapper to take leading whitespace away and truncate to 126 chars is working pretty well.
It turned out that 127 character lines triggered the bug.

It occurs to me that I could do some sort of checksum on each line, and create a files containing
only those checksums, and use fc.exe to compare the checksum files to get the line numbers that
define the difference sets.

I hesitate to stick with my workaround as it stands. There is a possibility I'm missing some
differences because of the truncation.

[frank.w...@gmail.com]

:: BEGIN SCRIPT :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: fcCmd.cmd
:: From the desk of Frank P. Westlake, 2012-10-20
:: Works around the FC line length limitation.
:: Only tested with the three-line sample so it will
probably need some work.
:: USAGE: Same as FC with this addition:
:: - Accepts a pipe or redirection as the second file
(i.e.
:: 'TYPE fileB | fcCmd fileA' and 'fcCmd fileA < fileB').
@Echo OFF
SetLocal EnableExtensions EnableDelayedExpansion
Set "ME=%~n0"
Set "TempDir=%TEMP%\%ME%.dir"
Set "SWITCHES= "
Set "NUMBERS="
Set "FILE_A="
Set "FILE_B="
Set "TEMP_A="
Set "TEMP_B="
:args
Set "arg=%~1"
IF DEFINED arg (
IF /I "!arg!" EQU "/B" (
FC %*
GOTO :EOF
) ELSE IF /I "!arg!" EQU "/N" (
SET "NUMBERS=!arg!"
) ELSE IF "!arg:~0,1!" EQU "/" (
SET "SWITCHES=!SWITCHES!!arg!
) ELSE IF NOT DEFINED FILE_A (
SET "FILE_A=!arg!"
FOR %%a in ("!arg!") Do (
SET "FILE_A=%%~fa"
SET "TEMP_A=%%~nxa"
)
) ELSE IF NOT DEFINED FILE_B (
FOR %%a in ("!arg!") Do (
SET "FILE_B=%%~fa"
SET "TEMP_B=%%~nxa"
IF /I "!TEMP_B!" EQU "!TEMP_A!" (
SET "TEMP_A=%%~na.1.%%~xa"
SET "TEMP_B=%%~na.2.%%~xa"
)
)
) ELSE (
(ECHO BARF: !arg!)>&2
GOTO :EOF
)
SHIFT
GOTO :args
)
IF NOT DEFINED FILE_A (
REM Let FC report the error.
FC %SWITCHES% %NUMBERS%
GOTO :EOF
)
MkDir "%TempDir%"
PushD "%TempDir%"
REM Pipe through MORE to avoid hanging with files that do not end with LF.
TYPE "%FILE_A%" | MORE | FINDSTR /N "^" >"%TEMP_A%"
IF DEFINED FILE_B (
TYPE "%FILE_B%" | MORE | FINDSTR /N "^" >"%TEMP_B%"
) ELSE (
REM Accept a pipe or redirection for the second file.
SET "TEMP_B=COMMAND LINE INPUT"
MORE | FINDSTR /N "^" >"!TEMP_B!"
)
Set /A "sync=1"
Set "save="
FOR /F "delims=" %%a in ('FC %SWITCHES% /N "%TEMP_A%" "%TEMP_B%"') Do (
Set "line=%%a"
IF "!line:~0,1!" NEQ " " (
IF DEFINED save (
ECHO.!save!
SET "save="
)
SET /A "sync=1"
ECHO.%%a
) ELSE (
Set "line=!line:~8!"
FOR /F "tokens=1* delims=:" %%A in ("!line!") Do (
IF %%A EQU !sync! (
IF DEFINED save ECHO.!save!
IF DEFINED NUMBERS (
Set "sync= !sync!"
Set "save=!sync!: !line:*:=!"
) ELSE (
Set "save=%%B"
)
Set /A "sync+=1"
) ELSE (
Set "save=!save!!line!"
)
)
)
)
IF DEFINED save ECHO.!save!
PopD
RD /S /Q "%TempDir%"
Goto :EOF
:: END SCRIPT :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

[frank.w...@gmail.com]

From frank.westlake:

>:: BEGIN SCRIPT
>::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>::::::
>:: fcCmd.cmd
>:: From the desk of Frank P. Westlake, 2012-10-20
>:: Works around the FC line length limitation.
>:: Only tested with the three-line sample so it will
>probably need some work.
>:: USAGE: Same as FC with this addition:
>:: - Accepts a pipe or redirection as the second file
>(i.e.
>:: 'TYPE fileB | fcCmd fileA' and 'fcCmd fileA <
>fileB').

I think those are the only two line wrap problems. I've
configured my message writer to wrap lines only if they
end with a space, so code doesn't get wrapped unless
it's a comment and I add the space out of habit.

Frank

[Larry__Weiss]

Thanks for the note about potential wrap.

I use the one preceding space adaptation to make them stick out.

[Larry__Weiss]

Thanks. As you predicted, it does have problems with large files.

- LarryW

On 10/20/2012 6:22 AM, frank.w...@gmail.com wrote:
> :: BEGIN SCRIPT :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> :: fcCmd.cmd
> :: From the desk of Frank P. Westlake, 2012-10-20
> :: Works around the FC line length limitation.
> :: Only tested with the three-line sample so it will probably need some work.
> :: USAGE: Same as FC with this addition:
> :: - Accepts a pipe or redirection as the second file (i.e.
> :: 'TYPE fileB | fcCmd fileA' and 'fcCmd fileA < fileB').
>

> ...
>

[Tom Del Rosso]

FC sucks eggs.

For text comparison done interactively I use CSDiff. It does whole
directory trees and shows which files are different, and you can click on
them to see the internal differences.

For comparing in a script I either use compare.exe, or work around the FC
bugs. I haven't used the /N switch much though.


--

Reply in group, but if emailing add one more
zero, and remove the last word.

[frank.w...@gmail.com]

From frank.westlake:
>:: BEGIN SCRIPT
>::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>:: fcCmd.cmd

This script should only be used if you know that the
file content is suitable. It prefixes source lines with
a line number then checks for line number
synchronization in FC's output. It is possible that a
line could contain at the right position the next line
number and cause a resynchronization error. For example,
this line 1, 2, and 3

12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012342:and more...
The real line 2.
The real line 3.

will be prefixed with the line number to this

1:1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234562:and more...
2:The real line 2.
3:The real line 3.

When it is compared by FC it will be split to this

1:123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
2:and more...
2:The real line 2.
3:The real line 3.


The script will not rejoin those first two lines because
it will incorrectly read the content "2:" as a line
number in what it calculates as the correct order. The
line following the first line, the normal second line,
since it begins with "2:" instead of the "3:" that the
script is looking for, will be appended to the last part
of the incorrect line 2.

1:123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
2:and more...2:The real line 2.
3:The real line 3.


Synchtonization will be correct again beginning with the
line labeled "3:".

Still, such resynchronization errors are far fewer then
the errors induced by FC alone.

Frank

[frank.w...@gmail.com]

From Larry__Weiss:

>Thanks. As you predicted, it does have problems with
>large files.

I suspect that you'll be finding another option but I
might be able to fix the script for larger files if you
could give me some details. The hard drive crashed on my
Windows computer Saturday night so it'll be a week or
more before I can look at your data and do any more work
on that script.

Frank

[Larry__Weiss]

On 10/21/2012 11:10 PM, Tom Del Rosso wrote:
> Larry__Weiss wrote:
>> I'm trying to use fc.exe for some general source code comparisons and
>> I'm finding out that it is very buggy.
>>
>> Anyone else have any experience using fc.exe ?
>>
>> If so have you experienced bugs in the results, especially with
>> respect to the line numbers you get using the /N argument to fc.exe ?
>
> FC sucks eggs.
> For text comparison done interactively I use CSDiff. It does whole
> directory trees and shows which files are different, and you can click on
> them to see the internal differences.
>For comparing in a script I either use compare.exe, or work around the FC
> bugs. I haven't used the /N switch much though.
>
>

Thanks for the recommendation of CSDiff.
http://www.componentsoftware.com/products/csdiff/
CSDiff has the command line option that I'm looking for that should be comparable to fc.exe

[Larry__Weiss]

I'm so sorry about your PC. I'll see if I can come up with some details sometimes this week if I
don't find an alternative.

Thanks!

[Tom Del Rosso]

Larry__Weiss wrote:
>
> Thanks for the recommendation of CSDiff.
> http://www.componentsoftware.com/products/csdiff/
> CSDiff has the command line option that I'm looking for that should
> be comparable to fc.exe

Sorry I didn't mention it. I forgot it had command line mode because in
scripts I almost always need binary comparison. I hope it does what you
need.

[Stan Dandy Liver]

1.4M (that's a full "crunchy" disk!) to do a compare!
--
[dash dash space newline 4line sig]

Albi CNU

[Todd Vargo]

For those who are tapped for HD space, you can use VBScript. :)

--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)

[foxidrive]

On Tuesday 23/10/2012 23:25, Todd Vargo wrote:
> On 10/23/2012 4:37 AM, Stan Dandy Liver wrote:
>>> Thanks for the recommendation of CSDiff.
>>> http://www.componentsoftware.com/products/csdiff/
>>> CSDiff has the command line option that I'm looking for that should be
>>> comparable to fc.exe
>>>
>>
>> 1.4M (that's a full "crunchy" disk!) to do a compare!

Word 5 came out on 6 floppy disks. Where have you been hiding? :)

> For those who are tapped for HD space, you can use VBScript. :)

Good plan. You can be lead programmer. I'd bet that there are better ways to display mismatches too.


--
foxi

[Todd Vargo]

Thanks for the nomination, but that exercise is better fitting for the
HD deficient or those needing custom features. I wonder if FC.EXE can
just be copied from XP. Has anyone tried that yet?

[Larry__Weiss]

On 10/23/2012 10:12 PM, Todd Vargo wrote:
> Thanks for the nomination, but that exercise is better fitting for the HD deficient or those
> needing custom features. I wonder if FC.EXE can just be copied from XP. Has anyone tried that yet?
>

FC.EXE works the same (flawed) way on XP as it does on Windows 7.

I just used a copy of FC.EXE from XP on Windows 7, and it executes, but has the same bugs.

- LarryW

[foxidrive]

Here's a routine to do a colour compare to the console. Just posted at Dostips forum by a regular.

Lines starting in column one have wrapped. I'm not sure if XP is supported...


@echo off
setlocal enableDelayedExpansion
set file1=%1
set file2=%2
for /f %%N in ('find /c /v "" ^<%file1%') do set "cnt=%%N"
for /f %%N in ('find /c /v "" ^<%file2%') do if %%N gtr %cnt% set "cnt=%%N"
call :initColorPrint
8<"%file1%" 9<"%file2%" (
for /l %%N in (1 1 %cnt%) do (
set "ln1="
set "ln2="
<&8 set /p "ln1="
<&9 set /p "ln2="
if !ln1! neq !ln2! (
call :strlen ln1 len
call :strlen ln2 len2
if !len2! gtr !len! set "len=!len2!"
set "ln1=.!ln1!"
set "ln2=.!ln2!"
set chunk=0
set "ln1.!chunk!="
set "ln2.!chunk!="
for /l %%A in (1 1 !len!) do (
set "change="
2>nul set /a "1/(chunk%%2)" && (
if "!ln1:~%%A,1!" equ "!ln2:~%%A,1!" set change=1
) || (
if "!ln1:~%%A,1!" neq "!ln2:~%%A,1!" set change=1
)
if defined change (
set /a chunk+=1
set "ln1.!chunk!="
set "ln2.!chunk!="
)
for %%B in (!chunk!) do (
set "ln1.%%B=!ln1.%%B!!ln1:~%%A,1!"
set "ln2.%%B=!ln2.%%B!!ln2:~%%A,1!"
)
)
if !chunk! gtr 0 (
call :printLn 1
call :printLn 2
echo(
)
)
)
)
call :cleanupColorPrint
pause
exit /b

:printLn
call :colorPrint 0F "File%1: "
for /l %%N in (0 1 %chunk%) do if defined ln%1.%%N (
2>nul set /a "1/(%%N%%2)" && (set color=0E) || set color=07
call :colorPrintVar !color! ln%1.%%N
)
echo(
exit /b

:colorPrint Color Str [/n]
setlocal
set "str=%~2"
call :colorPrintVar %1 str %3
exit /b

:colorPrintVar Color StrVar [/n]
if not defined %~2 exit /b
setlocal enableDelayedExpansion
set "str=a%DEL%!%~2:\=a%DEL%\..\%DEL%%DEL%%DEL%!"
set "str=!str:/=a%DEL%/..\%DEL%%DEL%%DEL%!"
set "str=!str:"=\"!"
pushd "%temp%"
findstr /p /A:%1 "." "!str!\..\x" nul
if /i "%~3"=="/n" echo(
exit /b

:initColorPrint
for /F "tokens=1,2 delims=#" %%a in ('"prompt #$H#$E# & echo on & for %%b in (1) do rem"') do set
"DEL=%%a"
<nul >"%temp%\x" set /p "=%DEL%%DEL%%DEL%%DEL%%DEL%%DEL%.%DEL%"
exit /b

:cleanupColorPrint
del "%temp%\x"
exit /b

:strLen string len -- returns the length of a string
:: -- string [in] - variable name containing the string being measured for length
:: -- len [out] - variable to be used to return the string length
:: Many thanks to 'sowgtsoi', but also 'jeb' and 'amel27' dostips forum users helped making this short
and efficient
:$created 20081122 :$changed 20101116 :$categories StringOperation
:$source http://www.dostips.com
( SETLOCAL ENABLEDELAYEDEXPANSION
set "str=A!%~1!"&rem keep the A up front to ensure we get the length and not the upper bound
rem it also avoids trouble in case of empty string
set "len=0"
for /L %%A in (12,-1,0) do (
set /a "len|=1<<%%A"
for %%B in (!len!) do if "!str:~%%B,1!"=="" set /a "len&=~1<<%%A"
)
)
( ENDLOCAL & REM RETURN VALUES
IF "%~2" NEQ "" SET /a %~2=%len%
)
EXIT /b


--
foxi

[foxidrive]

Here's a routine to do a colour compare to the console. Just posted at Dostips forum by a regular.

Lines starting in column one have wrapped. I'm not sure if XP is supported...

EDITED POST: to add the comments about the code.

As others have pointed out, it is not possible to color code, bold, underline, etc. within a simple text
file.

But you can use color to show the differences on the screen :!:

This is a bit slow, but it works. It uses the DosTips StrLen function. It also uses a variation of jeb's
print in color routine. The filenames are passed to the script as the first two parameters (%1 and %2).

The files do not have to have the same number of lines, nor do the lines have to be the same length.

But keep in mind that 2 files could be identical except one file could have an extra line at the
beginning. In this case the routine would report that all lines are different :!: :(

The console window must be wider than the largest line in either file.


http://www.dostips.com/forum/viewtopic.php?p=21210#p21210

[Todd Vargo]

On 10/25/2012 10:02 PM, foxidrive wrote:
> Here's a routine to do a colour compare to the console. Just posted at Dostips forum by a regular.
>
> Lines starting in column one have wrapped. I'm not sure if XP is supported...
>
> EDITED POST: to add the comments about the code.
>
> As others have pointed out, it is not possible to color code, bold, underline, etc. within a simple text
> file.
>
> But you can use color to show the differences on the screen :!:

<snip>

I think this was intended for a different thread. ;^)

[foxidrive]

On 18/10/2012 05:55, Larry__Weiss wrote:
> I'm trying to use fc.exe for some general source code comparisons and I'm finding out that it is
> very buggy.
>
> Anyone else have any experience using fc.exe ?
>
> If so have you experienced bugs in the results, especially with respect to the line numbers you get
> using the /N argument to fc.exe ?
>

> - LarryW
>

Somebody else had to use FC and wrote a tool for it.

Any lines in column 1 have wrapped.

http://www.dostips.com/forum/viewtopic.php?f=3&t=3968&view=unread#unread




@echo off
rem FComp.bat: Format FC output in a pleasant way
rem Antonio Perez Ayala - Nov/10/2012

if "%~2" neq "" goto start
echo Format FC output identifying added, deleted or updated sections
echo/
echo FCOMP filename1 filename2 [FC switches]
goto :EOF

:start
setlocal EnableDelayedExpansion
set while=if not
set do=goto endwhile
set endwhile=goto while
set "space= "
set "spaces39= "
set numbersInLines=
set params=%*
if "%params: /N=%" neq "%params%" set numbersInLines=TRUE
fc %3 %4 %5 %6 %7 %8 %9 %1 %2 > differences.txt
if %errorlevel% equ 0 echo FC: no differences encountered
if %errorlevel% equ 1 call :FormatFCOutput < differences.txt
del differences.txt
goto :EOF

:FormatFCOutput
set /P line=
echo %line%
set /P line=
:while Process each set of differences
%while% defined line %do%
set line=
set /P line=
set old=0
:while1 Load old section of this set
%while% "!line:~0,5!" neq "*****" %do%1
set /A old+=1
set oldLine[%old%]=!line!
:while1.5 PATCH FOR FC GLITCH: Concatenate next line while current is 127 chars. long
%while% defined line %do%1.5
%while% "!line:~126,1!" neq "" %do%1.5
set line=
set /P line=
set oldLine[%old%]=!oldLine[%old%]! !line!
%endwhile%1.5
:endwhile1.5
set oldLine[%old%]=!oldLine[%old%]!%space%
set line=
set /P line=
%endwhile%1
:endwhile1
set line=
set /P line=
set new=0
:while2 Load new section of this set
%while% "!line:~0,5!" neq "*****" %do%2
set /A new+=1
set newLine[%new%]=!line!
:while2.5 PATCH FOR FC GLITCH: Concatenate next line while current is 127 chars. long
%while% defined line %do%2.5
%while% "!line:~126,1!" neq "" %do%2.5
set line=
set /P line=
set newLine[%new%]=!newLine[%new%]! !line!
%endwhile%2.5
:endwhile2.5
set newLine[%new%]=!newLine[%new%]!%space%
set line=
set /P line=
%endwhile%2
:endwhile2
rem Identify the type of this set
echo/
rem PATCH FOR FC GLITCH: If both versions are size 2, it is an updated section
set /A "oldEqu2_And_NewNeq2=^!(old-2)*(new-2), newEqu2_And_OldNeq2=^!(new-2)*(old-2)"
if %old% equ 0 (
echo ====== NEW SECTION ADDED AT END OF FILE =====================================
echo/
for /L %%i in (1,1,!new!) do echo + ^|!newLine[%%i]:~0,70!
) else if %new% equ 0 (
echo OLD SECTION DELETED AT END OF FILE ===========================================
echo/
for /L %%i in (1,1,!old!) do echo -!oldLine[%%i]:~0,78!
) else if %oldEqu2_And_NewNeq2% neq 0 (
call :getBothLines[1]
if "!oldLine!" equ "!newLine!" (
echo ====== NEW SECTION ADDED ====================================================
echo/
echo(!oldLine[1]:~0,79!
set /A new-=1
for /L %%i in (2,1,!new!) do echo + ^|!newLine[%%i]:~0,70!
echo(!oldLine[2]:~0,79!
) else (
echo ====== NEW SECTION ADDED AT BEGINNING OF FILE ===============================
echo/
set /A new-=2
for /L %%i in (1,1,!new!) do echo + ^|!newLine[%%i]:~0,70!
)
) else if %newEqu2_And_OldNeq2% neq 0 (
call :getBothLines[1]
if "!oldLine!" equ "!newLine!" (
echo OLD SECTION DELETED ==========================================================
echo/
echo ---------!newLine[1]:~0,70!
set /A old-=1
for /L %%i in (2,1,!old!) do echo -!oldLine[%%i]:~0,78!
echo ---------!newLine[2]:~0,70!
) else (
echo OLD SECTION DELETED AT BEGINNING OF FILE =====================================
echo/
set /A old-=2
for /L %%i in (1,1,!old!) do echo -!oldLine[%%i]:~0,78!
)
) else (
echo ============================== SECTION UPDATED ==============================
echo/
if %old% lss %new% (
for /L %%i in (1,1,%old%) do call :showBothLines %%i
set /A old+=1
for /L %%i in (!old!,1,%new%) do call :showNewLine %%i
) else (
for /L %%i in (1,1,%new%) do call :showBothLines %%i
set /A new+=1
for /L %%i in (!new!,1,%old%) do call :showOldLine %%i
)
)
rem Pass to next set of differences
set /P line=
set line=
set /P line=
%endwhile%
:endwhile
exit /B


:getBothLines[1]
set oldLine=!oldLine[1]!
set newLine=!newLine[1]!
if defined numbersInLines (
set oldLine=!oldLine:*:=!
set newLine=!newLine:*:=!
)
exit /B


:showBothLines i
set oldLine=!oldLine[%1]!%spaces39%
echo !oldLine:~0,39!^|!newLine[%1]:~0,39!
set oldLine=!oldLine[%1]:~39,-1!
if defined oldLine (
set definedOldLine=TRUE
if "!oldLine:~39,1!" equ "" (
set oldLine=%spaces39%!oldLine!
set oldLine=!oldLine:~-39!
)
set separator=^&
) else (
set definedOldLine=FALSE
set oldLine=%spaces39%
set separator=^>
)
set newLine=!newLine[%1]:~39,-1!
:while3 Show a long new line at right side, old line or spaces at left side
%while% defined newLine %do%3
if "!newLine:~39,1!" equ "" (
set newLine=%spaces39%!newLine!
set newLine=!newLine:~-39!
)
echo !oldLine:~0,39!!separator!!newLine:~0,39!
if %definedOldLine% equ TRUE set oldLine=!oldLine:~39!
if defined oldLine (
if "!oldLine:~39,1!" equ "" (
set oldLine=%spaces39%!oldLine!
set oldLine=!oldLine:~-39!
)
) else (
set definedOldLine=FALSE
set oldLine=%spaces39%
set separator=^>
)
set newLine=!newLine:~39!
%endwhile%3
:endwhile3
if %definedOldLine% neq TRUE set oldLine=
:while4 Show the rest of a long old line at left side
%while% defined oldLine %do%4
if "!oldLine:~39,1!" equ "" (
set oldLine=%spaces39%!oldLine!
set oldLine=!oldLine:~-39!
)
echo !oldLine:~0,39!^<
set oldLine=!oldLine:~39!
%endwhile%4
:endwhile4
exit /B


:showNewLine i
echo %spaces39%^|!newLine[%1]:~0,39!
set newLine=!newLine[%1]:~39,-1!
:while5 Show a long new line at right side, spaces at left side
%while% defined newLine %do%5
if "!newLine:~39,1!" equ "" (
set newLine=%spaces39%!newLine!
set newLine=!newLine:~-39!
)
echo %spaces39%^>!newLine:~0,39!
set newLine=!newLine:~39!
%endwhile%5
:endwhile5
exit /B


:showOldLine i
echo(!oldLine[%1]:~0,39!
set oldLine=!oldLine[%1]:~39,-1!
:while6 Show a long old line at left side
%while% defined oldLine %do%6
if "!oldLine:~39,1!" equ "" (
set oldLine=%spaces39%!oldLine!
set oldLine=!oldLine:~-39!
)
echo !oldLine:~0,39!^<
set oldLine=!oldLine:~39!
%endwhile%6
:endwhile6
exit /B




--
foxi

[Larry__Weiss]

Thanks! Now, if we can just get Microsoft's attention, and get them to fix it.

- LarryW

On 11/11/2012 2:11 AM, foxidrive wrote:
> On 18/10/2012 05:55, Larry__Weiss wrote:
>> I'm trying to use fc.exe for some general source code comparisons and I'm finding out that it is
>> very buggy.
>>
>> Anyone else have any experience using fc.exe ?
>>
>> If so have you experienced bugs in the results, especially with respect to the line numbers you get
>> using the /N argument to fc.exe ?
>>
>> - LarryW
>>
>
> Somebody else had to use FC and wrote a tool for it.
>

>

> http://www.dostips.com/forum/viewtopic.php?f=3&t=3968&view=unread#unread
>

[foxidrive]

FWIW There has been an update, Larry.





--
foxi

[Larry__Weiss]

An update to what?

- Larry

[foxidrive]

The link I posted above. To the batch tool that tries to fix FC issues.

--
foxi

[Larry__Weiss]

On 11/13/2012 8:16 AM, foxidrive wrote:
> On 14/11/2012 00:36, Larry__Weiss wrote:
>> On 11/13/2012 12:25 AM, foxidrive wrote:
>>> On 13/11/2012 02:46, Larry__Weiss wrote:
>>>> On 11/11/2012 2:11 AM, foxidrive wrote:
>>>>> On 18/10/2012 05:55, Larry__Weiss wrote:
>>>>>> I'm trying to use fc.exe for some general source code comparisons and I'm finding out that it is
>>>>>> very buggy.
>>>>>> Anyone else have any experience using fc.exe ?
>>>>>> If so have you experienced bugs in the results, especially with respect to the line numbers you get
>>>>>> using the /N argument to fc.exe ?
>>>>>

>>>>> Somebody else had to use FC and wrote a tool for it.
>>>>>
>>>>> http://www.dostips.com/forum/viewtopic.php?f=3&t=3968&view=unread#unread
>> >>>
>> >>>
>> >> Thanks! Now, if we can just get Microsoft's attention, and get them to fix it.
>> >>
>>>

>>> FWIW There has been an update, Larry.
>>>
>>
>> An update to what?
>>
>

> The link I posted above. To the batch tool that tries to fix FC issues.
>

OK. Thanks.

I have written a pretty good PowerShell coded wrapper for fc.exe output
that allows it to find differences in spite of the line length issues
for most of my source code.

- Larry

[Todd Vargo]

On 11/13/2012 10:52 AM, Larry__Weiss wrote:
>
> I have written a pretty good PowerShell coded wrapper for fc.exe output
> that allows it to find differences in spite of the line length issues
> for most of my source code.

If you are going to spend the time to write a wrapper, it would be
better to just eliminate fc.exe from the equation and just write a
complete replacement.

[Larry__Weiss]

I wanted to do that, but the algorithm for finding a minimal set of differences is tricky.

Do you have some source code for that?

When the input is suitable for fc.exe, it does a good job of finding the differences.

- Larry

[frank.w...@gmail.com]

From Larry__Weiss :

>I wanted to do that, but the algorithm for finding a
>minimal set of differences is tricky.

It would not be hard to do with CMD script. I don't have
a Windows machine but it would be something like this:

SET "lineA="
FOR /F "delims=" %%a in ('(FINDSTR /N %fileA%^&FINDSTR /N %fileB%^)^|SORT') do (
if DEFINED lineA (
if "!lineA!" NEQ "%%a" (
ECHO %fileA%:!lineA!
ECHO %fileB%:%%a
)
SET "lineA="
) else (
SET "lineA=%%a"
)
)

If I synchronized it correctly that will print
unmatching lines. The sort would be confusing because
lines 1, 2, and 10 would be in the order 1, 10, 2.

Frank

[Todd Vargo]

On 11/14/2012 9:33 AM, Larry__Weiss wrote:
> On 11/13/2012 6:49 PM, Todd Vargo wrote:
>> On 11/13/2012 10:52 AM, Larry__Weiss wrote:
>>>
>>> I have written a pretty good PowerShell coded wrapper for fc.exe output
>>> that allows it to find differences in spite of the line length issues
>>> for most of my source code.
>>
>> If you are going to spend the time to write a wrapper, it would be
>> better to just eliminate fc.exe
>> from the equation and just write a complete replacement.
>>

> I wanted to do that, but the algorithm for finding a minimal set of
> differences is tricky.
>
> Do you have some source code for that?
>
> When the input is suitable for fc.exe, it does a good job of finding the
> differences.

No, I don't have source code for that. However, LBn is a maximum number
of consecutive mismatches, which seems to be strait forward. You
increment a counter each time a mismatch occurs. If the limit is
reached, you abort, ElseIf a match is found, reset the counter back to zero.

If you have to modify the input to make it suitable for fc.exe for files
with long lines, then you are adding unnecessary time to the process.
Also, since such a solution will become the norm on your system, that
means files without long lines will also be pre-processed.

[frank.w...@gmail.com]

From frank.westlake:

> FOR /F "delims=" %%a in ('(FINDSTR /N %fileA%^&FINDSTR
>/N %fileB%^)^|SORT') do (

FINDSTR needs a search string in both cases, perhaps
FINDSTR "^" ....

Frank

[Larry__Weiss]

On 11/15/2012 12:23 AM, Todd Vargo wrote:
> If you have to modify the input to make it suitable for fc.exe for files with long lines, then you
> are adding unnecessary time to the process. Also, since such a solution will become the norm on
> your system, that means files without long lines will also be pre-processed.
>

Yes, it definitely slows it down.

[Dr J R Stockton]

In alt.msdos.batch.nt message <13b004c22f4$frank.w...@gmail.com>,
Wed, 14 Nov 2012 18:44:43, frank.w...@gmail.com posted:

Which would be not nearly so useful.

I guess that your programming is not DOS-only, and that you use not only
[an] Android but also a Mac, UNIX, Linux, etc., system or systems. In
that case, you could look at
<http://www.merlyn.demon.co.uk/linxchek.htm#DF>
and suggest something in your OS roughly equivalent to WinXP command
prompt DIR /B /S > $DIR.TXT so that LINXCHEK can read the output
file into the right structure for subsequent use.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

[frank.w...@gmail.com]

From Dr J R Stockton :

>I guess that your programming is not DOS-only, and that
>you use not only
>[an] Android but also a Mac, UNIX, Linux, etc., system
>or systems.

It appears that you are addressing me because you
mention Android and other systems; if so, your
suggestion is misdirected and for the wrong system.

Frank

[Dr J R Stockton]

In alt.msdos.batch.nt message <13b069d9d9e$frank.w...@gmail.com>,
Fri, 16 Nov 2012 00:20:58, frank.w...@gmail.com posted:

I was judging from your "X-MUA: Frank P. Westlake's very own mail user-
agent baked with JavaScript on an Android", and your "I don't have a
Windows machine". But I wrote "guess", knowing that there was no
conclusive evidence. I know nothing of Android; but an answer for any
non-Windows system that runs JavaScript in local copies of Web pages
would be of interest. If you do not want to discuss it *here*, you
should have access to news:comp.lang.javascript.

Also, I was replying to you; but perhaps your system does not show that.

--
(c) John Stockton, nr London UK Reply address via Home Page.
news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
<http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.