FINDSTR: Line is too long

Question

Windows FINDSTR command is useful for sifting through large amounts of data; it filters out lines of text that match or don't match a specified pattern or string (like GNU/BSD grep).

But it refuses to output lines longer than a certain length. Is there a (native) alternative, fix, or workaround?

Solution 1

SS64's FINDSTR - Escapes and Length limits says:

Line Length limits

Files specified as a command line argument or via the /F:FILE option have no known line length limit. Searches were successfully run against a 128MB file that did not contain a single <LF>.

Piped data and Redirected input is limited to 8191 bytes per line. This limit is a "feature" of FINDSTR. It is not inherent to pipes or redirection. FINDSTR using redirected stdin or piped input will never match any line that is >=8k bytes. Lines >= 8k generate an error message to stderr, but ERRORLEVEL is still 0 if the search string is found in at least one line of at least one file.

Credits:
Dave Benham - List of undocumented features and limitations of FINDSTR from StackOverflow

Solution 2

The better built-in alternative would be PowerShell's Select-String (or its alias sls)

The Select-String cmdlet searches for text and text patterns in input strings and files. You can use Select-String similar to grep in UNIX or findstr.exe in Windows.

Select-String

Just be aware that Select-String does a case-insensitive search by default, unlike most alternatives

Comments

[Harry]

interact-sw.co.uk/iangblog/2006/06/03/pshfindstr

[Sz.]

I'm just here to express my sympathy, in your (well, our shared) grief.

[endo64]

Baregrep is an old but still useful tool: baremetalsoft.com/baregrep/index.php

[Sz.]

Then again, just to ensure no powerful, usable tools accidentally leak out from the "CLI utils" dungeon of Microsoft (see the hilariously scripting-unfriendly basic commands like MD, RD, DEL, COPY (or, god forbid: XCOPY), not to mention their evil daddy CMD), FINDSTR will, in this case (of not failing on normal text input), will prefix every line of the output with the current filename being processed from the list, no matter what. So, FINDSTR cannot be used as a proper filter, not even in this "partially uncripple" mode with /F. (And I'm not even an anti-MS zealot.)

[HappyDog]

This explains the problem well, but doesn't actually answer the question; "Is there a (native) alternative, fix, or workaround?"

[Gerold Broser]

@HappyDog Yes, there is a fix or workaround: Don't pipe or redirect lines > 8191 chars long. Mingw-w64 is an alternative. Another one is right herein.

[HappyDog]

Well, the workaround for "How do I do X" is never "Don't do X", so I'm not really sure I agree with that. And you're right, there are answers given on this page. However, as it stands, this doesn't answer the question that was posed (even though it is very useful background information).

[Gerold Broser]

@HappyDog Relax, this was kinda joke. Times are hard enough otherwise, fighting Corona worldwide. You can downvote my answer any time if you think you must.