China DOS Union

I tested it like this. The file read is jieguo.txt
find /v "OK" A:\jieguo.txt
if errorlevel 1 goto end
echo 222

:end
echo 333
No matter whether the value is 0 or 1, the result is to display 222 333. If the value is 2 or above, it is to display 333

If that's the case, it means the exit code is >=2, and find didn't complete the search, with an error occurring during the search. What's wrong with your A:\jieguo.txt? It doesn't have to be tested with A:.

But, find has been completed normally, and the result is correct. How to check the return value of the previous command?

Under the command, you can't directly see the exit code, only judge according to errorlever, unless using 4DOS. The result is correct? What correct? According to your statement and result, it's just not correct. "No matter taking value 0 or 1, the result is to display 222 333, taking value above 2, it's to display 333", this explains that the exit code is >=2. find ending the search doesn't necessarily mean it's completed normally. Actually you don't have to test with the original file, just create a file on the hard disk, the content is only one OK, then delete this OK or change it to other content, isn't it okay?

But as long as there is one different place, even in the last line of the file, it can be echoed on the screen. The jieguo.txt posted in the forum is only a part of it. Actually, this file has about 2000 lines. Does this have something to do with it?

I don't know the upper limits of the file size and line count for find searches. I guess thousands of lines shouldn't be a problem; it's not unusual for a program to handle tens of thousands of lines. I specifically created a file with 2048 lines, each containing "ok", and the 2049th line is not "ok". The test went without a hitch, and the results and exit codes were exactly as expected. Why don't you try it on a hard drive?

Then I'll try again to see if there's something wrong on my end

MS-DOS 7.1 can use command /z to view the errorlevel. You can also write a simple batch script to detect the errorlevel.

I tried it again later. It seems that the exit code of find is not what we thought. I'll analyze it later.

Waiting for your news, I've been waiting for good news.

STRINGS [Target variable=]LEFT Source string Number of characters to take 〈Take the specified number of characters from the left of the source string〉

First, let's talk about the exit code explanation of FIND.

FIND exit codes

The following list shows each exit code and a brief description of its meaning:

0
The search was completed successfully and at least one match was found.

1
The search was completed successfully, but no matches were found.

2
The search was not completed successfully. In this case, an error
occurred during the search, and FIND cannot report whether any matches
were found.

Create a file txt with only one line "ok" content, and execute it with different parameters of FIND to view the results and exit codes:

D1.

find "ok" txt

---------- TXT
ok

exitcode = 0

//Found the character to be found, returned exit code 0, normal

D2.

find/v "ok" txt

---------- TXT

exitcode = 0

//According to reason, there should be no character to be found, why is the returned exit code 0? Does a non-existent line also count as found? But, similarly, it is also "found", but the fourth example below returns 1

D3.

find "w" txt

---------- TXT

exitcode = 1

//No character to be found, returned exit code 1, normal

D4.

find/v "w" txt

---------- TXT
ok

exitcode = 1

//Found the line that does not contain the character w, that is, found the character to be found. According to reason, the exit code here should be 0, why does it return 1?

Now, modify the content of the txt file, add a line "not" content, and then execute it according to the above parameters:

D5.

find "ok" txt

---------- TXT
ok

exitcode = 0

//

D6.

find/v "ok" txt

---------- TXT
not

exitcode = 0

//

D7.

find "w" txt

---------- TXT

exitcode = 1

//

D8.

find/v "w" txt

---------- TXT
ok
not

exitcode = 1

//

I won't explain the specific details. The order of exit codes is also 0 0 1 1. I got the same results under MS-DOS 6.22 and MS-7.10 for FIND.

Later I tested FIND under Windows XP, and the tested file content and parameter order are the same as above.

For the txt file with only content "ok":

X1.

find "ok" txt

---------- TXT
ok

exitcode = 0

//Found the character to be found, exit code is 0, normal

X2.

find/v "ok" txt

---------- TXT

exitcode = 1

//No character to be found, exit code is 1, normal

X3.

find "w" txt

---------- TXT

exitcode = 1

//No character to be found, exit code is 1, normal

X4.

find/v "w" txt

---------- TXT
ok

exitcode = 0

//Found the line that does not contain w, that is, found the content to be searched, exit code is 0, normal

Now, add a line "not" to the content of the txt file:

X5.

find "ok" txt

---------- TXT
ok

exitcode = 0

//Found the character to be found, exit code is 0, normal

X6.

find/v "ok" txt

---------- TXT
not

exitcode = 0

//Found the line that does not contain ok, also found the content to be searched, exit code is 0, normal

X7.

find "w" txt

---------- TXT

exitcode = 1

//No character to be found, exit code is 1, normal

X8.

find/v "w" txt

---------- TXT
ok
not

exitcode = 0

//Found the line that does not contain w, also found the content to be searched, exit code is 0, normal


It can be seen that under DOS, specifically under MS-DOS (I haven't tested other DOS yet), the exit code of the FIND command has a defect. The defect is that the exit code after adding the /v parameter is not returned according to the original intention, that is, the examples D2 and D4 above. In Windows XP (my version is SP2), the FIND has corrected this bug. Other versions of Windows have not been tested.

Finally, it is noted: In order to facilitate viewing the exit code and redirecting the result to a file, my test environment under DOS is 4DOS, and the command line environment under Windows is 4NT. I think this should not affect the test results.

However, from your test results, this defect should not be related to your return exit code being >= 2.

Combined with your specific application, if your verification result file is all OK and there is one not OK, using the "find /v "OK"" command, the returned exit code is both 0, which cannot be judged. Just like the examples of D2 and D6 I mentioned earlier.

I don't know which MD5 you are using. Judging from your parameter format, the one using this format should be md5sum.exe, which is a different program from md5.exe. Both of these programs also provide exit codes. Generally, if the generation process and verification result are correct, the returned code is all 0, and if there is an error, it is always >= 1.

Let me supplement the example of D6. It seems to be correct. find indeed found the line "not" that does not contain the "ok" character and returns 0. But I think actually the reason why D1 and D5 return 0 is the same. find thinks it found "ok", not because it found the line that does not contain "ok".

Thank you so much, I need to take a good look. Thank you for your patient testing, I really don't know what to say to express my gratitude. For your patience, I also need to take a good look and try more.