Findstr problem

[Squashman]

Using a file as my search strings and I am getting two lines of output that should not output.

The two bolded lines should not output. They are not in the WD_List.txt

C:\WD_CONFIG_FILES\Vbfolders>findstr /I /L /G:WD_List.txt VB_Folder.txt
\\SERVER30\E$\EDLCampaignSum\HandshakeIn
\\SERVER30\E$\EDLCampaignSum\HandshakeOut
\\SERVER30\E$\EDLError\HandshakeIn
\\SERVER30\E$\EDLError\HandshakeOut
\\SERVER30\E$\Handshake
\\SERVER30\E$\Handshakeout
\\SERVER30\E$\Manifest\ManHold
\\SERVER30\E$\Manifest\Workin
\\SERVER30\E$\Manifest\Workout
\\SERVER30\E$\ProductID\HandshakeIn
\\SERVER30\E$\ProductID\HandshakeOut
\\server10\ABC-SEC\PDF_Files\Failed_Trigger
\\server10\ABC-SEC\PDF_Files\Success

VB_Folder.txt

Code: Select all

\\SERVER30\E$\DailyInput\DailyMainUp
\\SERVER30\E$\EDLCampaignSum\HandshakeIn
\\SERVER30\E$\EDLCampaignSum\HandshakeOut
\\SERVER30\E$\EDLError\HandshakeIn
\\SERVER30\E$\EDLError\HandshakeOut
\\SERVER30\E$\Handshake
\\SERVER30\E$\Handshakeout
\\SERVER30\E$\Manifest\ManHold
\\SERVER30\E$\Manifest\Workin
\\SERVER30\E$\Manifest\Workout
\\SERVER30\E$\ProductID\HandshakeIn
\\SERVER30\E$\ProductID\HandshakeOut
\\server10\ABC-SEC\PDF_Files\Failed_Trigger
\\server10\ABC-SEC\PDF_Files\Success

WD_List.txt

Code: Select all

\\SERVER30\E$\AP30SweepCopy
\\SERVER30\E$\AP30SweepHist
\\SERVER30\E$\AP30SweepLand
\\SERVER30\E$\AP30SweepMove
\\SERVER30\E$\DailyInput\DailyHist
\\SERVER30\E$\DailyInput\DailyLand
\\SERVER30\E$\DailyInput\DailytoMain
\\SERVER30\E$\DailyInput\DailyUnZip
\\SERVER30\E$\EDLCampaignSum
\\SERVER30\E$\EDLCampaignSum\CampLand
\\SERVER30\E$\EDLCampaignSum\Campland\Work Space
\\SERVER30\E$\EDLCampaignSum\CampLand\Work Space\Failed FTP
\\SERVER30\E$\EDLCampaignSum\HandshakeOut
\\SERVER30\E$\EDLError
\\SERVER30\E$\EDLError\ErrorLand
\\SERVER30\E$\EDLError\ErrorLand\Failed FTP
\\SERVER30\E$\EDLError\HandshakeOut
\\SERVER30\E$\Handshake
\\SERVER30\E$\HandshakeLand
\\SERVER30\E$\Handshakeout
\\SERVER30\E$\Manifest\ManCopy
\\SERVER30\E$\Manifest\ManHold
\\SERVER30\E$\Manifest\ManLand
\\SERVER30\E$\Manifest\Workin
\\SERVER30\E$\Manifest\Workout
\\SERVER30\E$\ProductID\HandshakeIn
\\SERVER30\E$\ProductID\HandshakeOut
\\SERVER30\E$\ProductID\ProductLand
\\SERVER10\ABC-SEC\PDF_Files
\\SERVER10\ABC-SEC\PDF_Files\Failed
\\SERVER10\ABC-SEC\PDF_Files\Failed_Trigger
\\SERVER10\ABC-SEC\PDF_Files\Hold_FTP
\\SERVER10\ABC-SEC\PDF_Files\Success

[jeb]

The two bolded lines should not output. They are not in the WD_List.txt

Hmm, but there are

Code: Select all

\\SERVER30\E$\EDLCampaignSum
\\SERVER30\E$\EDLError

jeb

[Squashman]

The two bolded lines should not output. They are not in the WD_List.txt

Hmm, but there are

Code: Select all

\\SERVER30\E$\EDLCampaignSum
\\SERVER30\E$\EDLError

jeb

Yeah this works better.

C:\WD_CONFIG_FILES\Vbfolders>findstr /E /I /L /G:WD_List.txt VB_Folder.txt
\\SERVER30\E$\EDLCampaignSum\HandshakeOut
\\SERVER30\E$\EDLError\HandshakeOut
\\SERVER30\E$\Handshake
\\SERVER30\E$\Handshakeout
\\SERVER30\E$\Manifest\ManHold
\\SERVER30\E$\Manifest\Workin
\\SERVER30\E$\Manifest\Workout
\\SERVER30\E$\ProductID\HandshakeIn
\\SERVER30\E$\ProductID\HandshakeOut
\\server10\ABC-SEC\PDF_Files\Failed_Trigger
\\server10\ABC-SEC\PDF_Files\Success

[zimxavier]

Merged posts below wrt a different findstr problem

@dbenham
It works thank you again.

-----------------------------------------
You listed limitations and bugs with findstr. I used it many times without issues and today i have one.

Code: Select all

findstr /b /g:strings.txt input.txt > output.txt

My file strings.txt has 14681 lines (characters a-z A-Z 0-9 only). Longest line around 35 characters. My input file has 47705 lines.
It fails to match all lines...

There is any solution with our jrepl for this situation ?


I downloaded and installed GNUWin32 2.5.4 as you recommanded it sometimes. In my batch i replace the line with :

Code: Select all

grep -f strings.txt input.txt > output.txt

And now grep is unknown...

[thefeduke]

Code: Select all

findstr /b /g:strings.txt input.txt > output.txt

Would not 'input.txt' be treated as a string to be searched for unless you coded '<input.txt' ?
John A.

[foxidrive]

Code: Select all

findstr /b /g:strings.txt input.txt > output.txt

Would not 'input.txt' be treated as a string to be searched for unless you coded '<input.txt' ?

/g takes the input strings from the file. Did it error when you tried it?

[zimxavier]

No error. And it fails to match all corresponding lines (sorry, I have expressed myself badly). My output file has 14199 lines but around 500 lines are missing.

I often used it, and it's the first time i have an issue...

[foxidrive]

I replied to John, who was querying the syntax.

No error. And it fails to match all corresponding lines

Examples?

[zimxavier]

in strings.txt:
EVTOPTC_WOL_10420;
in input.txt:
EVTOPTC_WOL_10420;No, there's no need for additional currencies.;Non, nous n'avons pas besoin de devises supplémentaires.;
in output.txt:

Missing. I found the line with notepad++, so it's exactly the same string. And other matched lines are quite similar:

in strings.txt
EVTOPTB_TOG_3110;
in input.txt:
EVTOPTB_TOG_3110;Go to Miklagård and make me proud, son.;Fils, va à Miklagård et fais-moi honneur.;
in output.txt:
EVTOPTB_TOG_3110;Go to Miklagård and make me proud, son.;Fils, va à Miklagård et fais-moi honneur.;

[foxidrive]

Missing. I found the line with notepad++, so it's exactly the same string. And other matched lines are quite similar:

Your example strings work just fine here.

[dbenham]

@zimxavier - I believe you have stumbled on this FINDSTR bug that I documented at Why doesn't this FINDSTR example with multiple literal search strings find a match?. A FINDSTR search with multiple literal search strings can miss matches if the /I switch is not specified.

When using the /G option without the /L or /R option, the first search string determines whether the search will be a literal search or a regex search. If the first search contains at least one regex meta character, and the search is valid, then all strings will be considered to be regular expressions. Otherwise all strings are considered to be literal string searches.

Since all your strings contain nothing but a-z A-Z 0-9, your search will be a literal search, so the bug is in play. Given that your search strings do not contain any regex meta characters, the simplest solution is to add the /R switch to treat the strings as regular expressions. It won't change the meaning of the search, but it will avoid the bug.

This issue really belongs in its own thread - it has nothing to do with JREPL.


Dave Benham

[zimxavier]

@foxidrive
Thank you for your try. I know it works with other conditions. As Dave said, it doesn't work in some cases only. It is a really nasty bug.

@dbenham
Dave, thank you so much. I spent all yesterday searching a solution (i added a \L after reading your posts about findstr limitations but to no avail). Now i added a \R and it works (even if it is very long now). I can't add a \I parameter because it must be case sensitive (but indeed it fixes that bug too and it is fast).

Sorry for wrong section, i didn't think you can resolve that bug without a workaround using jrepl... You are incredible