findstr output is garbled when the preceding files has no newline for the last line

[cliff]

hello,

findstr output has a problem when the search word happens to be on a last
line of the preceding file. The output will be garbled with the succeeding
file searched.
e.g here shows a sample command line session showing the problem with
file1.txt and file2.txt :

c:\ > type file1.txt
test
findstr
c:\ > type file2.txt
test
findstr
c:\ > findstr "findstr" file1.txt file2.txt
file1.txt:findstrfile2.txt:findstr


The desired output is :
file1.txt:findstr
file2.txt:findstr


The last line should not have a newline for file1.txt. Try using notepad and
make sure the last line does not have a newline. I also noticed that "edit"
also seems to insert a newline for the last line(but not notepad).

I also tested grep(a sort of findstr equivalent) and it does not have a this
problem when given the same file1.txt and file2.txt.

Will this problem be fixed? It could cause some subtle problems in scripts
when pipes are used.
This problem exists on Windows 2000 and Windows XP.

regards,
Cliff

 

[Dean Wells [MVP]]

I can confirm the behavior and would too consider it a bug. The
following syntax (when executed from within a script) will create
similar output to the native findstr command if that's what you really
need -

for %%l in (f1 f2) do @set /p =%%l:<nul&findstr "findstr" %%l&echo/

.... it is, however, less efficient on large numbers of files that
findstr alone. If this is not precisely what you're after, please post
back with an expanded definition of your goal.

Note, the FIND.EXE command does not exhibit this behavior but uses a
different output format.

 

[cliff]

hello,

My goal is to hope the problem will be fixed in the next release of findstr
so that it will be a better cmd environment.

regards,
Cliff

I can confirm the behavior and would too consider it a bug. The following
syntax (when executed from within a script) will create similar output to
the native findstr command if that's what you really need -

for %%l in (f1 f2) do @set /p =%%l:<nul&findstr "findstr" %%l&echo/

... it is, however, less efficient on large numbers of files that findstr
alone. If this is not precisely what you're after, please post back with
an expanded definition of your goal.

Note, the FIND.EXE command does not exhibit this behavior but uses a
different output format.

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l

hello,

findstr output has a problem when the search word happens to be on a
last line of the preceding file. The output will be garbled with the
succeeding file searched.
e.g here shows a sample command line session showing the problem with
file1.txt and file2.txt :

c:\ > type file1.txt
test
findstr
c:\ > type file2.txt
test
findstr
c:\ > findstr "findstr" file1.txt file2.txt
file1.txt:findstrfile2.txt:findstr


The desired output is :
file1.txt:findstr
file2.txt:findstr


The last line should not have a newline for file1.txt. Try using
notepad and make sure the last line does not have a newline. I also
noticed that "edit" also seems to insert a newline for the last
line(but not notepad).
I also tested grep(a sort of findstr equivalent) and it does not have
a this problem when given the same file1.txt and file2.txt.

Will this problem be fixed? It could cause some subtle problems in
scripts when pipes are used.
This problem exists on Windows 2000 and Windows XP.

regards,
Cliff

 

[Dean Wells [MVP]]

Microsoft may or may not fix that particular behavior, they are,
however, developing an entirely new command shell codenamed Monad
(AFAIK, its release date isn't yet certain).

I don't understand your response, surely you had a goal when using
FINDSTR in the manner you posted outside of finding fault with
Microsoft's CLI utilities? My comment was intended to try and find out
what that goal was to see if a workaround or an alternative approach
would be a better fit.

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l

hello,

My goal is to hope the problem will be fixed in the next release of
findstr so that it will be a better cmd environment.

regards,
Cliff

I can confirm the behavior and would too consider it a bug. The
following syntax (when executed from within a script) will create
similar output to the native findstr command if that's what you
really need - for %%l in (f1 f2) do @set /p =%%l:<nul&findstr
"findstr" %%l&echo/

... it is, however, less efficient on large numbers of files that
findstr alone. If this is not precisely what you're after, please
post back with an expanded definition of your goal.

Note, the FIND.EXE command does not exhibit this behavior but uses a
different output format.

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l

hello,

findstr output has a problem when the search word happens to be on a
last line of the preceding file. The output will be garbled with the
succeeding file searched.
e.g here shows a sample command line session showing the problem
with file1.txt and file2.txt :

c:\ > type file1.txt
test
findstr
c:\ > type file2.txt
test
findstr
c:\ > findstr "findstr" file1.txt file2.txt
file1.txt:findstrfile2.txt:findstr


The desired output is :
file1.txt:findstr
file2.txt:findstr


The last line should not have a newline for file1.txt. Try using
notepad and make sure the last line does not have a newline. I also
noticed that "edit" also seems to insert a newline for the last
line(but not notepad).
I also tested grep(a sort of findstr equivalent) and it does not
have a this problem when given the same file1.txt and file2.txt.

Will this problem be fixed? It could cause some subtle problems in
scripts when pipes are used.
This problem exists on Windows 2000 and Windows XP.

regards,
Cliff

 

[cliff]

hello,

Yes, I was actually using findstr to search some .js files for a function
and stumbled onto this problem. I was surprised to see the garbled output
and later determined that it was because I had placed the function call on
the last lines of some .js files. Actually I also wanted to pipe the output
from findstr to another findstr but saw I could not do that due to the fact
the output from the first findstr was garbled and it would have produced
incorrect results. Hence I thought Microsoft had better do something with
this and hence this posting.

I do not need any immediate solutions as I could easy use other solutons but
I just wanted the cmd environment to be more robust and friendly without
having to install more outside software and also the possible problems
others may also face unknowingly.

Thanks for the response. I hope Microsoft will do something for the sake of
correctness.
regards,
Cliff

Microsoft may or may not fix that particular behavior, they are, however,
developing an entirely new command shell codenamed Monad (AFAIK, its
release date isn't yet certain).

I don't understand your response, surely you had a goal when using FINDSTR
in the manner you posted outside of finding fault with Microsoft's CLI
utilities? My comment was intended to try and find out what that goal was
to see if a workaround or an alternative approach would be a better fit.

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l

hello,

My goal is to hope the problem will be fixed in the next release of
findstr so that it will be a better cmd environment.

regards,
Cliff

I can confirm the behavior and would too consider it a bug. The
following syntax (when executed from within a script) will create
similar output to the native findstr command if that's what you
really need - for %%l in (f1 f2) do @set /p =%%l:<nul&findstr "findstr"
%%l&echo/

... it is, however, less efficient on large numbers of files that
findstr alone. If this is not precisely what you're after, please
post back with an expanded definition of your goal.

Note, the FIND.EXE command does not exhibit this behavior but uses a
different output format.

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l

cliff wrote:
hello,

findstr output has a problem when the search word happens to be on a
last line of the preceding file. The output will be garbled with the
succeeding file searched.
e.g here shows a sample command line session showing the problem
with file1.txt and file2.txt :

c:\ > type file1.txt
test
findstr
c:\ > type file2.txt
test
findstr
c:\ > findstr "findstr" file1.txt file2.txt
file1.txt:findstrfile2.txt:findstr


The desired output is :
file1.txt:findstr
file2.txt:findstr


The last line should not have a newline for file1.txt. Try using
notepad and make sure the last line does not have a newline. I also
noticed that "edit" also seems to insert a newline for the last
line(but not notepad).
I also tested grep(a sort of findstr equivalent) and it does not
have a this problem when given the same file1.txt and file2.txt.

Will this problem be fixed? It could cause some subtle problems in
scripts when pipes are used.
This problem exists on Windows 2000 and Windows XP.

regards,
Cliff

 

[Al Dunbar]

hello,

Yes, I was actually using findstr to search some .js files for a function
and stumbled onto this problem. I was surprised to see the garbled output
and later determined that it was because I had placed the function call on
the last lines of some .js files. Actually I also wanted to pipe the
output from findstr to another findstr but saw I could not do that due to
the fact the output from the first findstr was garbled and it would have
produced incorrect results. Hence I thought Microsoft had better do
something with this and hence this posting.

I do not need any immediate solutions as I could easy use other solutons
but I just wanted the cmd environment to be more robust and friendly
without having to install more outside software and also the possible
problems others may also face unknowingly.

Thanks for the response. I hope Microsoft will do something for the sake
of correctness.

IMHO, there are a number of annoying little behaviours that we have found
workarounds for over the years, my favourite being the failure of [dim
arrayname(10)] and [const constname="constvalue"] in VBScript classes to
either work or throw a compile-time error.

You must realize, hoever, that, for the most part, the number of Microsoft
customers actually affected by these little aberations is quite small. And
further, people working with those technologies are typically those most
able to find workarounds.

Microsoft will probably not fix a problem mentioned in passing in their
public newsgroups -- unless they see a compelling reason to do so. They
certainly have not for some of the other annoyances that have seen even more
complaints in newsgroups.

/Al

regards,
Cliff

Microsoft may or may not fix that particular behavior, they are, however,
developing an entirely new command shell codenamed Monad (AFAIK, its
release date isn't yet certain).

I don't understand your response, surely you had a goal when using
FINDSTR in the manner you posted outside of finding fault with
Microsoft's CLI utilities? My comment was intended to try and find out
what that goal was to see if a workaround or an alternative approach
would be a better fit.

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l

hello,

My goal is to hope the problem will be fixed in the next release of
findstr so that it will be a better cmd environment.

regards,
Cliff

I can confirm the behavior and would too consider it a bug. The
following syntax (when executed from within a script) will create
similar output to the native findstr command if that's what you
really need - for %%l in (f1 f2) do @set /p =%%l:<nul&findstr
"findstr" %%l&echo/

... it is, however, less efficient on large numbers of files that
findstr alone. If this is not precisely what you're after, please
post back with an expanded definition of your goal.

Note, the FIND.EXE command does not exhibit this behavior but uses a
different output format.

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l

cliff wrote:
hello,

findstr output has a problem when the search word happens to be on a
last line of the preceding file. The output will be garbled with the
succeeding file searched.
e.g here shows a sample command line session showing the problem
with file1.txt and file2.txt :

c:\ > type file1.txt
test
findstr
c:\ > type file2.txt
test
findstr
c:\ > findstr "findstr" file1.txt file2.txt
file1.txt:findstrfile2.txt:findstr


The desired output is :
file1.txt:findstr
file2.txt:findstr


The last line should not have a newline for file1.txt. Try using
notepad and make sure the last line does not have a newline. I also
noticed that "edit" also seems to insert a newline for the last
line(but not notepad).
I also tested grep(a sort of findstr equivalent) and it does not
have a this problem when given the same file1.txt and file2.txt.

Will this problem be fixed? It could cause some subtle problems in
scripts when pipes are used.
This problem exists on Windows 2000 and Windows XP.

regards,
Cliff

 

[Timo Salmi]

Dean Wells [MVP] wrote:
About: findstr "findstr" file1.txt file2.txt

I can confirm the behavior and would too consider it a bug. The

I, too, can confirm the outcome. However, I would rather consider it
naturally expected behavior. But, if and when it is a problem:

@echo off & setlocal enableextensions
type file1.txt > file1.tmp
echo.>>file1.tmp
findstr "findstr" file1.tmp file2.txt
del file1.tmp
endlocal & goto :EOF

C:\_M>cmdfaq
file1.tmp:findstr
file2.txt:findstr

All the best, Timo