How to get an ERRORLEVEL from FC file comparison
William Allen
A number of Batch questions we've dealt with recently have involved
obtaining an ERRORLEVEL from the FC command when comparing files. The
problem is that FC doesn't return a meaningful ERRORLEVEL to allow
a Batch file to distinguish whether or not the comparison result
was files_are_same/files_are_different. FC returns ERRORLEVEL 0
for comparisons regardless of same/different (see Note 1 at end
for meaningful ERRORLEVELs that FC does return).
The approach we used in a recent answer in alt.msdos.batch is useful:
(a) Using the FC command as normal.
This screen capture shows operation [with my annotations added] in
a Return-Code shell (note that this shows transient ERRORLEVELs
during pipes, but your Batch file will not "see" these). It shows
that FC returns ERRORLEVEL 0 whether or not the two files differ.
============Screen capture Windows 95
C:\WORK>command /z /k
Return code (ERRORLEVEL): 0
WARNING: Reloaded COMMAND.COM transient
C:\WORK>ECHO. File One and Two are the same>FILE1.TXT
C:\WORK>ECHO. File One and Two are the same>FILE2.TXT
C:\WORK>ECHO. File three differs from either>FILE3.TXT
C:\WORK>fc file1.txt file2.txt
Comparing files FILE1.TXT and file2.txt
FC: no differences encountered
Return code (ERRORLEVEL): 0 [FC comparison returns 0]
C:\WORK>fc file1.txt file3.txt
Comparing files FILE1.TXT and file3.txt
****** FILE1.TXT
File One and Two are the same
****** file3.txt
File three differs from either
******
Return code (ERRORLEVEL): 0 [FC still returns 0]
C:\WORK>
============End screen capture
(b) Filter that result with FIND
The output from FC is on STDOUT, and can be filtered with FIND.
The ****** highlighter output when files differ is language
independent and a string of asterisks can be tested for
with FIND as follows:
fc file1.txt file2.txt | find "***">NUL
ERRORLEVEL=1 files [1]dentical (i/1=mnemonic)
ERRORLEVEL=0 files n[0]n-identical (o/0=mnemonic)
This screen capture shows operation [with my annotations added] in
a Return-Code shell (note that this shows transient ERRORLEVELs
during pipes, but your Batch file will not "see" these). Files are as
before: FILE1.TXT and FILE2.TXT are the same, FILE3.TXT differs from
either of them.
============Screen capture Windows 95
C:\WORK>command /z /k
Return code (ERRORLEVEL): 0
WARNING: Reloaded COMMAND.COM transient
C:\WORK>fc file1.txt file2.txt | find "***">NUL
Return code (ERRORLEVEL): 0 [transient ERRORLEVEL from FC]
Return code (ERRORLEVEL): 1 [final ERRORLEVEL from FIND=1]
C:\WORK>fc file1.txt file3.txt | find "***">NUL
Return code (ERRORLEVEL): 0 [transient ERRORLEVEL from FC]
Return code (ERRORLEVEL): 0 [final ERRORLEVEL from FIND=0]
C:\WORK>
============End screen capture
As I say, the mnemonic for the line
fc file1.txt file2.txt | find "***">NUL
is:
ERRORLEVEL=1 files [1]dentical (i/1=mnemonic)
ERRORLEVEL=0 files n[0]n-identical (o/0=mnemonic)
See our Batch Course (Lesson 20) Exercises 50-56 for a detailed
series of interactive Exercises to allow you to work through the
building of a similar (more complex) Win95/98/ME command line:
:: Set ERRORLEVEL 1 if %1 contains non-numerics
fc /1%1 NUL NUL | find /c "FC:" | find "1">NUL
(This line is used in a Batch file to test whether a command-line
parameter, such as %1, is entirely numeric or not).
The line above is from an original idea by me, with help improving
the syntax from Frank-Peter Schultze.
The language independent syntax to test FC output to get meaningful
ERRORLEVELs was first drawn to my attention by Laura Fairhead.
--
William Allen
Free interactive Batch Course http://www.allenware.com/icsw/icswidx.htm
For example Batch Files see: http://www.allenware.com/find?BatchLibrary
Creative Technical Writing - Allen & Company: http://www.allenware.com/
Note 1: Quoted from our ERRORLEVEL list:
=====
FC.EXE
(a) Insufficient number of filespecs = ERRORLEVEL 1
(b) Too many filenames on command line = ERRORLEVEL 1
(c) Sharing Violation + Abort reply = ERRORLEVEL 5
(Note: Fail reply returns ERRORLEVEL 0)
(d) Drive not ready = ERRORLEVEL 18
(Note: Fail reply returns ERRORLEVEL 0)
Note: when a command encounters a device not ready condition (and
possibly generates the Abort, Retry, Fail message), the reply you
give (or supply automatically in a COMMAND.COM /f/c Fail-continue
shell) sometimes affects what ERRORLEVEL the command will return.
=====
To download our list of ERRORLEVELs returned by most commands:
http://www.allenware.com/mcsw/errorlevels.zip
Note 2:
For an explanation of Batch technical terms such as STDOUT, see our
Batch Reference Sesssion: http://www.allenware.com/icsw/icswref.htm
billious
"William Allen" <_w...@email.com> wrote in message
news:423ac403$0$20513$ed2e...@ptn-nntp-reader04.plus.net...
Unfortunately William, the files-are-different detection using "****"
doesn't work for non-text files.
I'd suggest
fc file1 file2 >tempfile
echo .>>tempfile
type tempfile|find /c /v "" tempfile2
dir tempfile2|find " 3 byte" >nul
if errorlevel.....
(need to clean up tempfile & tempfile2)
[tested on XP & 6.2]
My reasoning is that the ONLY time that FC produces less than 9 lines out
output is where the files are the same. Even a single character difference
will produce 9 output lines.
Echoing an extra line yields 4 lines for "same" and 10 or more for
"different". Count this with FIND /C /V "" and the filelength produced will
be either 3 characters or at least 4. It's then a simple matter of finding "
3 byte" in the DIR listing for the second tempfile produced.
William Allen
>
> "William Allen" wrote in message
..snip
> > As I say, the mnemonic for the line
> > fc file1.txt file2.txt | find "***">NUL
> > is:
> > ERRORLEVEL=1 files [1]dentical (i/1=mnemonic)
> > ERRORLEVEL=0 files n[0]n-identical (o/0=mnemonic)
> Unfortunately William, the files-are-different detection using "****"
> doesn't work for non-text files.
Noted. Thank you. However, you can force an ASCII comparison with the
/L switch, so the following single command line will work for the six
file types where FC defaults to binary comparison (Windows 95/98/ME):
fc /L file1.exe file2.exe | find "***">NUL
as before gives:
ERRORLEVEL=1 files [1]dentical (i/1=mnemonic)
ERRORLEVEL=0 files n[0]n-identical (o/0=mnemonic)
============Screen capture Windows 95
C:\WORK>command /z /k
Return code (ERRORLEVEL): 0
WARNING: Reloaded COMMAND.COM transient
C:\WORK>copy c:\windows\winver.exe FILE1.EXE
1 file(s) copied
C:\WORK>copy c:\windows\winver.exe FILE2.EXE
1 file(s) copied
C:\WORK>REM Make FILE2.EXE different from FILE1.EXE
C:\WORK>copy /b /y FILE2.EXE+FILE1.EXE FILE2.EXE
FILE2.EXE
FILE1.EXE
1 file(s) copied
C:\WORK>fc /L file1.exe file2.exe | find "***">NUL
Return code (ERRORLEVEL): 0
Return code (ERRORLEVEL): 0 [Errorlevel from FIND]
C:\WORK>fc /L file1.exe file1.exe | find "***">NUL
Return code (ERRORLEVEL): 0
Return code (ERRORLEVEL): 1 [Errorlevel from FIND]
C:\WORK>
============End screen capture
ERRORLEVEL=1 files [1]dentical (i/1=mnemonic)
ERRORLEVEL=0 files n[0]n-identical (o/0=mnemonic)
Note that FC performs an ASCII comparison by default on all files
except .EXE .OBJ .LIB .COM .BIN .SYS where the default is /B (binary).
I am grateful to Tom Lavedas for first drawing my attention some time
ago to the six types of file that FC treats as binary by default.
billious
When comparing .EXE against a .TXT of the same length, I found
FC /L indeed produces "****" on mismatch in DOS6.2
FC /L does not produce "****" on mismatch in NT4 or XP
William Allen
>
> "William Allen" wrote in message
> > Noted. Thank you. However, you can force an ASCII comparison with the
> > /L switch, so the following single command line will work for the six
> > file types where FC defaults to binary comparison (Windows 95/98/ME):
> >
> > fc /L file1.exe file2.exe | find "***">NUL
> > as before gives:
> > ERRORLEVEL=1 files [1]dentical (i/1=mnemonic)
> > ERRORLEVEL=0 files n[0]n-identical (o/0=mnemonic)
> When comparing .EXE against a .TXT of the same length, I found
>
> FC /L indeed produces "****" on mismatch in DOS6.2
>
> FC /L does not produce "****" on mismatch in NT4 or XP
Noted.
Would you try an FC in NT/XP with the /L and /LB1 switches
combined, to try and force a re-synchronization failure on the
mismatch, to see what happens, thus:
============Screen capture Windows 95
C:\WORK>fc /L /LB1 file1.exe file2.exe
Comparing files FILE1.EXE and file2.exe
Resync failed. Files are too different
****** FILE1.EXE
****** file2.exe
******
C:\WORK>
============End screen capture
--
William Allen
J. Yazel
> How to get an ERRORLEVEL from FC file comparison:
>
>A number of Batch questions we've dealt with recently have involved
>obtaining an ERRORLEVEL from the FC command when comparing files. The
> ----- SNIP ----
Try COMPARE.ZIP
J. Yazel
> How to get an ERRORLEVEL from FC file comparison:
>
>A number of Batch questions we've dealt with recently have involved
>obtaining an ERRORLEVEL from the FC command when comparing files. The
>problem is that FC doesn't return a meaningful ERRORLEVEL to allow
>a Batch file to distinguish whether or not the comparison result
==== SNIP =====
Sorry, I forgot the URL. http://www.goodells.net/dan/pclib.htm
It's important because there are multiple files on the net with the
same name (COMPARE.ZIP) but they are not the same.
Jack
Dr John Stockton
2005 00:16:28, seen in news:alt.msdos.batch, billious
<billio...@hotmail.com> posted :
>
>Unfortunately William, the files-are-different detection using "****"
>doesn't work for non-text files.
FC /L *should* force text-type comparison for all files.
The lack of a direct and efficient way of comparing files in pure
Microsoft Batch seems to me to be a foolish defect; to be efficient, one
should first compare the lengths (unless FC /W type comparison is
needed, and remember /T and /C too).
So efficient code should do something like
dir %1 | find "file(s)" > $$$1
dir %2 | find "file(s)" > $$$2
and then compare $$$1 & $$$2 : however, I can see the possibility of a
trap, and avoidance, but insecure, ... .
So I wrote a program, FILECMPR.PAS, with EXE in ZIP, quite small, via
sig line 3. It sets errorlevels by
procedure QUIT(const N : word) ;
const Elevs : array [0..9] of string[27] = (
'0 : Files identical',
'1 : File content differs',
'2 : File 2 unopenable',
'3 : File 1 unopenable',
'4 : File 2 is longer',
'5 : File 1 is longer',
'6 : File 2 not found',
'7 : File 1 not found',
'8 : Too many parameters',
'9') ;
begin Writeln('ErrorLevel ', Elevs[N]) ; HALT(N) end {Quit} ;
(9 is for Help called) and it does the minimum work necessary, starting
with the greatest error number and working down.
Note that the comparison is a binary comparison; I could write another
version for text comparisons, or add the feature, but it would probably
then have a 255-character line length limit; or 254.
Does TSBAT item #9 need a little work?
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; Win98. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
billious
[snip-snip]
>> FC /L indeed produces "****" on mismatch in DOS6.2
>>
>> FC /L does not produce "****" on mismatch in NT4 or XP
>
> Noted.
>
> Would you try an FC in NT/XP with the /L and /LB1 switches
> combined, to try and force a re-synchronization failure on the
> mismatch, to see what happens, thus:
>
> ============Screen capture Windows 95
> C:\WORK>fc /L /LB1 file1.exe file2.exe
> Comparing files FILE1.EXE and file2.exe
> Resync failed. Files are too different
> ****** FILE1.EXE
> ****** file2.exe
>
> ******
>
>
>
> C:\WORK>
> ============End screen capture
>
> --
> William Allen
> Creative Technical Writing - Allen & Company: http://www.allenware.com/
>
>
OK. revision...
To get the above results, I was trying a .EXE against a .TXT that was
exactly the same size.
I revised the test, where the two files, names file.EXE and file.TXT
differed in 1 byte.
on XP,
FC alone responded with 2 lines of output and no "****"
FC /B responded with 2 lines of output and no "****"
FC /L responded with 2 lines of output and no "****"
FC /LB1 responded with 8 lines of output and with "****"
FC /L /LB1 responded with 8 lines of output and with "****"
on DOS6.22
FC alone responded with 3 lines of output and no "****"
FC /B responded with 3 lines of output and no "****"
FC /L responded with 3 lines of output, no "****" and falsely claimed "no
differences encountered"
FC /LB1 responded with 3 lines of output and no "****"
FC /L /LB1 responded with 3 lines of output, no "****" and falsely claimed
"no differences encountered"
Hmmm...this needs thinking about.
William Allen
> "William Allen" wrote in message
...snip
> > combined, to try and force a re-synchronization failure on the
> > mismatch, to see what happens, thus:
> >
> > ============Screen capture Windows 95
> > C:\WORK>fc /L /LB1 file1.exe file2.exe
> > Comparing files FILE1.EXE and file2.exe
> > Resync failed. Files are too different
> > ****** FILE1.EXE
> > ****** file2.exe
> >
> > ******
> >
> >
> >
> > C:\WORK>
> > ============End screen capture
> To get the above results, I was trying a .EXE against a .TXT that was
> exactly the same size.
>
> I revised the test, where the two files, names file.EXE and file.TXT
> differed in 1 byte.
>
> on XP,
> FC alone responded with 2 lines of output and no "****"
> FC /B responded with 2 lines of output and no "****"
> FC /L responded with 2 lines of output and no "****"
> FC /LB1 responded with 8 lines of output and with "****"
> FC /L /LB1 responded with 8 lines of output and with "****"
Thanks for those data. They show that /LB1 does indeed generate
the language independent ***** I was looking for. As far as I am
aware /LB1 does indeed imply /L (which explains the similar
results in your last two tests).
> on DOS6.22
> FC alone responded with 3 lines of output and no "****"
> FC /B responded with 3 lines of output and no "****"
> FC /L responded with 3 lines of output, no "****" and falsely claimed "no
> differences encountered"
> FC /LB1 responded with 3 lines of output and no "****"
> FC /L /LB1 responded with 3 lines of output, no "****" and falsely claimed
> "no differences encountered"
Probably not "falsely" claimed, I expect it was the result of
using ASCII comparisons (/L and /LB1 both generate an
ASCII comparison). It was making comparisons of ASCII text
files that I was considering as part of Batch operations.
For example the following demo (Windows 95/98/ME and probably
MS-DOS 6.22 as well) creates two files both 2048 lines long (all
blank lines), but with PC (carriage return linefeed) conventions in
_FILE1.TXT and UNIX (linefeed only) conventions in _FILE2.TXT, so
that _FILE1.TXT is twice the length of _FILE2.TXT, but FC regards
them as "no differences encountered" unless you force /B comparison.
Lines that don't begin with two spaces have wrapped accidentally
====Begin cut-and-paste (omit this line)
@ECHO OFF
:: Create 2048 line file _FILE1.TXT PC format with Debug script
ECHO. f 100 900 d a>_FILE1.TXT
FOR %%C IN (rcx 800 w q) DO ECHO.%%C >>_FILE1.TXT
TYPE _FILE1.TXT | debug _FILE1.TXT>NUL
:: Create 2048 line file _FILE2.TXT UNIX format with Debug script
ECHO. f 100 500 a>_FILE2.TXT
FOR %%C IN (rcx 400 w q) DO ECHO.%%C >>_FILE2.TXT
TYPE _FILE2.TXT | debug _FILE2.TXT>NUL
ECHO. Two files created as follows:
DIR _FILE?.TXT | find "TXT"
ECHO.
ECHO. Now FC with ASCII comparison (default)
fc _FILE1.TXT _FILE2.TXT
choice /cny /n "Erase the test files "
IF ERRORLEVEL 2 deltree /y _FILE1.TXT _FILE2.TXT
IF ERRORLEVEL 2 ECHO. Files erased
IF ERRORLEVEL 1 IF NOT ERRORLEVEL 2 ECHO. Files are left for you
====End cut-and-paste (omit this line)
For Win95/98/ME study/demo use. Cut-and-paste as plain-text Batch file.
Batch file troubleshooting: http://www.allenware.com/find?UsualSuspects
Screen capture shows operation with above as DEMO.BAT
============Screen capture Windows 95
C:\WORK>demo.bat
Two files created as follows:
_FILE1 TXT 2,048 19/03/05 8:04 _FILE1.TXT
_FILE2 TXT 1,024 19/03/05 8:04 _FILE2.TXT
Now FC with ASCII comparison (default)
Comparing files _FILE1.TXT and _FILE2.TXT
FC: no differences encountered
Erase the test files Y
Deleting _FILE1.TXT...
Deleting _FILE2.TXT...
C:\WORK>
============End screen capture
--
William Allen
Free interactive Batch Course http://www.allenware.com/icsw/icswidx.htm
For example Batch Files see: http://www.allenware.com/find?BatchLibrary
billious
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Missing the obvious....
Rather than forcing ASCII comparison, which from the example I gave above is
version-dependent, simply force binary.
Result:
fc /b file1 file2 |find "FC: no" >nul
since fc /b does NOT regurgitate ASCII strings, there is no way that "FC:
no" can occur in an FC /B output except if it is the report from FC. "FC:"
can occur (if byte 3852 is different, for instance) but "FC: no" cannot.
This works for me in 6.22, 98, NT & XP.
I believe that the ASCII comparison will stop comparing on encountering a
'1Ah' byte.
The CRLF vs LF characteristic is quirky and may have applications - but
that's a side-issue.
William Allen
...snip
> Missing the obvious....
>
> Rather than forcing ASCII comparison, which from the example I gave above is
> version-dependent, simply force binary.
>
> Result:
>
> fc /b file1 file2 |find "FC: no" >nul
>
> since fc /b does NOT regurgitate ASCII strings, there is no way that "FC:
> no" can occur in an FC /B output except if it is the report from FC. "FC:"
> can occur (if byte 3852 is different, for instance) but "FC: no" cannot.
Yes, I'm aware of that, but the original context of this thread was
the interesting _language_independence_ of Laura Fairhead's "***"
FC search target. If you know the local language the user is working
in, then looking for fragments of it is fine (and is what most people
would do, of course).
It's simply that, occasionally, people need ideas that don't
presuppose what language the local user is speaking/using.
Keeping to Laura Fairhead's intention of language independence,
but allowing binary file comparisons to generate an ERRORLEVEL,
it doesn't immediately seem possible to devise a "one-liner"
like the one explained in my earlier post.
A general approach to language independence in Batch files is
to generate the local output of a Batch command, and use that
in further comparisons, so you automatically work in the locale's
language and conventions.
This code fragment does that for FC:
ECHO. Create a file to compare with itself>_CHECK.TMP
fc _CHECK.TMP _CHECK.TMP|find /n /v ""|find "[2]">_SAME.TMP
fc /b File-1.bin File-2.bin |find /n /v ""|find "[2]">_CHECK.TMP
fc _SAME.TMP _CHECK.TMP | find "***">NUL
It gets the second line of FC output for a guaranteed identical
result, storing it in workfile _SAME.TMP, and compares that
with what you get for comparing the two files (in the example,
File-1.bin and File-2.bin - the /B switch is there but not needed
for .BIN files).
In a practical Batch file, where the two files are accepted as
command line arguments, it would start to look something
like this:
Lines that don't begin with two spaces have wrapped accidentally
====Begin cut-and-paste (omit this line)
@ECHO OFF
IF (%2)==() GOTO EOF
IF NOT EXIST %1 GOTO EOF
IF NOT EXIST %2 GOTO EOF
ECHO. Create a file to compare with itself>_CHECK.TMP
fc _CHECK.TMP _CHECK.TMP|find /n /v ""|find "[2]">_SAME.TMP
fc /b %1 %2 |find /n /v ""|find "[2]">_CHECK.TMP
fc _SAME.TMP _CHECK.TMP | find "***">NUL
IF ERRORLEVEL 1 ECHO. Files are the same
IF NOT ERRORLEVEL 1 ECHO. Files differ
FOR %%F IN (_SAME.TMP _CHECK.TMP) DO DEL %%F
:EOF
====End cut-and-paste (omit this line)
For Win95/98/ME study/demo use. Cut-and-paste as plain-text Batch file.
Batch file troubleshooting: http://www.allenware.com/find?UsualSuspects
You run it as follows:
demo.bat firstfile.ext secondfile.ext
and it reports same/different setting an ERRORLEVEL as before:
ERRORLEVEL=1 files [1]dentical (i/1=mnemonic)
ERRORLEVEL=0 files n[0]n-identical (o/0=mnemonic)
====Third-party utilties
Obviously there are numerous third-party utilities that can be used
to compare files, and some people have suggested them. As we say
on our Website: "As far as possible, we avoid third-party utilities. The
main advantage of using the Batch Language is that it runs on any
machine with the relevant operating system. If your Batch files can't
run on a normal installation, you lose this key feature of the Batch
Language." Where we use them, we try to keep to standard ones
such as SED and GAWK.
As far as we are concerned, in teaching the Batch language, the
use of third-party utilities is counter-productive, since their use
works against the student learning how to write Batch files properly.
Furthermore:
(a) you need to install them on every machine you may run
the Batch file on
(b) you need to check them for viruses before installation
(c) there will be copyright issues in using them as part
of a training course or commercial operation
If you just need to get work done, and don't care about any
of the above issues, then I suppose some argument could
be made for a third-party approach.
But, realistically, if you need to do things that you can't
easily do with Batch files, you're better these days learning
to use WSH (Windows Script Host), since the skills are
highly transferable. And WSH can be mixed easily with
Batch operations, since the CSCRIPT.EXE command line
WSH tool is installed by default on all machines that carry
WSH (nearly all of them these days).
And to "billious", if you've read this far <G>, just to be mischevious,
remember Long file names:
Lines that don't begin with two spaces have wrapped accidentally
====Begin cut-and-paste (omit this line)
@ECHO OFF
fc /b file1.bin file2.bin
fc /b file1.bin file2.bin |find "FC: no"
IF NOT ERRORLEVEL 1 ECHO. Found "FC: no"
IF ERRORLEVEL 1 ECHO. Didn't find "FC: no"
ECHO.
ECHO. Now copy file2.bin to file called "no differences encountered"
COPY file2.bin "no differences encountered">NUL
ECHO.
fc /b file1.bin "no differences encountered"
fc /b file1.bin "no differences encountered"|find "FC: no"
IF NOT ERRORLEVEL 1 ECHO. Found "FC: no"
IF ERRORLEVEL 1 ECHO. Didn't find "FC: no"
====End cut-and-paste (omit this line)
For Win95/98/ME study/demo use. Cut-and-paste as plain-text Batch file.
Batch file troubleshooting: http://www.allenware.com/find?UsualSuspects
This shows what can happen:
============Screen capture Windows 95
C:\WORK>sillydemo.bat
Comparing files FILE1.BIN and file2.bin
FC: file2.bin longer than FILE1.BIN
Didn't find "FC: no"
Now copy file2.bin to file called "no differences encountered"
Comparing files FILE1.BIN and no differences encountered
FC: no differences encountered longer than FILE1.BIN
FC: no differences encountered longer than FILE1.BIN
Found "FC: no"
William Allen
...snip
> And to "billious", if you've read this far <G>, just to be mischevious,
> remember Long file names:
And, of course, a similar mischevious Long file name twist
applies to my own language independent code section<G>:
ECHO. Create a file to compare with itself>_CHECK.TMP
fc _CHECK.TMP _CHECK.TMP|find /n /v ""|find "[2]">_SAME.TMP
fc /b %1 %2 |find /n /v ""|find "[2]">_CHECK.TMP
fc _SAME.TMP _CHECK.TMP | find "***">NUL
which would better be coded as:
ECHO. Create a file to compare with itself>_CHECK.TMP
fc _CHECK.TMP _CHECK.TMP|find /n /v ""|find "[2]">_SAME.TMP
fc /b %1 %2 |find /n /v ""|find /v "[1]">_CHECK.TMP
fc _SAME.TMP _CHECK.TMP | find "***">NUL
changing the second occurrence of:
find "[2]"
to:
find /v "[1]"
Why so? Hint: a long file name can itself contain "[2]".
Dr John Stockton
2005 18:19:11, seen in news:alt.msdos.batch, billious
<billio...@hotmail.com> posted :
>
>Rather than forcing ASCII comparison, which from the example I gave above is
>version-dependent, simply force binary.
Please trim your quotes : see sig line 2 below.
AFAICS, binary comparison generates about 17 bytes for each byte of
difference detected.
A method relying only on FC /b is therefore inefficient in
comparing two vast and completely different files. There may not even
be space to store an intermediate of size 17*vast.
>since fc /b does NOT regurgitate ASCII strings, there is no way that "FC:
>no" can occur in an FC /B output except if it is the report from FC. "FC:"
>can occur (if byte 3852 is different, for instance) but "FC: no" cannot.
Consider the case of a file whose name is allegedly
FC: no differences encountered
For those whose FC reports in English, that file, ISTM, will be reported
as matching any other file, even though it should not exist.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME ©
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
billious
"Dr John Stockton" <sp...@merlyn.demon.co.uk> wrote in message
> Consider the case of a file whose name is allegedly
> FC: no differences encountered
> For those whose FC reports in English, that file, ISTM, will be reported
> as matching any other file, even though it should not exist.
>
ISTM that if you have a system which has a filename "FC: no differences
encountered" indeed any filename containing "FC:" then you have a most
extraordinary system.
billious
>
> ECHO. Create a file to compare with itself>_CHECK.TMP
> fc _CHECK.TMP _CHECK.TMP|find /n /v ""|find "[2]">_SAME.TMP
> fc /b %1 %2 |find /n /v ""|find "[2]">_CHECK.TMP
> fc _SAME.TMP _CHECK.TMP | find "***">NUL
>
> which would better be coded as:
>
>
> changing the second occurrence of:
> find "[2]"
> to:
> find /v "[1]"
>
> Why so? Hint: a long file name can itself contain "[2]".
>
> --
> William Allen
> Free interactive Batch Course http://www.allenware.com/icsw/icswidx.htm
> For example Batch Files see: http://www.allenware.com/find?BatchLibrary
> Creative Technical Writing - Allen & Company: http://www.allenware.com/
>
>
and much better coded as
copy %1 _CHECK.TXT>nul
fc /b %1 _CHECK.TXT|find "FC:">_SAME.TXT
fc /b %1 %2 |find "FC:">_CHECK.TXT
fc /lb1 _SAME.TXT _CHECK.TXT | find "***">NUL
(then clean up tempfiles _SAME.TXT and _CHECK.TXT)
which of course is language-independent and immune to the filename "no
differences encountered" (or whatever the message is in the language you are
using)
UNLESS of course you have the extraordinary bad taste to have a filename
"FC: no differences encountered" (Hint: consider that filename very
carefully)
OR, as Dr. Stockton complains, you run out of drivespace running the FC
(Clue: therefore the files are different)
William Allen
>
> "William Allen" wrote in message
> >
> > fc _CHECK.TMP _CHECK.TMP|find /n /v ""|find "[2]">_SAME.TMP
> > fc /b %1 %2 |find /n /v ""|find "[2]">_CHECK.TMP
> > fc _SAME.TMP _CHECK.TMP | find "***">NUL
> >
> > which would better be coded as:
> >
> [snip]
> >
> > changing the second occurrence of:
> > find "[2]"
> > to:
> > find /v "[1]"
> >
> > Why so? Hint: a long file name can itself contain "[2]".
> and much better coded as
>
> copy %1 _CHECK.TXT>nul
> fc /b %1 _CHECK.TXT|find "FC:">_SAME.TXT
> fc /b %1 %2 |find "FC:">_CHECK.TXT
> fc /lb1 _SAME.TXT _CHECK.TXT | find "***">NUL
>
> (then clean up tempfiles _SAME.TXT and _CHECK.TXT)
Remember that in binary comparisons %1 may be very large
and using it to create _CHECK.TXT may lead to delays
that a separately created and simple Check file avoids.
My code was also meant to be (effectively) self documenting
by writing the Check file I did. When we post code we normally
have in mind that students of our Batch Course may read these
message, and will expect us to document Batch code (as indeed
we constantly pester them to do when they take our Course).
...snip
> UNLESS of course you have the extraordinary bad taste to have a filename
> "FC: no differences encountered" (Hint: consider that filename very
> carefully)
John Stockton simply made a mistake in suggesting the filename he did,
since even long filenames don't have : [colon]s in them. I assume he meant
"no differences encountered" as I had already mischeviously suggested<G>.
Klaus Meinhard
> ====Third-party utilties
>
> Obviously there are numerous third-party utilities that can be used
> to compare files, and some people have suggested them. As we say
> on our Website: "As far as possible, we avoid third-party utilities.
> The main advantage of using the Batch Language is that it runs on any
> machine with the relevant operating system. If your Batch files can't
> run on a normal installation, you lose this key feature of the Batch
> Language." Where we use them, we try to keep to standard ones
> such as SED and GAWK.
> As far as we are concerned, in teaching the Batch language, the
> use of third-party utilities is counter-productive, since their use
> works against the student learning how to write Batch files properly.
> Furthermore:
> (a) you need to install them on every machine you may run
> the Batch file on
> (b) you need to check them for viruses before installation
> (c) there will be copyright issues in using them as part
> of a training course or commercial operation
>
> If you just need to get work done, and don't care about any
> of the above issues, then I suppose some argument could
> be made for a third-party approach.
<snip>
Just to add my 2 cents' worth:
A good collection of 3rd party utilities is essential to get any
nontrivial work done at the "plain" DOS command line. You mention
"standard" utils like SED and AWK (which versions?), and I'd like to add
4DOS for simple reasons:
1. It makes the use of most other utilities unnecessary, because mostly
it can do the job alone (in the case of this thread using the internal
@crc function to compare files language-independantly).
2. It can do the job quicker, because using 4DOS you can write DOS
batches quickly in a nearly selfdocumentary way, using DO loops, IFF -
ELSEIFF, SWITCH - CASE constructs as you'd do in any other proper
computer language. You get at computer information quicker in the form
of internal variables. You can handle strings, dates, computations much
faster because the tools are available internally. In other words:
shorter developement time, better documentation, easier maintainenance.
3. Taking your own tools with you while working on machines of one's
client is probably standard (you use sed and awk, probably your editor
etc.) You don't need to check your own (write-protected) tools for
viruses every time you use them. If you are allowed to install your
programs (=batches) on another machine, there's no reason not to install
the tools needed, be it sed, awk or 4dos.
4. 4DOS is freeware, even in a teaching or commercial environment.
--
* Klaus Meinhard *
www.4dos.info
- 4DOS Info -
- Info for DOS -
foxidrive
> Yes, I'm aware of that, but the original context of this thread was
> the interesting _language_independence_ of Laura Fairhead's "***"
> FC search target.
Can someone describe to me why 'find /i "no differences"' is version
dependant?
William Allen
Not "version", Laura Fairhead was aiming at _language_independence,
par example:
============Screen capture en France (simulated...)
C:\Marche>REM Peut-être nous sommes en France ...
C:\Marche>fc nul nul
On a comparé NUL et nul
FC: pas de differences rencontré
C:\Marche>
William Allen
> William,
WA> > As far as we are concerned, in teaching the Batch language, the
WA> > use of third-party utilities is counter-productive, since their use
WA> > works against the student learning how to write Batch files properly.
WA> > Furthermore:
WA> > (a) you need to install them on every machine you may run
WA> > the Batch file on
WA> > (b) you need to check them for viruses before installation
WA> > (c) there will be copyright issues in using them as part
WA> > of a training course or commercial operation
WA> >
WA> > If you just need to get work done, and don't care about any
WA> > of the above issues, then I suppose some argument could
WA> > be made for a third-party approach.
> <snip>
> Just to add my 2 cents' worth:
We use GAWK311 and SED3028 (not necessarily the latest, but these
are simply the versions we've used in our posted and other examples,
and so work as stated). One of the reasons I like SED is that it
handles regular expressions, which is something we are possibly
interested in from a training/tuition point of view.
> , and I'd like to add 4DOS for simple reasons:
...snip
> 4. 4DOS is freeware, even in a teaching or commercial environment.
This last point does change the situation with regard to 4DOS, and
makes it more interesting.
Dr John Stockton
dated Sun, 20 Mar 2005 05:58:58, seen in news:alt.msdos.batch, William
Allen <_w...@email.com> posted :
>
>...snip
>> UNLESS of course you have the extraordinary bad taste to have a filename
>> "FC: no differences encountered" (Hint: consider that filename very
>> carefully)
>
>John Stockton simply made a mistake in suggesting the filename he did,
>since even long filenames don't have : [colon]s in them. I assume he meant
>"no differences encountered" as I had already mischeviously suggested<G>.
That is a very careless criticism. I actually wrote :
Consider the case of a file whose name is allegedly
FC: no differences encountered
For those whose FC reports in English, that file, ISTM, will be
reported as matching any other file, even though it should not exist.
There "FC: no differences encountered" is not a name, but an alleged
name; it could arise from carelessness, or from some earlier error. And
I also wrote "Consider". Careful consideration would extend itself to
looking for any other possible cases where a match might be found in
text other than that which it was appropriate to search - and not only
in the case of file comparison.
--
foxidrive
> "foxidrive" wrote in message
>> On Sat, 19 Mar 2005 10:49:52 -0000, William Allen wrote:
>>
>>> Yes, I'm aware of that, but the original context of this thread was
>>> the interesting _language_independence_ of Laura Fairhead's "***"
>>> FC search target.
>>
>> Can someone describe to me why 'find /i "no differences"' is version
>> dependant?
>
> Not "version", Laura Fairhead was aiming at _language_independence,
> par example:
>
> FC: pas de differences rencontré
Ahh. Mea culpa
Dr John Stockton
dated Mon, 28 Mar 2005 15:45:49, seen in news:alt.msdos.batch, William
Allen <_w...@email.com> posted :
>Dr John Stockton" wrote in message
>> William Allen posted :
>...snip
>> >John Stockton simply made a mistake in suggesting the filename he did,
>> >since even long filenames don't have : [colon]s in them. I assume he meant
>> >"no differences encountered" as I had already mischeviously suggested<G>.
>>
>> That is a very careless criticism. I actually wrote :
>>
>> Consider the case of a file whose name is allegedly
>> FC: no differences encountered
>> For those whose FC reports in English, that file, ISTM, will be
>> reported as matching any other file, even though it should not exist.
>
>No. Rather, it's your reply that's careless, for the following reasons:
I write for those that can understand English, and can think about what
they read. Evidently you do not qualify.
William Allen
> I write for those that can understand English, and can think about what
> they read. Evidently you do not qualify.
You write in a defensive and convoluted style. The result is not only
unclear to NewsGroup readers, but also leads to mistakes such the one
you made in this thread.
I knew what you meant to say, but replies show others didn't. You
had almost grasped the right name that would deceive the string in
the FIND "no differences encountered" pipe from FC, but you weren't
quite there. As it stood, your suggestion didn't work, and confused
the issue (while the correct name had been pointed out earlier).
There's no harm in partly-baked ideas. However, prefixing them with
"alleged" is mere sophistry that neither finishes the cooking, nor
makes an inchoate thought clear, nor a wrong one right. It certainly
didn't help make anything clear in this case - quite the reverse.
Writing clearly is difficult, though when done well it seems easy to
the casual eye. The first step is to realise that "clearly" means
writing so that _readers_ follow your meaning without undue effort.
In contrast, writing badly and leaving the wretched reader to sort
it out makes life easy for a lazy author. However, few will bother
to decipher the turgid result. Writing is communication, or it should
be. Batch syntax is not easy to grasp; bad writing makes it harder.
Sometimes, the Batch file points you make are useful. However, points
made in poor style may be missed or dismissed by NewsGroup readers,
and so waste everyone's time: better to write clearly and be read.
--
William Allen