| Author |
Message |
|
dbenham
Expert
Joined: 12 Feb 2011 21:02
Posts: 889
Location: United States (east coast)
|
 Undocumented FINDSTR features and limitations For those that are interested, I've posted an exhaustive list of undocumented FINDSTR features and limitations at StackOverflow. A few of the more interesting tid-bits - Line length limits for piped or redirected input
- Escape rules for " and \ within search strings
- Which characters do not work properly within search strings
- How exactly does FINDSTR determine what is a line
- How to search across line breaks with one search string
- Precise explanation of regex terms ^ $ \< \> and [x-y]
Dave Benham
|
| 13 Jan 2012 09:55 |
|
|
|
Squashman
Joined: 23 Dec 2011 13:59
Posts: 1003
|
Re: Undocumented FINDSTR features and limitations dbenham wrote: - How to search across line breaks with one search string
That might actually come in handy right away for me.
|
| 13 Jan 2012 10:35 |
|
|
|
aGerman
Expert
Joined: 22 Jan 2010 18:01
Posts: 1395
Location: Germany
|
Re: Undocumented FINDSTR features and limitations Thanks Dave. I wasn't aware of some of these issues. BTW I appreciate FINDSTR for supporting regular expressions, but I hate it for not returning the matched sub string but the entire line instead  Regards aGerman
|
| 13 Jan 2012 16:25 |
|
|
|
dbenham
Expert
Joined: 12 Feb 2011 21:02
Posts: 889
Location: United States (east coast)
|
Re: Undocumented FINDSTR features and limitations FINDSTR BUG ALERT  FINDSTR may give the wrong answer if multiple literal search strings are specified unless the /I option is used. See Why doesn't this FINDSTR example with multiple literal search strings find a match? for more info. Also, the default type of search (Literal vs Regex) is more complicated than I thought. I've updated my link in the first post of this thread. Dave Benham
|
| 19 Jan 2012 07:09 |
|
|
|
Judago
Joined: 04 Nov 2011 07:59
Posts: 11
|
Re: Undocumented FINDSTR features and limitations There is a pretty serious bug that is present on xp(haven't tested others). Using more than 15 classes doesn't just result in a text(in console) error message, but the typical windows error popup. Code: echo 01234567890123456|findstr [0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]
|
| 20 Jan 2012 05:16 |
|
|
|
dbenham
Expert
Joined: 12 Feb 2011 21:02
Posts: 889
Location: United States (east coast)
|
Re: Undocumented FINDSTR features and limitations  Wow - nice tip about a horrible "feature" Confirmed in Vista Dave Benham
|
| 20 Jan 2012 07:14 |
|
|
|
jeb
Expert
Joined: 30 Aug 2007 08:05
Posts: 567
Location: Germany
|
Re: Undocumented FINDSTR features and limitations Confirmed in Win7 64Bit
That's the problem of Microsoft, some components are written by drug consuming apprentices.
jeb
|
| 20 Jan 2012 09:58 |
|
|
|
Squashman
Joined: 23 Dec 2011 13:59
Posts: 1003
|
Re: Undocumented FINDSTR features and limitations So can the search be extended across multiple lines? I am basically looking at the lines that start with EA and 4 lines down will be the line GC. Code: **
YP 2001
RC U
EA 9780702026171
RF R
WE 1780
SG 1
GC O00
I3 1313101313134
PC S6.1T
**
YP 2003
RC J
EA 9780237526306
RF R
WE 220
SG 4
GC C09
I3 1111232349544
PC Y2.1
**
YP 2005
RC G
EA 9781857152814
RF R
WE 562
SG 3
GC O00
I3 1483859583943
PC S6.3Y
** So I want to pull out the EA line when the GC line Equals GC O00 So I gave this a try. Code: @echo off
setlocal
::Define LF variable containing a linefeed (0x0A)
set LF=^
::Above 2 blank lines are critical - do not remove
::Define CR variable containing a carriage return (0x0D)
for /f %%a in ('copy /Z "%~dpf0" nul') do set "CR=%%a"
setlocal enableDelayedExpansion
::regex "!CR!*!LF!" will match both Unix and Windows style End-Of-Line
findstr /r /c:"EA *!CR!*!LF!*!CR!*!LF!*!CR!*!LF!*!CR!*!LF!GC O00" test.txt no go on this as well. Code: findstr /r /c:"EA .!CR!!LF!.!CR!!LF!.!CR!!LF!.!CR!!LF!GC O00" test.txt
|
| 21 Jan 2012 16:31 |
|
|
|
aGerman
Expert
Joined: 22 Jan 2010 18:01
Posts: 1395
Location: Germany
|
Re: Undocumented FINDSTR features and limitations Try Code: findstr /r /c:"EA ..*!CR!*!LF!..*!CR!*!LF!..*!CR!*!LF!..*!CR!*!LF!GC O00" test.txt . matches exactly 1 character .* matches zero or more characters ..* matches min. 1 or more characters My output for your test.txt is Code: EA 9780702026171
EA 9781857152814 Regards aGerman
|
| 21 Jan 2012 17:34 |
|
|
|
Squashman
Joined: 23 Dec 2011 13:59
Posts: 1003
|
Re: Undocumented FINDSTR features and limitations Thanks aGerman!
|
| 21 Jan 2012 21:57 |
|
|
|
Squashman
Joined: 23 Dec 2011 13:59
Posts: 1003
|
Re: Undocumented FINDSTR features and limitations Couple of other questions. 1) Can't seem to put this into a FOR LOOP. I get the error FINDSTR: Bad command lineCode: FOR /F "tokens=2 delims= " %%A in ('findstr /r /c:"EA ..*!CR!*!LF!..*!CR!*!LF!..*!CR!*!LF!..*!CR!*!LF!GC O00" test.txt') do echo %%A 2)Dave said in his article that using the /G option is imprecise. Well I actually need to search for several GC variables in the file. GC O00 GC K02 GC Q00 GC F05 GC C00 Could I make each of the search strings a variable so that I can shorten up the actual findstr command in the for loop. Do I have to escape the exclamations in the CR and LF variables so that they don't expand when setting them to a variable? Code: :: Is this correct?
SET "S1=EA ..*^!CR^!*^!LF^!..*^!CR^!*^!LF^!..*^!CR^!*^!LF^!..*^!CR^!*^!LF^!GC O00"
:: Or is this OK?
SET "S2=EA ..*!CR!*!LF!..*!CR!*!LF!..*!CR!*!LF!..*!CR!*!LF!GC K02"
SET "S3=EA ..*!CR!*!LF!..*!CR!*!LF!..*!CR!*!LF!..*!CR!*!LF!GC Q00"
SET "S4=EA ..*!CR!*!LF!..*!CR!*!LF!..*!CR!*!LF!..*!CR!*!LF!GC F05"
SET "S5=EA ..*!CR!*!LF!..*!CR!*!LF!..*!CR!*!LF!..*!CR!*!LF!GC C00"
FOR /F "tokens=2 delims= " %%A in ('findstr /r /c:"%S1%" /c:"%S2%" /c:"%S3%" /c:"%S4%" /c:"%S5%" test.txt') do echo %%A
|
| 22 Jan 2012 13:34 |
|
|
|
dbenham
Expert
Joined: 12 Feb 2011 21:02
Posts: 889
Location: United States (east coast)
|
Re: Undocumented FINDSTR features and limitations The IN() clause is run in it's own CMD session. The CR and LF must be expanded within that session. Each ! must be escaped so that the variables are not expanded in the parent batch session. But the IN() clause CMD session does not inherit the Delayed Expansion state, so you need to use CMD /V:ON. I think this will work (untested). Edit - fixed bug - %A became %%A as per aGerman's post belowCode: set "prefix=EA ..*!CR!*!LF!..*!CR!*!LF!..*!CR!*!LF!..*!CR!*!LF!GC "
set "search="
for %%A in (O00 K02 Q00 F05 C00) do set "search=!search! /c:"!prefix!%%A"
FOR /F "tokens=2 delims= " %%A in ('cmd /v:on /c "findstr /r ^!search^! test.txt"') do echo %%A
Dave Benham
Last edited by dbenham on 27 Apr 2012 15:42, edited 1 time in total.
|
| 22 Jan 2012 14:17 |
|
|
|
Squashman
Joined: 23 Dec 2011 13:59
Posts: 1003
|
Re: Undocumented FINDSTR features and limitations It's like winning the lottery every time I post a question here.
Thanks again Dave.
|
| 22 Jan 2012 14:29 |
|
|
|
aGerman
Expert
Joined: 22 Jan 2010 18:01
Posts: 1395
Location: Germany
|
Re: Undocumented FINDSTR features and limitations I had to correct this line to get it to run:
for %%A in (O00 K02 Q00 F05 C00) do set "search=!search! /c:"!prefix!%%A""
Regards
aGerman
|
| 22 Jan 2012 15:01 |
|
|
|
Squashman
Joined: 23 Dec 2011 13:59
Posts: 1003
|
Re: Undocumented FINDSTR features and limitations aGerman wrote: I had to correct this line to get it to run:
for %%A in (O00 K02 Q00 F05 C00) do set "search=!search! /c:"!prefix!%%A""
Regards
aGerman Yeah, I saw that as well when I initially ran the code. Didn't want to discredit Dave for a minor syntax error.
Last edited by Squashman on 22 Jan 2012 15:43, edited 1 time in total.
|
| 22 Jan 2012 15:08 |
|
|
