new findstr bug

Discussion forum for all Windows batch related topics.

Moderator: DosItHelp

Message
Author
Squashman
Expert
Posts: 4486
Joined: 23 Dec 2011 13:59

Re: new findstr bug

#16 Post by Squashman » 24 Jun 2013 08:14

dbenham wrote:@Squashman - No, penpen is intentionally issuing the SET/P command after the FOR has completed. The code is simply piping 9 normal lines followed by 1 non terminated line consisting of a single character to FINDSTR. It is exactly what Sponge Belly did with sample.txt, except the content is generated dynamically instead of using a static file.

I don't see the point of using the FOR /L. It has no bearing on what is causing the issue. I don't see the point of trying to pipe the ECHO's from the FOR loop to the findstr command. Take the brackets out and it still outputs the same.

Code: Select all

C:\A>(for /l %i in (0,1,9) do @echo:Line_%i.)&set/p"=x "<nul|findstr "^"
Line_0.
Line_1.
Line_2.
Line_3.
Line_4.
Line_5.
Line_6.
Line_7.
Line_8.
Line_9.
x

C:\A>((for /l %i in (0,1,9) do @echo:Line_%i.)&set/p"=x "<nul)|findstr "^"
Line_0.
Line_1.
Line_2.
Line_3.
Line_4.
Line_5.
Line_6.
Line_7.
Line_8.
Line_9.
x

dbenham
Expert
Posts: 2461
Joined: 12 Feb 2011 21:02
Location: United States (east coast)

Re: new findstr bug

#17 Post by dbenham » 24 Jun 2013 08:32

Add the /N option to findstr and you will see that the version with the extra brackets pipes everything to FINDSTR. The version without brackets only pipes the SET/P output.

Code: Select all

>((for /l %i in (0,1,9) do @echo:Line_%i.)&set/p"=x "<nul)|findstr /n "^"
1:Line_0.
2:Line_1.
3:Line_2.
4:Line_3.
5:Line_4.
6:Line_5.
7:Line_6.
8:Line_7.
9:Line_8.
10:Line_9.
11:x

>(for /l %i in (0,1,9) do @echo:Line_%i.)&set/p"=x "<nul|findstr /n "^"
Line_0.
Line_1.
Line_2.
Line_3.
Line_4.
Line_5.
Line_6.
Line_7.
Line_8.
Line_9.
1:x

>


Dave Benham

Squashman
Expert
Posts: 4486
Joined: 23 Dec 2011 13:59

Re: new findstr bug

#18 Post by Squashman » 24 Jun 2013 08:38

dbenham wrote:Add the /N option to findstr and you will see that the version with the extra brackets pipes everything to FINDSTR. The version without brackets only pipes the SET/P output.

Dave I realize that. I just don't see the point of piping the FOR /L output to FINDSTR. I am trying to understand why we are piping the output from the FOR /L loop to FINDSTR. It seems like a bad example to me. It has no affect on what SET /P is doing when it pipes to FINDSTR.

dbenham
Expert
Posts: 2461
Joined: 12 Feb 2011 21:02
Location: United States (east coast)

Re: new findstr bug

#19 Post by dbenham » 24 Jun 2013 09:22

It's not a big deal. It is simply demonstrating that the behavior is not restricted to piping a single line with one character. Just as Sponge Belly did with piping file contents, the example demonstrates that the last line is always ignored if it consists of a single character without line terminator, even if there are preceding lines.

What matters is the content that is piped, not the method by which the content is generated. The FOR loop coupled with SET/P is simply one means of generating multiple lines followed by a line of one character without newline. Note that I am referring to the example without the space after x.

Squashman
Expert
Posts: 4486
Joined: 23 Dec 2011 13:59

Re: new findstr bug

#20 Post by Squashman » 24 Jun 2013 10:09

I understand the code. I just don't understand what point the example is making. Probably never will.

penpen
Expert
Posts: 2009
Joined: 23 Jun 2013 06:15
Location: Germany

Re: new findstr bug

#21 Post by penpen » 24 Jun 2013 16:07

I have thought of sending the following as private message, but if 50% of posters have problems with what i wrote, there may be much more readers with the same problem, so i have decided to post this.

I'm not sure what problem you have with these two examples, so i try a detailed explanation of:
1) why i have used examples at all,
2) what these examples should do, and
3) why the structure of the examples has this form,
and hope that this is, what you want to know.

ad 1)
I have written down as good as i remember how FINDSTR is working on piped input. To show, that FINDSTR produces the predicted output on the two error states, i have given 2 examples.

ad 2)
The first example should produce the output when the first reason must be assumed by FINDSTR (the delivering process/thread may have crashed for what reason ever).
The second is choosen analogously.

ad 3)
FINDSTR is getting input via pipe from another process and is doing a valid search.
Because i don't like creating files i have choosen to create it in memory only.

FINDSTR operates on lines and the error handling is independent of a specific line. Therefore i need to create a valid text with an arbitrary constant number of lines, so i decided to use ECHO inside a FOR/L loop, as the ECHO command sets a string and ends the line with a carriage return (\r) followed by a newline (\n). Anybody may change the number of lines of this valid text by changing the start, step or end values.

Then i needed the invalid line without the \r\n, so i used the SET\R command.
The first example has one char, the second has the minimum number higher than one char.

This is all i've needed, so the resulting examples have this structure:

Code: Select all

((for /l %i in (0,1,9) do @echo:Line_%i.)&set/p"=x"<nul)|findstr "^"
((for /l %i in (0,1,9) do @echo:Line_%i.)&set/p"=x "<nul)|findstr "^"


penpen

Post Reply