China DOS Union

Originally posted by namejm at 2006-9-1 22:09:


　　You still missed a very important file: fc_name.txt. If you miss this file, it will be a big problem - if you query different files several times and then directly choose to delete, uh...

I don't understand. I created this folder just to know later which files I have searched, copied, and deleted. It has nothing to do with deletion.

Because in your code, the for statement parses the text line by line. So, if you use the code in to filter records in the specified directory, how many lines are there in your %dati%_9.txt, the find %dati%_6.txt /v /i "%%a">>%dati%_5.txt statement will be executed that many times. You should change to another filtering solution to fundamentally solve the problem.

Just now during the testing process, it was found that in the option of not searching certain specific paths under the advanced search, you can only select y, but not n. Selecting n prompts that it is an invalid operation. This is because you did not make a jump when selecting n; after the selection is completed, a lot of temporary files have been generated before pressing any key to execute the next step. This belongs to the operation being too early, and it should start generating only after pressing any key; and after the search is completed, the path name in the success prompt is wrong;

Today I will temporarily test here. I will test comprehensively another day - the code is getting more and more, and it looks a bit difficult, especially when encountering unclear expressions. Please pay attention to modifying the prompt language to make it both concise and accurate, and not let others have misunderstandings.

for /f "tokens=* delims= " %%a in (%dati%_9.txt) do (find %dati%_6.txt /v /i "%%a">>%dati%_5.txt)

Originally posted by namejm at 2006-9-3 13:21:
Because in your code, the for statement parses the text line by line, so if you use the code in to filter the records of the specified directory, then how many lines are there in your %dati%_9.txt, find %dati%_6.txt /v ...

I'm also thinking of other methods to solve this, but I haven't thought of it yet

Originally posted by he200377 at 2006-9-4 08:05:

I'm also thinking of other ways to solve this, but I haven't come up with one yet

　　In fact, after changing the filtering scheme, a few lines of concise code can solve the problem.

Originally posted by namejm at 2006-9-8 00:55:

In fact, after changing the filtering scheme, a few lines of concise code can solve the problem.

Hehe, no matter how I change it, I find that the search speed during testing is not faster than the one built into Windows. I really don't know how Windows implements the search.

That's because you used several for statements to read the content of the text. You know, the for statement parses the text as a whole. A large number of for operations will of course lead to low efficiency. Changing to a filtering solution can greatly improve the search efficiency.

Originally posted by namejm at 2006-9-8 04:52:
????????????????????????????????????for?????????????????????????????????????????????for???????????????????????????????????????????????????for?????????????????????????????????????????????????????????...

What about the win... What specific problem are you having?

Learning

I was too busy yesterday and didn't realize there were so many good posts.