Analysis Mechanism of findstr Command Line - China DOS Union Forum

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.

Could you be a bit more detailed?

Floor1　willsort	Posted 2006-06-10 22:46
元老会员　Posts 1,512　Credits 4,432
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 ]

Floor2　Climbing	Posted 2006-06-11 01:18
铂金会员　Posts 2,753　Credits 6,962　From 河北保定
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.

Floor3　无奈何	Posted 2006-06-11 03:02
荣誉版主　Posts 356　Credits 1,338
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.

Floor4　3742668	Posted 2006-06-11 14:43
荣誉版主　Posts 718　Credits 2,013
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.

Floor5　willsort	Posted 2006-06-11 18:24
元老会员　Posts 1,512　Credits 4,432
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 ]

Floor6　220110	Posted 2006-06-17 21:07
荣誉版主　Posts 313　Credits 718
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.

Floor7　willsort	Posted 2006-06-18 18:19
元老会员　Posts 1,512　Credits 4,432
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.

Floor8　jackerloo2009	Posted 2009-06-27 00:18
新手上路　Posts 1　Credits 1
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?

Floor9　echoair	Posted 2009-11-11 13:04
新手上路　Posts 33　Credits 8
I hope everyone can systematically summarize the basic usage of findstr...

Floor10　hongcheng668	Posted 2009-11-16 15:43
新手上路　Posts 9　Credits 10
Not bad, learned something.

Floor11　hongcheng668	Posted 2009-11-16 15:43
新手上路　Posts 9　Credits 10
Hehe, impressive.

Floor12　hongcheng668	Posted 2009-11-16 15:43
新手上路　Posts 9　Credits 10
Could you be a bit more detailed?