China DOS Union

To All:

The problem originated from a topic by bsijl about incorrect filtering with findstr . At that time, since the cause couldn't be found, we could only speculate that there were certain issues with the /g switch.

Recently, when writing a debugger code, I used findstr/g again and encountered the same problem . After careful testing , it was found that the problem was caused by the special command-line parsing mechanism of findstr. Briefly described as follows:

1. Unlike the early find, findstr has certain requirements for the arrangement of parameters, that is, it follows the order of switches (can be omitted), strings (omitted when using the /c switch), and file names (can be wildcards, can be multiple, and need to be omitted when there is an input stream).

2. Switches can use quotes, so you can't directly search with keywords the same as switches; file names with spaces must use quotes.

3. The situation and performance of search keywords are relatively complicated, described as follows:
3-1. Whether using the /l or /r switch or using quotes, \ in the keyword will become an escape character, so \\ will become \, and \" will make the quote lose the string delimiting function;
3-2. Search keywords can be with or without quotes. When with quotes, \ in them may be escaped again. The escape results when using /l and /r switches may be different: when using /r, so "\\\\" will become a single \, and "\\" will make the keyword empty; when using /l or neither, "\\\\" and "\\" are equivalent to a single \.
3-3. If the keyword ends with a single \ and has no quotes, it will not be escaped;

And the problem with findstr/g should be related to the above content, but the internal mechanism is still not thoroughly understood. I wonder what everyone's opinions are?

Batch processing to delete XP input method problem! Please DOS experts solve
http://www.cn-dos.net/forum/search.php?searchid=24472

Test of findstr/v/g

E:\Batch\Test>set > envar.out

E:\Batch\Test>findstr /v /g:envar.out envar.out
LOGONSERVER=\\Test
ProgramFiles=C:\Program Files

E:\Batch\Test>findstr /v /i /g:envar.out envar.out
LOGONSERVER=\\Test

Test of findstr

:: Test of findstr

:: Will Sort - 2006-06-10 - CMDWinXP

@echo off

cls&echo ---- "set>_tfs1.tmp & findstr /v /g:_tfs1.tmp _tfs1.tmp"

set>_tfs1.tmp & findstr /v /g:_tfs1.tmp _tfs1.tmp

pause



echo ---- "findstr /v /i /g:_tfs1.tmp _tfs1.tmp"

findstr /v /i /g:_tfs1.tmp _tfs1.tmp

pause



echo ---- "sort /r _tfs1.tmp > _tfs2.tmp & findstr /v /g:_tfs1.tmp _tfs2.tmp"

sort /r _tfs1.tmp > _tfs2.tmp & findstr /v /g:_tfs1.tmp _tfs2.tmp

pause



echo ---- "set|findstr /v /g:_tfs1.tmp"

set|findstr /v /g:_tfs1.tmp

pause



cls&echo ---- "dir C:\ /w > _tfs2.tmp & findstr /v /g:_tfs2.tmp _tfs2.tmp"

dir C:\ /w > _tfs2.tmp & findstr /v /g:_tfs2.tmp _tfs2.tmp

pause



echo ---- "echo :\ > _tfs2.tmp & findstr /v /g:_tfs2.tmp _tfs2.tmp"

echo :\ > _tfs2.tmp & findstr /v /g:_tfs2.tmp _tfs2.tmp

pause



cls&echo ---- "findstr /g:_tfs1.tmp _tfs1.tmp>_tfs2.tmp & fc _tfs1.tmp _tfs2.tmp"

findstr /g:_tfs1.tmp _tfs1.tmp>_tfs2.tmp & fc _tfs1.tmp _tfs2.tmp

pause



cls&echo ---- "set|findstr /r "\\\\  \\\\""

set|findstr /r "\\\\  \\\\"

pause



echo ---- "set|findstr /l "\\\\  \\\\""

set|findstr /l "\\\\  \\\\"

pause



cls&echo ---- "echo _tfs1_tmp > _tfs1.tmp & findstr "/l" "_tfs1.tmp" "_tfs1.tmp""

echo _tfs1_tmp >> _tfs1.tmp & findstr "_tfs1.tmp" "_tfs1.tmp"

pause

del _tfs?.tmp

[ Last edited by willsort on 2006-6-11 at 18:38 ]

How to explain this result on my XP?

d:\work>findstr /v /g:envar.out envar.out
FINDSTR: The search string is too long.

d:\work>findstr /v /g:envar.out envar.out
FINDSTR: The search string is too long.

d:\work>findstr /v /g:envar.out
FINDSTR: The search string is too long.

Under my XP, it is the same as the description of brother willsort 3. I don't know if this annoying result can confirm that it is a bug of FINDSTR. Please friends try the situation of other systems more. It seems that we should be more careful when the keyword contains the "\" character.

Well, it seems that an error occurs only when the character following \ is neither a letter nor a digit. It feels like Microsoft is trying to make findstr a regular expression tool under cmd, but it didn't consider compatibility with other parameters, resulting in the final result being a botched job.

Also, in some cases, when the search string of findstr contains Chinese, the /i parameter needs to be added to avoid errors. The specific environment and code are forgotten. Maybe findstr has bugs in Unicode and ASCII conversion in addition to regular expression issues.

Re Ups:

Another question:

Because the switch also allows quotes, it is impossible to match keywords with the same text strings as the switches such as "/l" or "/r". The following sentence pattern will go wrong:
echo /l /r > test
findstr /l "/r" test

However, you can use the switch /c to force the designation of the keyword:
findstr /l /c:"/r" test
findstr /l /c:/r test

There is another method, which is the \ mentioned above:
findstr /l \/r test

In addition, this \ can also let our keywords contain quotes:
echo /l /r >test
echo "/r" >> test
findstr /l \"/r\" test

Finally, revise and supplement some descriptions in the top floor 3-2:
3-2. The switch /r is the same as the switch /l, and the keywords after it can use or not use quotes; when using quotes:
3-2-1. "\" and "\"\" are equivalent to the quotes and each of the subsequent strings representing multiple keywords;
3-2-2. "\"\"\" and "\"\"\"\" are equivalent to the keyword composed of quotes plus \ and other multiple keywords;
3-2-3. "\"\"\"\" is equivalent to the keyword composed of quotes plus \\ and other multiple keywords;
3-2-4. "\ ", "\\", "\\ ", "\\\ ", "\\\\", "\\\\\ " are equivalent to empty;
3-2-5. "\\ ", "\\\\" are equivalent to one \;
3-2-6. "\\\\ ", "\\\\\\\\" are equivalent to two \;
3-2-7. "\\\\\ " are equivalent to three \;
3-2-8. "\\\\\\\ " are equivalent to four \;

The above data are measured by the following method. The test files are see . When not using the /r switch, it is the same as using the /l switch,;
type test1.txt | findstr /r "test_key" test2.xt


Test text of findstr - "test1.txt"

/l /r
"/l"
" test1
\" test1
\\" test1
\\\" test1
\\\\" test1
\ test1
\\ test1
\\\ test1
\\\\ test1

Test text of findstr - "test2.txt"

" test2
\" test2
\\" test2
\\\" test2
\\\\" test2
\ test2
\\ test2
\\\ test2
\\\\ test2

[ Last edited by willsort on 2006-6-11 at 18:25 ]

3-2. The switches /r and /l are the same. The keywords that follow can use or not use quotes; when using quotes:
3-2-1. "\" and "\"\" are equivalent to the quote and each of the multiple keywords represented by each subsequent string;
3-2-2. "\"\"\" and "\"\"\"\" are equivalent to the keyword composed of quote plus \ and other multiple keywords;
3-2-3. "\"\"\"\"\" is equivalent to the keyword composed of quote plus \ and other multiple keywords;
3-2-4. "\ ", "\\", "\\\ ", "\\\\\ ", "\\\\", "\\\\\ " are equivalent to empty;
3-2-5. "\\ ", "\\\\" are equivalent to one \;
3-2-6. "\\\\ ", "\\\\\\\\" are equivalent to two \;
3-2-7. "\\\\\ " is equivalent to three \;
3-2-8. "\\\\\\\ " is equivalent to four \;

I also discovered this pattern earlier in pathnames, but I didn't study it deeply and didn't dare to post it.
I started from "dir .\" and " dir ..\", you might as well test it.

Re 220110:

The parsing of \ in the UNC pathname is different from the findstr keyword. It only has the function of delimiting directories and has no function of escape characters.

echo 王志慧|findstr /i ".*净"
Still an error with /i

Also, still unclear about the /l parameter

findstr /v /x /i /g:B.txt A.txt
findstr /v /x /i /g:A.txt B.txt

I once compared two texts, both containing email addresses. Without /l, a common point appeared in the result

Both texts have this address p*.tournois@chello.fr

But the result after comparing differences still had this address. But with /l, it was avoided. How to understand using /l to search the string character by character? All become ordinary characters for literal comparison?

I hope everyone can systematically summarize the basic usage of findstr...

Not bad, learned something.

Hehe, impressive.

Could you be a bit more detailed?